smbkrb5pwd – password syncing for OpenLDAP, MIT kerberos and Samba
Here at Opinsys we’ve been busy trying to figure out how to make user management work easily without having to use ugly tricks to glue different applications together. Changing password sounds really simple to many, but it often gets quite complicated as there are many passwords that need to be changed. It is possible to write a script to change the different passwords at the same time, but that limits password changing to that single script. Using GUI programs through PAM or Moodle to change the password require a different approach.
In earlier posting I went through the setup for using SASL to get rid of one password, but that left us still with Samba passwords to be changed separately. As one commenter noted, there has been for a long time an OpenLDAP overlay called smbk5pwd that syncs Heimdal kerberos and Samba passwords automatically when the password is changed in OpenLDAP. It works by intercepting the ldap exop password change operations and doing its own magic. We’ve been using MIT Kerberos until now and as it is the better maintained kerberos implementation in Ubuntu, we wanted to keep using it.
As there was no existing solution like smbk5pwd for it, we decided to implement one. smbk5pwd modifies the kerberos keys directly in the database, but we were not brave enough to try the same with MIT Kerberos and instead chose to use kadmind to create the principals in ldap. This approach uses extra network connections and it is possible that changing password fails because connecting kadmind fails or kadmind cannot connect back to ldap. Having a system where ldap server connects to kerberos server that connects back to ldap is not an optimal solution, but so far we haven’t seen problems arising from this. On the other hand not having to deal with kerberos internals is a definite plus.
If you are brave enough, here are quick instructions on how to use the overlay. This is now the first version of the overlay and it has not been in production use anywhere. It’s still missing features and ACLs need to be checked out, so this is work in progress.
Installation instructions
The source code for smbkrb5pwd overlay is available here.
To compile the overlay the easiest way is to get the full source code for OpenLDAP and place the smbkrb5pwd directory under contrib/slapd-modules directory. After compiling OpenLDAP normally the overlay can be compiled simply by:
cd contrib/slapd-modules make sudo cp .libs/* /usr/lib/ldap/
A precompiled version of smbkrb5pwd for Ubuntu 10.04 (Lucid Lynx) is available from Opinsys PPA in Launchpad:
sudo apt-get install slapd-smbkrb5pwd
To configure the overlay, the module needs to be loaded and configured for the database.
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib/ldap
olcModuleload: {0}back_hdb
olcModuleload: {1}smbkrb5pwd
dn: olcOverlay={0}smbkrb5pwd
objectClass: olcOverlayConfig
objectClass: olcSmbKrb5PwdConfig
olcOverlay: {0}smbkrb5pwd
olcSmbKrb5PwdEnable: samba
olcSmbKrb5PwdEnable: krb5
olcSmbKrb5PwdMustChange: 2592012
olcSmbKrb5PwdKrb5Realm: EDU.EXAMPLE.ORG
olcSmbKrb5PwdRequiredClass: posixAccount
The overlay accepts the following configuration attributes:
| Attribute | Possible values | Description |
| olcSmbKrb5PwdEnable | samba / krb5 | Enable samba/kerberos functionality of the module, same as olcSmbK5PwdEnable in smbk5pwd. If attribute is not set or both are set, both passwords are changed. |
| olcSmbKrb5PwdMustChange | e.g. 31536000 (year), 2592000 (30 seconds) | Time in seconds before the password expires (currently affects only Samba) |
| olcSmbKrb5PwdKrb5Realm | e.g. EDU.EXAMPLE.ORG | Kerberos realm used to create user principals |
| olcSmbKrb5PwdRequiredClass | e.g. posixAccount | If set, the entry needs to have this object class for the kerberos principal and samba passwords to be modified |
smbkrb5pwd connects to kadmind using a principal found in keytab file /etc/ldap/slapd.d/openldap-krb5.keytab. The keytab is searched for principal that has name smbkrb5pwd/FQDN@REALM. Note that “hostname -f” should return fqdn. One way to achieve this is to put fqdn as the first name in /etc/hosts for the server’s ip address (here 10.11.12.13):
10.11.12.13 server.edu.example.org server
Creating the principal and exporting it to a keytab file can be done with the following commands:
sudo kadmin.local -q "addprinc -randkey smbkrb5pwd/server.edu.example.org@EDU.EXAMPLE.ORG"
sudo kadmin.local -q "ktadd -e des-cbc-crc:normal -k /etc/ldap/slapd.d/openldap-krb5.keytab \
smbkrb5pwd/server.edu.example.org@EDU.EXAMPLE.ORG"
sudo chown openldap.openldap /etc/ldap/slapd.d/openldap-krb5.keytab
The overlay activates itself when an password change exop request is made. This can be done for example with ldappasswd command:
ldappasswd -x -D uid=admin,ou=people,dc=edu,dc=example,dc=org -W \ uid=user1,ou=people,dc=edu,dc=example,dc=org
smbkrb5pwd writes debug information to slapd’s logfile which is normally /var/log/syslog in Ubuntu.
Happy hacking!
Veli-Matti Lintu
Tags: mit kerberos, OpenLDAP, password, samba
06.05.2010
I loved the quote “It works by intercepting the ldap exop password change operations and doing its own magic.” — sounds like black magic indeed
But thank you, this might come in handy.
10.06.2010
“dn: olcOverlay={0}smbkrb5pwd” – Is it right? Maybe “dn: olcOverlay={0}smbkrb5pwd,cn=config” or something like it?
24.06.2010
I had some issues following your short guide. Whenever I tried running ldappasswd on the server with the overlay enabled I would get an ‘Connect error (-11)’. No useful error message or anything, so I first thought ldappasswd was broken. However, after searching and figuring it was probably somewhere else, I went on and found issues with smbkrb5pwd.
First of all, the keytab didn’t seem to be sufficient to connect to kadmin, I guess this is configurable through allowed keytype settings etc., but I chose to just leave out the key type so there are 4 entries in my keytab for smbkrb5pwd now (and “sudo kadmin -k -t /etc/ldap/slapd.d/openldap-krb5.keytab -p smbkrb5pwd/`hostname -f`” now works).
Second, smbkrb5pwd/`hostname -f` needs proper permissions in the kadmin ACL to be able to function correctly. I added the following to /etc/krb5/kadm5.acl:
smbkrb5pwd/atlas.denc.nl ac
The “ac” is for add principals (a) and change passwords (c). This fixed the issues for me, changing passwords now is a beauty again!
One last comment: I don’t understand why smbkrb5pwd does an ‘add principal’ operation instead of finding the principal first… For me it seems one would want to avoid such a situation, although it involves another if-branch to look up the principal and then add it if it doesn’t exist…
Anyway, thanks for this useful implementation, I hope you find some use for my comments too.
Regards,
Michael
23.08.2010
Petter is also creating a laptop client solution for ltsp!
http://people.skolelinux.org/pere/blog/Autodetecting_Client_setup_for_roaming_workstations_in_Debian_Edu.html
I think this is a huge step forwards.
26.08.2010
Hi!
Nice work there!
I wonder if it would be possible for you to backport it to krb5-1.6.1 / OpenLDAP 2.3.43.
I ask this for use with rhel/centos. I ( and many others probably ) would like to use smbkrb5pwd before we get our hands on rhel/centos 6 ( Who knows when it will be released… ).
If I had at least a good C knowledge I’d risk doind it, but…
29.08.2010
Unfortunately we have no plans on doing backports as we are using only 2.4.xx versions ourselves. I do not know how easily it could be backported as there probably have been quite a few changes in OpenLDAP. Maybe it would be possible to compile newer OpenLDAP from sources on RHEL and use the overlay with that?
08.09.2010
Firstly, thanks for your contribution to OpenLDAP and Kerberos.
I am having some issues getting this tool to work.
Currently, my LDAP server and Kerberos server are on the same machine. I have the tool set up and the correct ACLs, but when I try to actually change a password, ldappasswd just hangs and complains about a communications error. Log files report:
Sep 7 17:24:24 dc3 slapd[9812]: smbkrb5pwd conn=1025 op=1 : kadm5_chpass_principal() failed for user user@REALM: Communication failure with server
Sep 7 17:53:31 dc3 slapd[9964]: smbkrb5pwd conn=1009 op=1 : lock contention on kerberos mutex
08.09.2010
I was a bit too hasty, I have found the culprit.
I have set up my LDAP server to store kerberos information in the user records themselves, versus having a separate container to maintain them.
So users are in ou=users,dc=domain,dc=tld and the generic kerberos container is in cn=REALM at the root.
Changing a users’ password via ldappasswd does change their Kerberos password but does NOT change their LDAP or Samba passwords.
If I already have a user with a principal registered in their account, then the ldappasswd fails, I’m guessing because it can’t find the principal when it’s actually attached to the user account in another container.
This is a suggestion, and I have no idea how to do it in C, but maybe the password util should search for the record, if the record is missing the kerberos attributes, add them, else do the kerberos password update, to the userPassword update and the NT/LM password updates and only report failures for those passwords that were not successfully changed. I actually have a python password program that does this currently, but using expect is a poor substitute for a native solution.
08.09.2010
Could you give more details about the exact configuration you are using? I haven’t used MIT kerberos in such setting where kerberos information is in the user records, so I’d need to know a bit more about it.
smbkrb5pwd overlay itself doesn’t touch any kerberos records, but it always calls kadmin to do that. If one can change kerberos passwords through kadmin, the configuration is correct there.
The error message from the earlier comment might explain the problem:
Sep 7 17:53:31 dc3 slapd[9964]: smbkrb5pwd conn=1009 op=1 : lock contention on kerberos mutex
What could happen here is that when you call ldappasswd, the user entry is locked when smkrb5pwd overlay calls kadmin. Then kadmin tries to change the same entry, but as it is already locked, the change fails. Or actually, if kerberos password is changed, the entry gets locked when kadmin changes the entry and smbkrb5pwd cannot change the samba passwords anymore. The locking issues were one of the worries we had when doing the overlay, but in our configurations this hasn’t been a problem.
08.09.2010
The exact configuration I’m using essentially stores kerberos data with the user account outside of the normal kerberos principle containers in LDAP.
Normally, when I want to add an existing user to kerberos, I’ll use an extended property:
kadmin: addprinc -x “uid=$user,ou=people,ou=users,dc=domain,dc=tld”
I think you are correct as well – the record is locked when you try to update the other properties.