Am 23.10.2012 12:42, schrieb Mark Pröhl:
> 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@kdc # ldapsearch -Y EXTERNAL -H ldapi:// \
>>>>>> -b ou=People,dc=uni-koeln,dc=de \
>>>>>>
>>>>>> '(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))([email protected]))'
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> root@kdc # ldapsearch -Y EXTERNAL -H ldapi:// \
>>>>>> -b cn=RRZ.UNI-KOELN.DE,ou=Kerberos,dc=uni-koeln,dc=de" \
>>>>>>
>>>>>> '(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))([email protected]))'
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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/[email protected] with password.
>> Principal: [email protected]
>> 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/[email protected])
>> 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/[email protected] with password.
>> get_principal: Principal does not exist while retrieving
>> "[email protected]".
>>
>>
>> For the principal not in ou=People it's this on the master
>>
>> kadmin.local -q "getprinc bco"
>> Authenticating as principal root/[email protected] with password.
>> Principal: [email protected]
>> 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/[email protected])
>> 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/[email protected] with password.
>> Principal: [email protected]
>> 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/[email protected])
>> 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?
>
>
We're using LDAP replication and I made a full dump with slapcat to
compare the entries. LDAP replication is working perfectly.
krbSubTrees has been replicated and krbSearchScope is 2 on all systems.
And I've just restarted all kdcs. No change at all.
Master and slaves have different ACLs. The future IDM system is only
allowed to write to the master and the master has additional ACLs for
the consumer/slaves. Permissions for kadmin and kdc are all the same.
access to dn.subtree="ou=Kerberos,dc=uni-koeln,dc=de"
by dn.exact="cn=kdc,ou=Kerberos,dc=uni-koeln,dc=de" read
by dn.exact="cn=kadmind,ou=Kerberos,dc=uni-koeln,dc=de" write
by self read
by anonymous auth
by * break
access to
attrs="krbPrincipalName,krbPrincipalKey,krbLastPwdChange,krbExtraData"
by dn.exact="cn=kdc,ou=Kerberos,dc=uni-koeln,dc=de" read
by dn.exact="cn=kadmind,ou=Kerberos,dc=uni-koeln,dc=de" write
by self read
by * auth
On the master:
kadmin.local -q "listprincs"
Authenticating as principal root/[email protected] with password.
[email protected]
[email protected]
K/[email protected]
krbtgt/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
bco/[email protected]
idm/[email protected]
[email protected]
afs/[email protected]
[email protected]
afs/[email protected]
On the slaves:
kadmin.local -q "listprincs"
Authenticating as principal root/[email protected] with password.
K/[email protected]
krbtgt/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
kadmin/[email protected]
bco/[email protected]
idm/[email protected]
[email protected]
afs/[email protected]
[email protected]
afs/[email protected]
Regards
Berthhold
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
