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.
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.
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
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?
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)
@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
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.
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.