Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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)

share|improve this question
    
This is a masterfully-written question. I wish I could help you with it... –  gWaldo Nov 5 '10 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!

share|improve this answer
    
have you tried running it together with ppolicy? –  Hubert Kario Nov 5 '10 at 22:49
    
No. Please try it and let me know how it goes. –  200_success Nov 9 '10 at 22:44
    
It looks like either ppolicy or smbk5pwd overlays in Debian squeeze OpenLDAP do update shadowLastChange. Yay for Debian! –  Hubert Kario Dec 20 '11 at 18:22

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

#!/bin/sh
# 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

LDAP_MODIFY="/usr/bin/ldapmodify"
LDAP_SEARCH="/usr/bin/ldapsearch"
LDAP_USER="uid=shadow-update,ou=Services,dc=example,dc=com"
LDAP_PASSWORD="change-me"
LDAP_HOST="localhost"

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

# get user login name
user=$1

# find user's DN
dn=$($LDAP_SEARCH -x -h $LDAP_HOST -LLL -b dc=example,dc=com "(uid=$user)" dn)
dn=${dn#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
else
        # 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
fi

err=$?

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
   exit;
fi

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.

share|improve this answer

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

share|improve this answer
up vote 0 down vote accepted

(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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.