kinit failure with Kerberos and LDAP backend

Mark Pröhl mark at mproehl.net
Tue Oct 23 06:42:28 EDT 2012


Am 22.10.2012 10:34, schrieb Berthold Cogel:
> Am 21.10.2012 17:48, schrieb Berthold Cogel:
>> Am 21.10.2012 08:39, schrieb Mark Pröhl:
>>> Am 21.10.2012 00:21, schrieb Berthold Cogel:
>>>> Am 19.10.2012 20:02, schrieb Mark Pröhl:
>>>>> Hi,
>>>>>
>>>>> is there any difference in the output of the following two search
>>>>> requests?
>>>>>
>>>>> root at kdc # ldapsearch -Y EXTERNAL -H ldapi:// \
>>>>>     -b ou=People,dc=uni-koeln,dc=de  \
>>>>>
>>>>> '(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=a0537 at RRZ.UNI-KOELN.DE))'
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> root at kdc # ldapsearch -Y EXTERNAL -H ldapi:// \
>>>>>     -b cn=RRZ.UNI-KOELN.DE,ou=Kerberos,dc=uni-koeln,dc=de" \
>>>>>
>>>>> '(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=a0537 at RRZ.UNI-KOELN.DE))'
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mark
>>>>>
>>>>>
>
> I got an hint from a former colleague and tried this on all three KDCs:
>
> kadmin.local -q "getprinc a0537"
>
>
> On the master I get
>
> kadmin.local -q "getprinc a0537"
> Authenticating as principal root/admin at RRZ.UNI-KOELN.DE with password.
> Principal: a0537 at RRZ.UNI-KOELN.DE
> Expiration date: [never]
> Last password change: Fri Oct 19 14:27:36 CEST 2012
> Password expiration date: [none]
> Maximum ticket life: 0 days 10:00:00
> Maximum renewable life: 7 days 00:00:00
> Last modified: Fri Oct 19 14:27:36 CEST 2012 (root/admin at RRZ.UNI-KOELN.DE)
> Last successful authentication: [never]
> Last failed authentication: [never]
> Failed password attempts: 0
> Number of keys: 3
> Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
> Key: vno 1, DES cbc mode with CRC-32, no salt
> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
> Attributes: REQUIRES_PRE_AUTH
> Policy: default
>
>
> On both slaves:
>
> kadmin.local -q "getprinc a0537"
> Authenticating as principal root/admin at RRZ.UNI-KOELN.DE with password.
> get_principal: Principal does not exist while retrieving
> "a0537 at RRZ.UNI-KOELN.DE".
>
>
> For the principal not in ou=People it's this on the master
>
> kadmin.local -q "getprinc bco"
> Authenticating as principal root/admin at RRZ.UNI-KOELN.DE with password.
> Principal: bco at RRZ.UNI-KOELN.DE
> Expiration date: [never]
> Last password change: Tue May 29 11:25:51 CEST 2012
> Password expiration date: [none]
> Maximum ticket life: 0 days 10:00:00
> Maximum renewable life: 7 days 00:00:00
> Last modified: Mon Sep 24 16:21:00 CEST 2012 (root/admin at RRZ.UNI-KOELN.DE)
> Last successful authentication: [never]
> Last failed authentication: [never]
> Failed password attempts: 0
> Number of keys: 3
> Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
> Key: vno 1, DES cbc mode with CRC-32, no salt
> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
> Attributes: REQUIRES_PRE_AUTH
> Policy: default
>
>
> and on both slaves:
>
> kadmin.local -q "getprinc bco"
> Authenticating as principal root/admin at RRZ.UNI-KOELN.DE with password.
> Principal: bco at RRZ.UNI-KOELN.DE
> Expiration date: [never]
> Last password change: Tue May 29 11:25:51 CEST 2012
> Password expiration date: [none]
> Maximum ticket life: 0 days 10:00:00
> Maximum renewable life: 7 days 00:00:00
> Last modified: Mon Sep 24 16:21:00 CEST 2012 (root/admin at RRZ.UNI-KOELN.DE)
> Last successful authentication: [never]
> Last failed authentication: [never]
> Failed password attempts: 0
> Number of keys: 3
> Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
> Key: vno 1, DES cbc mode with CRC-32, no salt
> Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
> Attributes: REQUIRES_PRE_AUTH
> Policy: default
>


so the principal a0537 that is stored below ou=People only exists on the 
master while bco who is stored below cn=RRZ.UNI-KOELN.DE,ou=Kerberos 
exists on master and slave KDCs.

Looks like a problem related to LDAP permissions or replication ...

Are the OpenLDAP ACLs configured identical on master an slaves? Perhaps 
kdc_dn does not have read permissions for kerberos attributes below 
ou=People on the slaves?

When you configured ou=People as an additional sub tree for kerberos 
principals via kdb5_ldap_util, did you restart the krb5kdc process on 
all three KDC machines?

I assume you use OpenLDAP replication, not kprop.
Has all principal data been replicated to all slaves?
Has krbSubTrees in  cn=RRZ.UNI-KOELN.DE,ou=Kerberos,dc=uni-koeln,dc=de 
been replicated to all slaves?












More information about the Kerberos mailing list