OpenLDAP, Samba und Passwortalterung

Ich konfiguriere ein System, in dem alle IT-Ressourcen über ein einzelnes Benutzer-Kennwort-Paar verfügbar sind, sei es der Zugriff auf die Shell auf den Servern, die Anmeldung bei Samba-Domänen, WLAN, OpenVPN, Mantis usw. (wobei der Zugriff auf bestimmte Dienste geregelt wird) nach Gruppenmitgliedschaft oder Benutzerobjektfeldern). Da wir über personenbezogene Daten in unserem Netzwerk verfügen, müssen wir die Kennwortalterung gemäß der EU-Datenschutzrichtlinie (bzw. der polnischen Version davon) implementieren.

Das Problem ist, dass Samba und POSIX-Konten in LDAP unterschiedliche Informationen zu Kennwort-Hashing und Alterung verwenden. Während die Passwörter zu synchronisieren , ist sich leicht (das ldap password sync = Yesin smb.conf), Passwort zusätzlich zu den Mix Pausen Dinge Altern: Samba nicht shadowLastChange nicht aktualisiert. obey pam restrictions = YesErstellt zusammen mit ein System, in dem ein Windows-Benutzer das veraltete Kennwort nicht ändern kann. Wenn ich es jedoch nicht verwende, werden Ausgangsverzeichnisse nicht automatisch erstellt. Die Alternative besteht darin, den erweiterten LDAP-Vorgang zum Ändern des Kennworts zu verwenden, das smbk5pwdModul legt dies jedoch ebenfalls nicht fest. Was noch schlimmer ist, der OpenLDAP-Betreuer aktualisiert es nicht und akzeptiert keine Patches, da dieses Feld als veraltet gilt.

Meine Frage ist also, was ist die beste Lösung? Was sind die Vor- und Nachteile?

1. Verwenden Sie LDAP ppolicyund interne LDAP-Passwortalterung?

   1. Wie gut funktioniert es mit NSS, PAM-Modulen, Samba und anderen Systemen?
   2. Müssen die NSS- und PAM-Module speziell konfiguriert werden, um ppolicy und nicht shadow zu verwenden?
   3. Funktioniert GOsa² mit ppolicy?
   4. Gibt es andere Verwaltungstools, die mit ppolicyaktiviertem LDAP arbeiten können?

2. Zerhacken Sie ein Skript zum Ändern des Kennworts, das das Feld in LDAP aktualisiert. (Es besteht die Möglichkeit, dass der Benutzer das Feld selbst aktualisiert, ohne das Passwort zu ändern.)

Ich habe mein eigenes OpenLDAP-Overlay geschrieben, das aufgerufen wird shadowlastchange, um das shadowLastChangeAttribut bei jeder EXOP-Kennwortänderung zu aktualisieren . Es ist aktiviert in slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Ich habe smb.confdas Ändern von Passwörtern über EXOP konfiguriert:

ldap passwd sync = Only

Stellen Sie dann für jedes Konto shadowMaxdie Anzahl der Tage ein , für die ein Kennwort gültig ist. Die OpenLDAP-Module erledigen den Rest!

Als Notlösung habe ich ein Skript für Samba erstellt, das die Änderung des shadowLastChangePassworts aktualisiert :

#!/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 der Samba-Konfiguration muss unix password syncdas Skript mit as param auf yes, passwd chatauf *OK*und passwd programüber "%u"gesetzt werden.

Ein in angegebenes Konto LDAP_USERmuss in LDAP erstellt werden und die Berechtigung zum Lesen uidaller Samba-Benutzer und zum Schreiben haben shadowLastChange.

(In Arbeit, Details später)

Gute Nachrichten, Leute! Ich habe das Ganze mehr oder weniger ... in einer Testumgebung zum Laufen gebracht ...:

1. Die Kennwortrichtlinie (sowohl in Bezug auf die Qualität als auch in Bezug auf die Zeit) wird auf OpenLDAP-Ebene durchgesetzt (dank ppolicy, not24getund passwdqc).
2. Passwörter werden zwischen Samba und POSIX auf beide Arten synchronisiert (danke an smbk5pwd). Hinweis: Die Qualitätsprüfung mit Samba und ppolicy ist nicht offensichtlich: Das password check script( pwqcheck -1von passwdqc) muss die gleichen Prüfungen durchführen, die das LDAP durchführt, oder der Benutzer erhält eine verweigerte Berechtigung anstelle von "Zu einfaches Kennwort, versuchen Sie es anders".
3. Sowohl PAM als auch Samba warnen den Benutzer, dass das Kennwort bald abläuft.
4. Benutzerverzeichnisse werden mit erstelltpam_mkhomedir
5. Die GOsa²-Implementierung von RFC2307bis-Einfügungen (und des zugehörigen Schemas) uidin Gruppeneinträge, sodass Anwendungen, die entweder das NIS-Schema (die meisten "UNIXy" -Anwendungen) oder das RFC2307bis-Schema (die meisten "für AD entworfenen" Anwendungen) erwarten, problemlos funktionieren.

Das einzige Problem ist, dass zum Deaktivieren eines Kontos die Verwendung von CLI-Tools (oder das Schreiben eines GOsa-Postmodify-Skripts) erforderlich ist. Andernfalls wird das Konto nur für PAM und Samba auf LDAP-Ebene nicht gesperrt. Der Kennwortablauf wird weiterhin erzwungen, sodass dies kein großes Problem darstellt.

Ich habe eine Antwort von einem der GOsa-Entwickler. Derzeit unterstützt GOsa keine Richtlinienüberlagerungen.