Frage OpenLDAP, Samba und Passwortalterung


Ich konfiguriere ein System, in dem alle IT-Ressourcen durch ein einziges Benutzer-Passwort-Paar verfügbar sind, sei es Zugriff auf die Shell auf den Servern, Protokollierung auf Samba-Domain, WiFi, OpenVPN, Mantis, etc. (mit Zugriff auf bestimmte Dienste) nach Gruppenmitgliedschaft oder Benutzerobjektfeldern). Da wir in unserem Netzwerk personenbezogene Daten haben, müssen wir gemäß der EU-Datenschutzrichtlinie (oder besser der polnischen Version) eine Passwortalterung implementieren.

Das Problem ist, dass Samba und POSIX-Konten in LDAP verschiedene Hashing- und Alterungsinformationen verwenden. Während der Synchronisierung der Passwörter selbst ist einfach (die ldap password sync = Yes im smb.conf), das Hinzufügen von Passwort Aging zu dem Mix bricht Dinge: Samba ShadowLastChange nicht aktualisieren. Zusammen mit obey pam restrictions = Yes erstellt ein System, in dem ein Windows-Benutzer altes Passwort nicht ändern kann, aber wenn ich es nicht verwende, werden Home-Verzeichnisse nicht automatisch erstellt. Die Alternative besteht darin, den erweiterten LDAP-Vorgang für die Kennwortänderung zu verwenden, aber das smbk5pwd Modul setzt es auch nicht. Was noch schlimmer ist, der OpenLDAP-Betreuer wird es nicht aktualisieren / Patches akzeptieren, da dieses Feld als veraltet gilt.

Also, meine Frage ist, was ist die beste Lösung? Was sind die Vor- und Nachteile von ihnen?

  1. Verwenden Sie LDAP ppolicy und interne LDAP-Passwortalterung?

    1. Wie gut funktioniert es mit NSS, PAM-Modulen, Samba, anderen Systemen?
    2. Müssen die NSS- und PAM-Module speziell konfiguriert werden, um ppolicy und nicht Schatten zu verwenden?
    3. Tut GOsa² Arbeit mit ppolicy?
    4. Gibt es andere Verwaltungstools, mit denen gearbeitet werden kann? ppolicy-aktiviertes LDAP?
  2. Hack ein Change-Passwort-Skript, das das Feld in LDAP aktualisiert. (unter der Möglichkeit, dass der Benutzer selbst das Feld aktualisiert, ohne das Passwort zu ändern)


13
2017-09-29 18:35


Ursprung


Dies ist eine meisterhaft geschriebene Frage. Ich wünschte ich könnte dir damit helfen ... - gWaldo


Antworten:


Ich habe mein eigenes OpenLDAP-Overlay geschrieben shadowlastchange aktualisieren shadowLastChange Attribut, wenn eine EXOP-Passwortänderung auftritt. Es ist aktiviert in slapd.conf:

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

Ich habe konfiguriert smb.conf Passwörter über EXOP ändern:

ldap passwd sync = Only

Stellen Sie dann für jedes Konto ein shadowMax zu der Anzahl von Tagen, die ein Passwort gültig ist. Die OpenLDAP-Module kümmern sich um den Rest!


1
2017-11-05 20:29



hast du versucht, es zusammen mit ppolicy laufen zu lassen? - Hubert Kario
Nein. Bitte versuchen Sie es und lassen Sie mich wissen, wie es geht. - 200_success
Es sieht genauso aus ppolicy oder smbk5pwd Überlagerungen in Debian Squeeze OpenLDAP tun aktualisieren shadowLastChange. Yay für Debian! - Hubert Kario


Als Stop-Gap habe ich ein Skript für Samba erstellt, das den shadowLastChange bei Passwortänderung:

#!/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-Konfiguration benötigt es unix password sync einstellen yes, passwd chat einstellen *OK* und passwd program zu über Skript mit "%u" als param.

Ein Konto in angegeben LDAP_USER muss in LDAP erstellt und mit Berechtigungen zum Lesen versehen werden uid aller Samba-Benutzer und das Recht zu schreiben shadowLastChange.


1
2017-11-05 19:01





(in Arbeit, ich werde später Details hinzufügen)

Gute Nachrichten, Leute! Ich habe das Ganze mehr oder weniger ... in einer Testumgebung funktionieren lassen ...:

  1. Passwortrichtlinien (sowohl in qualitativer als auch in zeitlicher Hinsicht) werden auf OpenLDAP-Ebene durchgesetzt (dank ppolicy, not24get und passwdqc)
  2. Passwörter werden auf beide Arten zwischen Samba und POSIX synchronisiert (dank smbk5pwd). Hinweis: Qualitätsprüfung mit Samba und ppolicy ist nicht offensichtlich: die password check script(pwqcheck -1 von passwdqc) muss die gleichen Prüfungen durchführen, die das LDAP macht, oder der Benutzer erhält eine Erlaubnis verweigert statt "Zu einfaches Passwort, versuche es anders".
  3. Sowohl PAM als auch Samba warnen den Benutzer, dass das Passwort bald abläuft.
  4. Benutzerverzeichnisse sind erstellt mit pam_mkhomedir
  5. GOsa² Implementierung von RFC2307bis (und zugehörigen Schema) -Einfügungen uid um Einträge zu gruppieren, so dass Anwendungen, die entweder NIS (das meiste "UNIXy" -Stück) oder RFC2307bis-Schema (die meisten "für AD-Anwendungen") erwarten, gut funktionieren.

Das einzige Problem ist, dass die Deaktivierung eines Kontos die Verwendung von CLI-Tools erfordert (oder das Schreiben eines GOsa Postmodify-Skripts) oder dass das Konto nicht auf LDAP-Ebene gesperrt wird, nur für PAM und Samba. Der Ablauf des Passworts wird weiterhin erzwungen, es ist also kein großes Problem.


1
2017-12-20 18:52





Ich habe eine Antwort von einem der GOsa-Entwickler bekommen. Zu diesem Zeitpunkt unterstützt GOsa das ppolicy-Overlay in keiner Weise.


0
2017-11-09 14:42