Sync the LDAP and the Samba Passwords Using the smbkrb5pwd Overlay on Ubuntu 12.04

The smbkrb5pwd overlay (module, if you like) is used to synchronise the passwords changed in OpenLDAP with the Samba and MIT Kerberos passwords stored in the LDAP-server. For this, the module (overlay, if you like :)) uses the exop of OpenLDAP.
(Ez a cikk magyarul is olvasható.)
The source of the overlay can be downloaded form here. To my best knowledge it is made by Velli-Matti, working at the Finnish Opinsys. The first blogpost showing how to use it is was published on the Opinsys developer blog. So let us begin with the compiling.
To be able to compile the module, first you need a fresh compilation of the OpenLDAP so we make this first. (It is not the OpenLDAP that will be running on our server. We continue using the official Ubuntu package. This one is needed only for the compiling of the smbkrb5pwd overlay.)
We install everything needed for the compilation of slapd :

sudo apt-get build-dep slapd

A package called heimdal-dev will be installed and with that we are goung to have some kind of trouble. When ready, download and comile the source. Compiling is reatively fast but the testing is soooooo long. No joking. An hour or so.

sudo apt-get -b source slapd

We need a nice unzip:

sudo apt-get install unzip

And we unzip:

sudo unzip opinsys-smbkrb5pwd-19e5454.zip -d openldap-2.4.28/contrib/slapd-modules/

Going there, renaming, entering::

cd openldap-2.4.28/contrib/slapd-modules/
sudo mv opinsys-smbkrb5pwd-19e5454/ smbkrb5passwd
cd smbkrb5passwd/

Compiling is done by the make command. It is going to die at given steps unless we take the nessecary precaution:

sudo apt-get install libkrb5-dev libssl-dev

During this the heimdal-dev package will be removed, but we do need a file from there. It's palce depends on the architecture of your system - you need to put the libgssapi.la in the directory /usr/lib/x86_64-linux-gnu/libgssapi.la on a 64 bit system. We are only downloading the package (watch the -d switch):

sudo apt-get -d install heimdal-dev

We extract the file we need:

sudo sh -c "dpkg --fsys-tarfile /var/cache/apt/archives/heimdal-dev_1.6~git20120311.dfsg.1-2_amd64.deb | tar xOf - ./usr/lib/x86_64-linux-gnu/libgssapi.la >/usr/lib/x86_64-linux-gnu/libgssapi.la"

Compiling (takes only a few seconds):

sudo make

And we put our nice fresh shiny nem module into its folder:

