LDAP & Kerberos SSO - Troubleshooting

Error Message

KrbException: Identifier doesn't match expected value (906)

Solution

The user Account in the Directory server is disable, please enable it.

Error Message

Message stream modified (41)

Solution

This message is mostly caused due to case sensitive realms in the krb5.conf file. Please review if the domain is upper- or lowercase and try change it to the opposite in krb5.conf file.

Error Message regarding Key Size

java.security.InvalidKeyException: Illegal key size or default parameters error

Problem

The key for the Kerberos Ticket has a bigger key size then Java can handle. Java is not allowed to be shipped with higher encryption keys because of US export policies

Solution

Download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files

For more information, see this from Oracle

Error Message regarding keytab file

kinit(v5): Client not found in Kerberos database while getting initial credentials

Solution

Please check if the keytab file was correctly created. With the klist command you can directly check, what's inside the keytab file

klist -ke path/to/keytab/file.keytab Keytab name: FILE:path/to/keytab/file.keytab KVNO Principal ---- --------------------------------------------------------------------------  1 HOST/censhare-server.example.com@EXAMPLE.COM (ArcFour with HMAC/md5)

You can check the keytab file always with the kinit command

kinit -V -k -t path/to/keytab/file.keytab HOST/censhare-server.example.com@EXAMPLE.COM

Error Message regarding key version

java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))

Solution

The KVNO falue always raise by 1 if you change anything on the Directory user or it's SPN. Therefore a new keytab file needs to be created with the same and current KVNO. You can see the KVNO in the keytab file with the following command

klist -ke path/to/keytab/file.keytab Keytab name: FILE:path/to/keytab/file.keytabKVNO Principal ---- -------------------------------------------------------------------------- 1 HOST/censhare-server.example.com@EXAMPLE.COM (ArcFour with HMAC/md5)

And to compare with the current KVNO at the Directory Server you can use this command after you already authenticated to the Ticket service (via kinit)

### list current KVNO (kinit before that) kvno host/censhare-hostname@EXAMPLE.COM host/censhare-hostname@EXAMPLE.COM: kvno = 3
      

No support for encryption type

kvno: KDC has no support for encryption type while getting credentials for HTTP/web.domain.com@DOMAIN.COM

This most commonly happens when trying to use a principal with only DES keys, in a release (MIT krb5 1.7 or later) which disables DES by default. DES encryption is considered weak due to its inadequate key size. If you cannot migrate away from its use, you can re-enable DES by adding allow_weak_crypto = true to the [libdefaults] section of krb5.conf.

Client asking for login credentials after SingleSign-On Login

The Client is not allowed to read the Windows Ticket Cache, then you get asked for the credentials: Log in at authentication service is necessary.

Solution

On Windows Clients you should use Kerberos SSPI (kerberos_win_sspi) as authentication method, this allows the client to use native Windows Kerberos authentication instead of Javas GSSAPI.

Alternative: You could also allow access for GSSAPI to the TGT Session key by adding this value to the Windows Registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters Value Name: AllowTgtSessionKey Value Type: DWORD (32bit) Value Range: 1

WebClient error when SPNGO token is bigger then Jetty Cache allows

The Jetty webclient log shows following error

GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)

Solution

Set a bigger cache in the etc/jetty.xml configuration

65536  65536

WebClient error because of wrong SPNGO token

The Jetty webclient log shows following error

GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

Solution

You get not a SPNGO token from the Webrowser on the Client, please check the settings there.

INFO: Authorization Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw== SPNGO tokens start with a "Y" and not a "T" T = NTLM Y = SPNGO

censhare5/client error because of Unsupported authentication protocol NTLM.

The censhare5 WebClient shows the following error

javax.security.auth.login.LoginException: Unsupported authentication protocol NTLM.

Solution

Your Client Browser is not using GSSAPI for authentication and falls back to NTLM, which is not supported.

First of all you need to ensure that your browser can use GSSAPI, for

For more information, see this more information see here.

Another issue could be, that the SPN, the URL Host need to be the same and it has to be a A Record in DNS, you get above error on Windows if it's a CNAME for example. On MacOS X it doesn't matter if A or CNAME, so it works there in that case.

For further root-Cause analysis

For more information, see this Wireshark

KRB5KDC_ERR_ETYPE_NOSUPP in Kerberos Protocol

Problem The Client uses still NTLM for authentication, on a Wireshark capture you see the Kerberos Error Message KRB5KDC_ERR_ETYPE_NOSUPP

Solution Please inspect the allowed encryption types of the Client and Servers. Typically they use ArcFour and it can happen that Windows Server allows the Client to use AES which leads to a mismatch for the encryption type of the tickets. You should check the Windows Server Group policy in order to disallow AES and make ArcFour preferred.

WebClient error because of TGS timeout

The Jetty webclient log shows the following error:

>>> KrbKdcReq send: error trying yourserver.domain.com java.net.SocketTimeoutException: Receive timed out

The server is reachable, the ports UDP/TCP 88 as well and you see in the log file that it has been communicated with this server on that port already successfully.

Solution

UDP works only well with smaller-sized packets, if the packets are bigger they should be handled better by TCP, so often UDP get's block at a specific size and it got fallbacked to TCP. To limit Kerberos Authentication to TCP right away, add the following line to the [libdefaults] section in your krb5.conf file.

udp_preference_limit = 1

This actually means that UDP is preferred for packets with a size of 1 byte or smaller, otherwise, it falls back to TCP.

Client not found in Kerberos database

If you see the following error message:

Client not found in Kerberos database (6)

Something is not correct with the setup Directory Service User and its Service Principal Name (SPN) and/or the entries are not matching the entry in the keytab file.

With the following comands, you can verify the SPN and its correctness on the Windows Director Server.

### double SPN entries C:\Users\Administrator>setspn -X Checking domain DC=example,DC=com Processing entry 0 found 0 group of duplicate SPNs.  ### query if SPN exists C:\Users\Administrator>setspn -Q host/censhare-hostname Checking domain DC=example,DC=com CN=UserFor Censhare-Server,CN=Users,DC=example,DC=com         host/censhare-hostname  Existing SPN found!  ### list SPN of a user C:\Users\Administrator>setspn -L censhare-sso Registered ServicePrincipalNames for CN=UserFor Censhare-Server,CN=Users,DC=example,DC=com:         host/censhare-hostname

Sporadic time outs on LDAP queries

Error message Sporadically a time-out happens when LDAP gets queried but it also works at other tries. You see the following message in the censhare server logfiles:

Error while trying to connect to LDAP. Details: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: some.domain.server:389 [Root exception is java.net.ConnectException: Connection timed out (Connection timed out)]]

Problem If for the LDAP URL you use the ports 389 or via SSL 636, it may happen that the query result returns reference to another Server in the Active Directory Forest and a followup query will be made by censhare to that other Server, which may not be desired for queries and may not even be available for censhare.

Solution Instead of the ports 389 or via SSL 636 you should query the global catalog directly on the ports 3268 or via SSL 3269. Just replace the other ports in your LDAP URL with the LDAP service configuration.