Windows auth for JDBC connector

:bangbang: Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.

Hi,

I am having hard time to configure windows auth for JDBC connector. Followed reference guide given in the following thread, but its not helping. I am getting an error :

@ravindrathakkar -

Unable to obtain Principal Name for authentication" is JAAS/GSS telling you it never got a valid Kerberos principal to log in with. It’s failing before it even talks to AD, while building the login context. On SailPoint’s JDBC connector this is almost always a formatting problem in the connection string or the Kerberos username, not a network or firewall issue.

Two things worth checking first, straight from SailPoint’s troubleshooting page for this connector:

  1. The domain/realm in the JDBC URL needs to be all caps, e.g. jdbc:sqlserver://yourhost.sqlkerb.lab;trustServerCertificate=true;integratedSecurity=true;authenticationScheme=JavaKerberos; where the realm part matches your Kerberos realm in caps, not mixed case.
  2. The Kerberos username field on the source needs a full UPN in all caps, like SERVICEACCOUNT@DOMAIN.COM. Not the sAMAccountName, not lowercase.

Since you already followed Brennen’s guide, also re-check these — they’re the usual suspects when the guide alone doesn’t fix it:

  • SQLJDBCDriver.config and krb5.config are actually uploaded under Base Configuration, not just referenced somewhere else. A missing krb5.config throws this same LoginException rather than a GSSException.
  • krb5.config matches your AD forest’s realm and KDC entries exactly, including a domain_realm mapping if the VA and the SQL box sit in different DNS domains.
  • The VA can resolve the SQL host, the KDC, and the realm through nslookup. SailPoint lists this as a hard prerequisite before Kerberos will work at all.

If you’re on the generic JDBC connector rather than the dedicated MS SQL Server connector, also confirm useMssqlKerberosAuth is set to true on the source. It’s a connector attribute, not a UI toggle, so it has to be patched in through the ISC API:

[{"op": "add", "path": "/connectorAttributes/useMssqlKerberosAuth", "value": true}]

If all of that checks out and the error’s still identical, post the exact domain/username string you’ve got in the connection config (redact the real values) — that’s where this usually breaks.

Docs:

Hello Ravindra. Amit covered the UPN casing, DNS, and Kerberos config checks, and those are all worth confirming. Since you already followed Brennen’s guide, the angle I would add is the login module itself, because it can produce this exact error even when the casing is right and both files are uploaded.

“Unable to obtain Principal Name for authentication” comes from the JAAS login step, before it reaches SQL Server. If your SQLJDBCDriver.config uses the ticket-cache path:

SQLJDBCDriver { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true doNotPrompt=true; };

then with doNotPrompt=true and no usable cached ticket on the VA, the module can fail to obtain a client principal, which fits the error. Microsoft also supports Kerberos using a supplied principal and password, so as a test you could try a login module that does not force the ticket-cache path and see whether authentication succeeds using the source credentials:

SQLJDBCDriver { com.sun.security.auth.module.Krb5LoginModule required; };

Enter the Login Account Name as an uppercase UPN (USER@DOMAIN.COM) with the Password, upload the updated file, and re-run Test Connection. I would also confirm useMssqlKerberosAuth is set to true on the source, since it defaults to false

If Test Connection passes after that change, that strongly points to the credential path as the cause. If it still fails, share sanitized copies of SQLJDBCDriver.config and krb5.config and we can narrow it down further.

Well, I got to connect JDBC source but its not holding connection for longer after certain time it loses the connectivity and giving this error. I am suspecting its an issue related to SQLJDBCDriver.config file.


I am suspecting its an issue related to SQLJDBCDriver.config file.

image
I added flag to user ticket cashe, but no luck.


Also, I tried SQLJDBCDriver.config file suggested by harish Punna but getting same error.

If I am missing some key flags or my present file has any formating error. Can anyone please provide the working version of SQLJDBCDriver.config file to try.

Hi @ravindrathakkar that error means the driver can’t read the entry in your config file, so it’s not even reaching Kerberos yet. I’d recreate the file in Notepad++ or VS Code, save it as plain UTF-8 without BOM, and double-check the semicolons:

SQLJDBCDriver {
    com.sun.security.auth.module.Krb5LoginModule required
    useTicketCache=false
    refreshKrb5Config=true;
};

Since it connects first and then drops after a while, also check the JDBC troubleshooting doc:

It mentions pooled connections can lock up, and you can turn pooling off with this patch on the source:

{
  "op": "add",
  "path": "/connectorAttributes/pool.disablePooling",
  "value": true
}

A few other things from the same doc that are worth checking: keep the domain in uppercase in the URL and in the username (USER@DOMAIN.COM), use the server’s actual hostname instead of a DNS alias, and make sure the service account has AES 128/256 enabled in AD.

Try fixing the file and disabling pooling first. If it still drops, paste the error and your config file here as text and we’ll take another look.

Thanks,

@SivaLankapalli

Hello Ravindra. Thanks, the second file is useful because this is valid JAAS syntax:

SQLJDBCDriver {
    com.sun.security.auth.module.Krb5LoginModule required;
};

Since it still returns “No LoginModules configured for SQLJDBCDriver,” I would first make sure CCG is actually loading the updated file.

I would confirm the correct SQLJDBCDriver.config is shown as the current file under Base Configuration, re-upload it if needed, save the source, restart CCG on the VA, then run Test Connection again. SailPoint notes that a CCG restart may be needed to clear the cached configuration and load the new file: Base Configuration.

If you add ticket-cache options later, keep them before the terminating semicolon:

SQLJDBCDriver {
    com.sun.security.auth.module.Krb5LoginModule required
    useTicketCache=true;
};

I would keep pooling as a separate test after this JAAS error is cleared. If the JAAS error clears but the connection still drops later, please share that later error separately. If the same “No LoginModules configured” error remains, share what Base Configuration shows for the currently uploaded SQLJDBCDriver.config.