OpenLDAP, Samba e invecchiamento della password

Sto configurando un sistema in cui tutte le risorse IT sono disponibili attraverso una singola coppia password utente, sia esso l'accesso alla shell sui server, il login al dominio Samba, WiFi, OpenVPN, Mantis, ecc. (Con accesso a servizi specifici governati in base all'appartenenza al gruppo o ai campi oggetto utente). Poiché disponiamo di dati personali nella nostra rete, dobbiamo implementare l'invecchiamento della password, come previsto dalla Direttiva sulla protezione dei dati dell'UE (o meglio dalla sua versione polacca).

Il problema è che gli account Samba e POSIX in LDAP utilizzano diverse informazioni di hashing e invecchiamento della password. Durante la sincronizzazione delle password stessi è facile (la ldap password sync = Yesa smb.conf), l'aggiunta di una password di invecchiamento per le pause mescolare le cose: Samba non aggiorna shadowLastChange. Insieme a obey pam restrictions = Yescrea un sistema in cui un utente di Windows non può cambiare la password obsoleta, ma se non la utilizzo, le home directory non verranno create automaticamente. L'alternativa è usare l'uso dell'operazione estesa LDAP per cambiare la password, ma smbk5pwdneanche il modulo lo imposta. Quel che è peggio, il manutentore di OpenLDAP non lo aggiornerà / accetterà le patch poiché questo campo è considerato deprecato.

Quindi, la mia domanda è: qual è la soluzione migliore? Quali sono i loro lati positivi e negativi?

1. Utilizzare LDAP ppolicye l'invecchiamento della password LDAP interna?

   1. Funziona bene con NSS, moduli PAM, samba, altri sistemi?
   2. I moduli NSS e PAM devono essere configurati in modo speciale per utilizzare ppolicy, non shadow?
   3. Non GOsa² lavorare con ppolicy?
   4. Esistono altri strumenti di amministrazione che possono funzionare con ppolicyLDAP abilitato?

2. Hack insieme uno script di modifica password che aggiorna il campo in LDAP. (lasciando la possibilità che l'utente stesso aggiorni il campo senza cambiare la password)

Ho scritto il mio overlay OpenLDAP chiamato shadowlastchangeper aggiornare l' shadowLastChangeattributo ogni volta che si verifica una modifica della password EXOP. Si attiva in slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Ho configurato smb.confper modificare le password tramite EXOP:

ldap passwd sync = Only

Quindi, per ciascun account, impostare shadowMaxil numero di giorni in cui una password è valida. I moduli OpenLDAP si occupano del resto!

Come stop-gap ho creato uno script per Samba che aggiornerà la modifica della shadowLastChangepassword:

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

Nella configurazione di Samba deve essere unix password syncimpostato su yes, passwd chatimpostato su *OK*e passwd programsopra lo script con "%u"come param.

È LDAP_USERnecessario creare un account specificato in LDAP e disporre delle autorizzazioni per leggere su uidtutti gli utenti Samba e il diritto di scrivere shadowLastChange.

(lavori in corso, aggiungerò i dettagli più avanti)

Buone notizie a tutti! Ho fatto funzionare tutto, più o meno ..., in un ambiente di test ...:

1. Politica di password (entrambi qualità- e tempo-saggio) è applicata a livello di OpenLDAP (grazie a ppolicy, not24gete passwdqc)
2. Le password sono sincronizzate tra Samba e POSIX in entrambi i modi (grazie a smbk5pwd). Nota: il controllo di qualità con Samba e ppolicy non è ovvio: il password check script( pwqcheck -1da passwdqc) deve eseguire gli stessi controlli del LDAP oppure l'utente riceverà un'Autorizzazione negata invece di "Password troppo semplice, prova diversamente".
3. Sia PAM che Samba avvisano l'utente che la password scadrà presto.
4. Le directory degli utenti vengono create utilizzandopam_mkhomedir
5. L'implementazione GOsa² degli inserti RFC2307bis (e dello schema associato) uidnelle voci di gruppo, quindi le applicazioni che prevedono NIS (la maggior parte degli elementi "UNIXy") o lo schema RFC2307bis (la maggior parte delle applicazioni "progettate per AD") funzionano bene.

L'unico problema è che la disabilitazione di un account richiede l'uso di strumenti CLI (o la scrittura di script postmodify GOsa) o l'account non verrà bloccato a livello LDAP, solo per PAM e Samba. La scadenza della password verrà comunque applicata, quindi non è un grosso problema.

Ho la risposta di uno degli sviluppatori GOsa. Al momento GOsa non supporta in alcun modo la sovrapposizione di PPolicy.