kinit failure with Kerberos and LDAP backend

[Berthold Cogel]

Am 26.10.2012 11:44, schrieb Mark Pröhl:
> Am 24.10.2012 11:25, schrieb Berthold Cogel:
>> ...
>  > 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
>>
> 
> I cannot exactly reproduce your problem.
> 
> With these ACLs kadmin.local -q getprinc ... can only find principals 
> below ou=Kerberos. I need to extend the attribute set in your second ACL 
> rule to 
> "objectClass,krbPrincipalName,krbPrincipalKey,krbLastPwdChange,krbExtraData,entry" 
> to get it working.
> 
> To see if the problem is related to OpenLDAP ACLs you could do a test 
> with more permissive ACLs on the slave? Or send me your complete 
> slapd.conf from the slave server?
> 
> Regards,
> 
> Mark
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 


You're right... this one was missing:

access to dn.subtree="ou=People,dc=uni-koeln,dc=de"
        by dn.exact="cn=kdc,ou=Kerberos,dc=uni-koeln,dc=de" read



Regards
Berthold