kdb5_ldap_util create fails

[Tobias Hachmer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20140309/00699bd1/attachment-0001.bin