On 2020-01-17 10:12, Prentice Bisbal wrote:
On 1/16/20 8:05 PM, Quanah Gibson-Mount wrote:
That's exactly what I suspected. We're using AD for our Kerberos
Client, and one of our AD admins insists that it couldn't be expired
credentials. I did use a utility called msktutil to make sure the
kerberos tickets in /etc/krb5.keytab were up to date, but I'm still
getting that error. Any ideas on how to prove/disprove what you
suggest, so I can go back to my AD admins with more information?
The tools that I use to investigate problems like this are klist,
k5start, ldapsearch, and ldapwhoami. I usually start by looking at
the keytab itself with klist just to make sure that the keytab itself
is not damaged.
Next I make sure I can generate a ticket cache.
k5start -f /etc/krb5.keytab host/<fqdn> -- klist
Next I use the keytab for authentication to a simple service. For
us this is a remctl help command.
k5start -f /etc/krb5.keytab host/<fqdn> -- remctl <host> help
If this fails there is no point in trying to authenticate to the
LDAP server. Do the normal checks for Kerberos failures, i.e. forward
and reverse DNS entries for hosts involved, system clocks, and
krb5.conf.
If the keytab appears to work for the simple service I would
proceed to testing searches against AD.
k5start -f /etc/krb5.keytab host/<fqdn> -- ldapsearch -h <ad> -b
<basedn> cn=<hostid>
The <hostid> might and might not be the same as the principal that
you specified when the keytab was created. In AD the <hostid> is
limited to 20 characters. When we generate a keytab we define the
ensure that the <hostid> does not exceed this limit by truncated as
needed and adding a sequence number to ensure uniqueness. The <hostid>
is probably in the keytab file.
I suppose that the ldapsearch agains <ad> will be affected by the ACLs
implemented there. If this fails you will need to talk to the AD admin
it figure that out. I got our AD administrators to create a separate
OU for our keytabs and give us full access to that OU.
You really do want to see what the <ad> entry for the keytab is to
ensure that the entry is self consistent. The critical attributes are
userPrincipalName, dNSHostName, and servicePrincipalName. Make sure
these are consistent. In our case if we see a problem here we just
delete the entry and re-create it. We usually use wallet developed at
Stanford for managing keytabs, but when we hit this type of problem we
use ldapdelete to remove the offending entry.
If the <ad> ldapsearch works then I would proceed to trying an
authentication against the OpenLDAP server using ldapwhoami.
k5start -f /etc/krb5.keytab host/<fqdn> -- ldapwhoami -h <ol>
In addition to any error messages look at the LDAP log entries.
Specifically
look at the authz entries to make sure that the principal to dn mapping
is what you expect.
If you get stuck let me know what you are seeing.
Bill