On 1/21/20 2:58 PM, Bill MacAllister wrote:
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
Thanks for the tips/assistance. I'm going to give these commands a try.
-- Prentice