This appendix provides generic information about troubleshooting errors and problems.

Cannot find key of appropriate type to decrypt. 

GSSException: Failure unspecified at GSS-API level (Mechanism level:
Invalid argument (400) - Cannot find key of appropriate type to
decrypt AP REP - RC4 with HMAC)

If you see abore error indicating missing key type, this will happen with two different use cases. Firstly your JVM may not support appropriate encryption type or it is disabled in your krb5.conf file.

default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac

Second case is less obvious and hard to track because it will lead into same error. This specific GSSException is throws also if you simply don’t have a required encryption key which then may be caused by a misconfiguration in your kerberos server or a simply typo in your principal.

Using wrong kerberos configuration.  ​

In most system all commands and libraries will search kerberos configuration either from a default locations or special locations like JDKs. It’s easy to get mixed up especially if working from unix systems, which already may have default settings to work with MIT kerberos, towards Windows domains.

This is a specific example what happens with ldapsearch trying to query Windows AD using kerberos authentication.

$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
  additional info: SASL(-1): generic failure: GSSAPI Error:
  Unspecified GSS failure.  Minor code may provide more information
  (No Kerberos credentials available)

Well that doesn’t look good and is a simple indication that I don’t have a valid kerberos tickets as shown below.

$ klist
klist: Credentials cache file '/tmp/krb5cc_1000' not found

We already have a keytab file we exported from Windows AD to be used with tomcat running on Linux. Lets try to use that to authenticate with Windows AD.

You can have a dedicated config file which usually can be used with native Linux commands and JVMs via system propertys.

$ cat krb5.ini
[libdefaults]
default_realm = EXAMPLE.ORG
default_keytab_name = /tmp/tomcat.keytab
forwardable=true

[realms]
EXAMPLE.ORG = {
  kdc = WIN-EKBO0EQ7TS7.example.org:88
}

[domain_realm]
example.org=EXAMPLE.ORG
.example.org=EXAMPLE.ORG

Lets use that config and a keytab to get initial credentials.

$ env KRB5_CONFIG=/path/to/krb5.ini kinit -kt tomcat.keytab HTTP/[email protected]

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/[email protected]

Valid starting     Expires            Service principal
26/03/15 09:04:37  26/03/15 19:04:37  krbtgt/[email protected]
  renew until 27/03/15 09:04:37

Lets see what happens if we now try to do a simple query against Windows AD.

$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
  additional info: SASL(-1): generic failure: GSSAPI Error:
  Unspecified GSS failure.  Minor code may provide more information
  (KDC returned error string: PROCESS_TGS)

This may be simply because ldapsearch is getting confused and simply using wrong configuration. You can tell ldapsearch to use a different configuration via KRB5_CONFIG env variable just like we did with kinit. You can also use KRB5_TRACE=/dev/stderr to get more verbose output of what native libraries are doing.

$ env KRB5_CONFIG=/path/to/krb5.ini ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/[email protected]

Valid starting     Expires            Service principal
26/03/15 09:11:03  26/03/15 19:11:03  krbtgt/[email protected]
  renew until 27/03/15 09:11:03
  26/03/15 09:11:44  26/03/15 19:11:03
  ldap/[email protected]
    renew until 27/03/15 09:11:03

Above you can see what happened if query was successful by looking kerberos tickets. Now you can experiment with further query commands i.e. if you working with KerberosLdapContextSource.

$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org \
-b "dc=example,dc=org" \
"(| ([email protected])
([email protected]))" \
dn

...
# test user, example.org
dn: CN=test user,DC=example,DC=org