1

Supposedly, in order to set up Kerberos, I need to run kdb5_ldap_util, though I'm not sure why. However, it fails with:

# kdb5_ldap_util -D cn=admin,dc=example,dc=com create -subtrees dc=example,dc=com -r EXAMPLE.COM -s -H ldapi:///
Password for "cn=admin,dc=example,dc=com":
Initializing database for realm 'EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
kdb5_ldap_util: Invalid syntax while creating realm 'EXAMPLE.COM'

I have no idea what that error means. Googling about has lead me to believe that it's a cryptic way of telling that the "kerberos schema" hasn't been "loaded" into the LDAP server yet. Checking /etc/ldap/schema, there isn't a kerberos.schema or anything equally obvious. There is, as some resources point out, a /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz and /usr/share/doc/krb5-kdc-ldap/kerberos.ldif.gz. (Why are these gzipped, other than to be obtuse to use?)

gunziping those two files into /etc/ldap/schema and running the following:

# ldapadd -Y EXTERNAL -H ldapi:/// -f kerberos.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
ldapadd: invalid format (line 5) entry: "cn=schema"

Line 5 is a comment.

This is the same command that I had to run on all the other LDIF files in that directory in order to get OpenLDAP working in the first place. Why doesn't this schema work?

The error tells me nothing about what's going wrong, but this seems to be a close match (but implies that the Kerberos schema is broken out of the box): do I need to edit it as suggested there? Some other resources seem to also suggest the LDIF needs a cn: entry for each part: is that needed as well/

0

krb5_ldap_util is indeed cryptically trying to inform me that I haven't added the Kerberos schema to the LDAP server. Unfortunately, doing so is far from trivial.

The best guide I have so far is this one from MIT, though it's directions are a bit off. I'm going to mostly repeat it here, but corrected for what appears to be the modern state of the world:

  1. You need to extract the schema files. They're at /usr/share/doc/krb5-kdc-ldap/kerberos.ldif.gz and /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz. To extract them, run:

    gunzip -c /usr/share/doc/krb5-kdc-ldap/kerberos.ldif.gz > /etc/ldap/schema/kerberos.ldif
    gunzip -c /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz > /etc/ldap/schema/kerberos.schema
    
  2. Now we're about at the guide's step 1, so in a directory somewhere, create a file with:

    include /etc/ldap/schema/kerberos.schema
    

    Save it somewhere. I'm calling mine /tmp/ldap-kerberos/schema_convert.conf.

  3. Make a directory to hold the results, e.g.,

    mkdir /tmp/ldap-kerberos/krb5_ldif
    
  4. Run:

    slaptest -f /tmp/ldap-kerberos/schema_convert.conf -F /tmp/ldap-kerberos/krb5_ldif
    
  5. This will output a bunch of stuff into /tmp/ldap-kerberos/krb5_ldif. Open /tmp/ldap-kerberos/krb5_ldif/cn=config/cn=schema/cn={0}kerberos.ldif in $EDITOR. As the guide suggests, replace:

    dn: cn={0}kerberos
    cn: {0}kerberos
    

    with

    dn: cn=kerberos,cn=schema,cn=config
    cn: kerberos
    

    Look at the bottom of the file for something like:

    structuralObjectClass: olcSchemaConfig
    entryUUID: ...
    creatorsName: cn=config
    createTimestamp: ...
    entryCSN: ...
    modifiersName: cn=config
    modifyTimestamp: ...
    

    and remove it.

  6. Add it to the server:

    ldapadd -Y EXTERNAL -H ldapi:/// -f  /tmp/ldap-kerberos/krb5_ldif/cn=config/cn=schema/cn={0}kerberos.ldif
    

    You should see:

    adding new entry "cn=kerberos,cn=schema,cn=config"
    

krb5_ldif should no longer complain. Also, note that Kerberos, AFAICT, must have a name with a password to bind to. It cannot do "peer authentication", which is what we're doing when we do -Y EXTERNAL -H ldapi:///: that connects over a Unix socket, and LDAP can ask the socket what our UID is, and trust us based on that. You have to create a name with a password, and use that instead. I've already done this; mine is cn=admin,dc=example,dc=com, visible in the command in the question. Kerberos will store the password to this name in a file, so just generate a long random password and set the permissions appropriately.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.