LDAP & Kerberos SSO - Troubleshooting
Common error messages are described here including ways to analyze the problem
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
and patch your Client and Server JDK with these policy files.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
should be used to get the exact error message from the Kerberos Protocol at the Client.
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.