Hello Greg, thanks for your answer and your further tests on this.
On Saturday 08 March 2014 15:51:33 Greg Hudson wrote: > > Mar 07 16:34:32 ldapkerberos slapd[959]: oc_check_required entry > > (ou=mit- kerberos,dc=example,dc=com), objectClass "krbContainer" > > Mar 07 16:34:32 ldapkerberos slapd[959]: Entry (ou=mit- > > kerberos,dc=example,dc=com), attribute 'ou' not allowed > > If I use a cn= as the first element of the container DN, it works. > Since krbContainer is defined in the schema with attributes "MUST ( cn > )" and nothing else, this may be expected behavior. Yes, if I let kdb5_ldap_util create the first container with a cn as the rdn it works here also on my archlinux machine: # mit-kerberos, example.com dn: cn=mit-kerberos,dc=example,dc=com objectClass: krbContainer cn: mit-kerberos > > I have set up a test machine with debian wheezy (kerberos version > > 1.10.1). With the krb5_ldap_util here everything works fine. > > I could produce the same behavior with krb5 1.10, so I don't think > there has been a relevant change on our side. Perhaps there is a > different OpenLDAP version on the test machine? Did you use all of > the same DNs? Archlinux machine: openldap version 2.4.39 Debian Wheezy machine: openldap version 2.4.31 The difference between the two kerberos versions I have recognized are the following: If the first kerberos container doesn't exist in the dit both kdb5_ldap_util versions create it as mentioned above. If I create the first kerberos container manually with objectClass organizationalUnit like this: # mit-kerberos, example.com dn: ou=mit-kerberos,dc=example,dc=com objectClass: organizationalUnit ou: mit-kerberos the kdb5_ldap_util from krb 1.12.1 exit with the error that the object has no cn like defined in schema for the krbContainer object. But the kdb5_ldap_util from krb 1.10.1 (debian tst machine) just leaves the first object as it is and initializes the kerberos backend in ldap: ... # mit-kerberos, example.com dn: ou=mit-kerberos,dc=example,dc=com objectClass: organizationalUnit ou: mit-kerberos # mit-kdc, mit-kerberos, example.com dn: cn=mit-kdc,ou=mit-kerberos,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject cn: mit-kdc userPassword:: ... # mit-kadmind, mit-kerberos, example.com dn: cn=mit-kadmind,ou=mit-kerberos,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject cn: mit-kadmind userPassword:: ... # EXAMPLE.COM, mit-kerberos, example.com dn: cn=EXAMPLE.COM,ou=mit-kerberos,dc=example,dc=com cn: EXAMPLE.COM objectClass: top objectClass: krbRealmContainer objectClass: krbTicketPolicyAux krbSubTrees: ou=users,dc=example,dc=com krbSearchScope: 2 ... So, from my pov this may be a misbehavior of the older version. Now it is quite straight forward to have the first object of an objectclass krbContainer as defined in the kerberos.schema. Greetings from germany, Tobias Hachmer
signature.asc
Description: This is a digitally signed message part.
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos