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.