This appendix provides generic information about troubleshooting errors and problems.
Important | |
---|---|
If you think environment and configuration is correctly setup, do double check and ask other person to check possible obvious mistakes or typos. Kerberos setup is generally very brittle and it is not always very easy to debug where the problem lies. |
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