How to set up Kerberos with OpenLDAP backend

Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.

1 Like

This section contains a small but annoying typo:

olcAccess: {3}to dn.subtree=“cn=krbContainer,dc=example,dc=com”
by dn.exact=“uid=kdc-service,dc=example,dc=com” read
by dn.exact=“uid=kadmin-service,dc=example,dc=com” write
by * none

Should be to dn.subtree=“cn=krb5Container …”

other than that … great guide !

Evert

Sorry, I don’t see the entry with krb5Container created, it’s krbContainer. Although I’m testing with MIT kerberos 1.19.2 now, in Jammy, but I’m not aware of something like this having changed.

1 Like

I followed the guide and destroyed the whole setup about 3 times thinking I was not doing something right until I found the note on this online guide:

Note
The ldap_kadmin_dn DN (uid=kadmin-service in our example) needs to have write access to the location specified by the -x parameter, otherwise you will get an Insufficient access error.

It took me a while to figure out what this note meant in terms of a practical procedure…
Here is what was missing in the note:

Give write access to kadmin-service to location by -x parameter:
Run command as follows (adjust as required):

$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
add: olcAccess
olcAccess: {4}to dn.subtree=“ou=People,dc=example,dc=com”
by dn.exact=”uid=kdc-service,dc=example,dc=com” read
by dn.exact=”uid=kadmin-service,dc=example,dc=com” write
by * none
EOF

1 Like

Thanks, I will update the note

I just changed your last by * none to by * break, or else no-one else would be able to read the ou=People subtree. The kerberos attributes (like keys) should still be protected by previous ACLs, can you do a quick check if you still have your setup up and running?

1 Like

Ahasenack, thank you! Will try and let you know.

Hello Ahasenack,

I want to thank you for that change (’* break’). That change alone fixed so many things…
I was being able to add -x principals, but SSSD was not working. I spent lots of time trying to fix it, but once I made the change you added, everything now works as it is supposed, and finally I can login users with no problem. Thank you thank you thank you.

I’m glad it worked, this is quite a complicated setup (kerberos + ldap + sssd)

2 Likes

@ahasenack, In my attempt to install Kerberos, I’ve found out that “ldap_kerberos_container_dn” inside “[libdefaults]” doesn’t work with the latest version of krb5kdc on ubuntu 22.04. I managed to make it work by placin inside “openldap_ldapconf”. Otherwise, krb5kdc wouldn’t start.
Also, when configuring this part, I updated “/etc/krb5kdc/kdc.conf” to make kdc work, I’m not sure if it’s a required step or only “/etc/krb5.conf” needs to be edited.

Upon a second installation on another system, it seems that “/etc/krb5kdc/kdc.conf” doesn’t need to be modified.
However, it looks like “ldap_kerberos_container_dn” does need to be included inside “openldap_ldapconf”.

Thanks for trying out the steps from this guide, I’ll take a look

1 Like

I think you experienced a different issue. I just followed the guide again, and I have ldap_kerberos_container_dn inside [dbdefaults] in /etc/krb5.conf.
Previously I did have issues with starting the kdc, but that was because I “converted” a normal kdc to kdc+openldap, and forgot to update kdc.conf. In particular, my stash file was named differently.
That being said, if you still follow the guide and have an issue with starting the kdc, please post the error message from the logs, and we can go from there.

1 Like

I’m having a weird issue following this. I have an openldap server all set up, I have accounts, passwords validate against other services like nextcloud, etc. I am following this, I made the kdc-service and kadmin-service accounts…I can’t validate the passwords I set. One thing I noticed, for the working accounts, userPassword is “MD5 Hashed Password” but for the script in this guide, it ends up being a “SSHA Hashed Password”. I the logs aren’t shedding any light, just “invalid password” when I try to do the “ldapwhoami” despite the password changing fine (using “ldappasswd” or changing it in Apache Directory Studio). I’m not even sure how else to debug, any advice is appreciated.

Is your database in mdb format? Check in the output of slapcat -b cn=config, see what you have for your existing olcDatabase entry.

Hello, thanks for answering. Tomorrow I review the notice since today I do not have access to my work server, but I am following the step by step

Oh, I think I know. Looks like there are missing leading spaces in the section inside the EOF markers. These mark the lines as being a continuation of the previous line.

It should be like this:

$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
add: olcAccess
olcAccess: {4}to dn.subtree=“ou=People,dc=example,dc=com”
  by dn.exact=”uid=kdc-service,dc=example,dc=com” read
  by dn.exact=”uid=kadmin-service,dc=example,dc=com” write
  by * break
EOF

Note the leading spaces in the by dn.exact=... lines. See if that works, and I’ll update the guide accordingly.

@ahasenack ok now i get this error

This puzzles me a bit, the error 80 is quite generic. Maybe if you check the slapd logs it will tell you a bit more. See the “Logging” section of https://ubuntu.com/server/docs/service-ldap for more details.

Other than that, I see you have successfully adjusted the ACLs before, given your {3} entry from the earlier comment, so that’s good.

Do you have the ou=People,dc=test=dc=cvg,dc=com entry in your LDAP server? Specifically the ou=People bit?

Oh, and please change your LDAP olcRootPW password, as you have exposed it in a screenshot earlier.