sudo cp .libs/* /usr/lib/ldap/

So far so good. Before we start using it, let us try two things. The frist is to change the password of a user as LDAP-admin:

ldappasswd -D cn=admin,dc=itthon,dc=cucc -w secret -s newpassword uid=suser1,ou=People,dc=itthon,dc=cucc

If you've set stats loglevel for your slapd then in the /var/log/syslog you will see this:

slapd[1287]: conn=1199 fd=24 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
conn=1199 op=0 BIND dn="cn=admin,dc=itthon,dc=cucc" method=128
slapd[1287]: conn=1199 op=0 BIND dn="cn=admin,dc=itthon,dc=cucc" mech=SIMPLE ssf=0
slapd[1287]: conn=1199 op=0 RESULT tag=97 err=0 text=
slapd[1287]: conn=1199 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1
slapd[1287]: conn=1199 op=1 PASSMOD id="uid=suser1,ou=People,dc=itthon,dc=cucc" new
slapd[1287]: conn=1199 op=1 RESULT oid= err=0 text=
slapd[1287]: conn=1199 op=2 UNBIND
slapd[1287]: conn=1199 fd=24 closed

Now logon using suser1 (and newpassword) to a Linux client and change your password using the passwd command. The syslog of the server shows this:

slapd[1287]: conn=1207 op=2 BIND dn="uid=suser1,ou=People,dc=itthon,dc=cucc" method=128
slapd[1287]: conn=1207 op=2 BIND dn="uid=suser1,ou=People,dc=itthon,dc=cucc" mech=SIMPLE ssf=0
slapd[1287]: conn=1207 op=2 RESULT tag=97 err=0 text=
slapd[1287]: conn=1207 op=3 BIND anonymous mech=implicit ssf=0
slapd[1287]: conn=1207 op=3 BIND dn="" method=128
slapd[1287]: conn=1207 op=3 RESULT tag=97 err=0 text=
slapd[1287]: conn=1207 op=4 BIND dn="uid=suser1,ou=People,dc=itthon,dc=cucc" method=128
slapd[1287]: conn=1207 op=4 BIND dn="uid=suser1,ou=People,dc=itthon,dc=cucc" mech=SIMPLE ssf=0
slapd[1287]: conn=1207 op=4 RESULT tag=97 err=0 text=
slapd[1287]: conn=1207 op=5 MOD dn="uid=suser1,ou=People,dc=itthon,dc=cucc"
slapd[1287]: conn=1207 op=5 MOD attr=userPassword
slapd[1287]: conn=1207 op=5 RESULT tag=103 err=0 text=
slapd[1287]: conn=1207 op=6 MOD dn="uid=suser1,ou=People,dc=itthon,dc=cucc"
slapd[1287]: conn=1207 op=6 MOD attr=shadowLastChange
slapd[1287]: conn=1207 op=6 RESULT tag=103 err=0 text=
slapd[1287]: conn=1207 op=7 UNBIND
slapd[1287]: conn=1207 fd=27 closed
slapd[1287]: conn=1206 op=4 UNBIND
slapd[1287]: conn=1206 fd=26 closed

None of the two methods changes the attribute sambaNTPassword or the Kerberos-password. But using the first one you can observe an important event. You can see PASSMOD instead of MOD and right before it you have and EXT oid standing for exop-id stading for extended operation id. The first method does not directly write the value of the userPassword method but calls the LDAP: "Hey, change that password for me!" When this happens the LDAP is capable to do other things besides changing the password. Changing other passwords for example. If you ask it nicely. And now we are just about doing that. Let us ignite our shiny new module.

Create the file smbkrb5pwd_load.ldif :

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: smbkrb5pwd

Add it to the LDAP:

sudo ldapmodify -Y EXTERNAL -f smbkrb5pwd_load.ldif

Look at what happened:

sudo ldapsearch -Y EXTERNAL -b cn=module{0},cn=config 

Create the file smbkrb5pwd_setup.ldif (we only use the overlay for Samba sync right now -  the Kerberos setup is a bit more complicated and I will post about that later):

dn: olcOverlay=smbkrb5pwd,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSmbKrb5PwdConfig
olcOverlay: {1}smbkrb5pwd
olcSmbKrb5PwdEnable: samba
olcSmbKrb5PwdMustChange: 2592000
olcSmbKrb5PwdRequiredClass: posixAccount

Add it to the LDAP:

sudo ldapadd -Y EXTERNAL -f smbkrb5pwd_setup.ldif

Look at what happened:

sudo ldapsearch -Y EXTERNAL -b olcDatabase={1}hdb,cn=config

If you issue the ldappaswd command now the syslog will show nothing new although the extended operation (exop) is performed and the Samba password will change. We achieved the userPassword - sambaNTPassword sync! Olé!
One thing to worry about is that we have just seen that the exop does not run when we use the  passwd command on the client. This can be solved by edithing the file /etc/ldap.conf .

• Comment out pam_password md5
• Uncomment  pam_password exop .

So the password changed on Linuxon is propagated toWindows.

Now our favorite user cannot change her password using Windows. When looking at the problem closely you see that the password is changed but Windows gives an error message (translated back form Hungarian, so the exact wording may be different): The user name or password is incorrect. Lower- and uppercase letters are not the same. (XP). So the password is changed but this error message is kind of embarassing. Why do we keep getting it?
Let us think for a while: in the file smb.conf the setting ldap passwd sync = yes causes Samba to change the userPassword filed too and this in turn causes LDAP's smbkrb5pwd overlay to change the sambaNTPassword attribute being updated by Samba itself.
The solution is to change ldap passwd sync = yes to ldap passwd sync = only in the file smb.conf followed by a humble

sudo service smbd restart

command.

Wow. That is cool.

Further reading:
http://easierbuntu.blogspot.com/2008/05/using-apt-get-to-compile-from-source.html
http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html