I'm configuring a system in which all IT resources are available through a single user-password pair, be it access to shell on the servers, logging to Samba domain, WiFi, OpenVPN, Mantis, etc. (with access to specific services governed by group membership or user object fields). Because we have personal data in our network, we need to implement password aging, as per the EU Data Protection Directive (or rather the Polish version of it).

The problem is that Samba and POSIX accounts in LDAP use different password hashing and aging information. While synchronizing the passwords themselves is easy (the ldap password sync = Yes in smb.conf), adding password aging to the mix breaks things: Samba doesn't update shadowLastChange. Together with obey pam restrictions = Yes creates a system in which a windows user can't change aged password, but if I don't use it, home directories won't be automatically created. The alternative is to use use LDAP extended operation for password changing, but the smbk5pwd module doesn't set it either. What's worse, the OpenLDAP maintainer won't update it/accept patches as this field is considered deprecated.

So, my question is, what is the best solution? What are the up- and downsides of them?

  1. Use LDAP ppolicy and internal LDAP password aging?

    1. How well does it work with NSS, PAM modules, samba, other systems?
    2. Do the NSS and PAM modules need to be configured in special way to use ppolicy, not shadow?
    3. Does GOsa² work with ppolicy?
    4. Are there other administrative tools that can work with ppolicy-enabled LDAP?
  2. Hack together a change password script that updates the field in LDAP. (leaving the possibility that the user himself will update the field without changing password)

  • This is a masterfully-written question. I wish I could help you with it...
    – gWaldo
    Nov 5, 2010 at 12:18

4 Answers 4


I wrote my own OpenLDAP overlay called shadowlastchange to update the shadowLastChange attribute whenever an EXOP password change occurs. It is activated in slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange

database bdb
overlay smbk5pwd
overlay shadowlastchange

I have configured smb.conf to change passwords via EXOP:

ldap passwd sync = Only

Then, for each account, set shadowMax to the number of days a password is valid. The OpenLDAP modules take care of the rest!

  • have you tried running it together with ppolicy? Nov 5, 2010 at 22:49
  • No. Please try it and let me know how it goes. Nov 9, 2010 at 22:44
  • It looks like either ppolicy or smbk5pwd overlays in Debian squeeze OpenLDAP do update shadowLastChange. Yay for Debian! Dec 20, 2011 at 18:22

As a stop-gap I created script for Samba that will update the shadowLastChange on password change:

# script to update shadowLastChange when samba updates passwords
# it's not needed when using 'passwd', it does update the field,
# even if pam_ldap is using LDAP Extented Operation to change password


# get date
SLC=$((`date '+%s'` / 24 / 3600))

# get user login name

# find user's DN
dn=$($LDAP_SEARCH -x -h $LDAP_HOST -LLL -b dc=example,dc=com "(uid=$user)" dn)

# check if DN is not base64 encoded
if [ "${dn:0:1}" = ":" ]; then
        # update password change date
        echo "dn:$dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
        # update password change date
        echo "dn: $dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1


if [ ! $err -eq 0 ]; then
   echo "error: can't update shadowLastChange: $err"
   echo "`date`: shadow.sh: can't update shadowLastChange: $err"\
       >> /var/log/shadow-update.log

echo OK

In Samba config it needs unix password sync set to yes, passwd chat set to *OK* and passwd program to above script with "%u" as param.

An account specified in LDAP_USER needs to be created in LDAP and given permissions to read on uid of all Samba users and the right to write shadowLastChange.


(work in progress, I'll add details later)

Good news everyone! I got the whole thing working, more or less..., in a testing environment...:

  1. Password policy (both quality- and time-wise) is enforced on OpenLDAP level (thanks to ppolicy, not24get and passwdqc)
  2. Passwords are synchronised between Samba and POSIX in both ways (thanks to smbk5pwd). Note: Quality checking with Samba and ppolicy is non obvious: the password check script (pwqcheck -1 from passwdqc) needs to perform the same checks the LDAP does or the user will get a Permission Denied instead of "Too easy password, try different".
  3. Both PAM and Samba warn the user that the password will soon expire.
  4. User directories are created using pam_mkhomedir
  5. GOsa² implementation of RFC2307bis (and associated schema) inserts uid to group entries, so applications expecting either NIS (most of "UNIXy" stuff) or RFC2307bis schema (most of "designed for AD" applications) work just fine.

The only problem is that disabling an account requires use of CLI tools (or writing GOsa postmodify script) or the account won't be locked at LDAP level, just for PAM and Samba. The password expiration will still be enforced, so it's not a big problem.


I've got answer from one of the GOsa developers. At this time GOsa does not support ppolicy overlay in any way.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .