when you are trying to kinit with a keytab, you need to use the -t flag. in our environment, Linux workstation and Windows domain controllers as root I can: kinit -k -t /etc/krb5.keytab and get a TGT
-kyley -------------------------------------------------- From: "Douglas E. Engert" <[email protected]> Sent: Tuesday, May 25, 2010 7:37 AM To: "Lars Kellogg-Stedman" <[email protected]> Cc: <[email protected]> Subject: Re: Loading host service principal from /etc/krb5.keytab? > > > Lars Kellogg-Stedman wrote: >> Hello all, >> >> Should it be possible to load the host service principal from >> /etc/krb5.keytab for the purpose of authenticating against an Active >> Directory server? That is, should I expect this to work? >> >> kinit -k host/[email protected] > > AD will look for an account where the principal matches the > userPrincipalName attribute, or where the principal will match > samaccountn...@domain > > I suspect that in your case the userPrincipalName (if any) is > host/[email protected] and the sAMAccountName is BUILDMASTER$ > so kinit -k host/[email protected] may work > and kinit -k [email protected] > should work. > > For machine that is not Windows you could change the userPrincipalName > attribute on the account to host/[email protected] > >> >> I invariably receive the following error message: >> >> kinit(v5): Client not found in Kerberos database while getting >> initial credentials >> >> Everything else seems to be working fine (I can kinit as a user, and >> those credentials are accepted for access to the server). The >> specified principal is listed by 'klist -k': >> >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 2 host/[email protected] >> 2 host/[email protected] >> 2 host/[email protected] >> 2 host/[email protected] >> 2 host/[email protected] >> 2 host/[email protected] >> 2 [email protected] >> 2 [email protected] >> 2 [email protected] >> >> The error message suggests to me some sort of hostname mismatch >> somewhere, but DNS (forward and reverse), the system hostname, and the >> servicePrincipalNames in AD are all consistent. >> >> The goal here is to be able to bind to an AD server using the stored >> host principal (rather than using shared credentials in >> /etc/ldap.conf, which seems to be the most common alternative to >> anonymous binds). >> >> Thanks for your help! >> ________________________________________________ >> Kerberos mailing list [email protected] >> https://mailman.mit.edu/mailman/listinfo/kerberos >> >> > > -- > > Douglas E. Engert <[email protected]> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
