Ich habe unzählige Websites und Tutorials durchsucht, konnte jedoch keine Antwort auf mein Problem finden.
Ich habe OpenLDAP 2.4 auf einem OpenSUSE 12.3-Rechner mit einem Passwortrichtlinien-Overlay eingerichtet. Der Client ist ein Linux Mint 17.1-Rechner mit installierten Paketen libnss-ldap und libpam-ldap. Client und Server sind für die Verwendung von TLS mit selbstsignierten Zertifikaten konfiguriert (der Server fungiert als Zertifizierungsstelle und signiert sein eigenes Zertifikat). Alles funktioniert einwandfrei, bis ich das Attribut pwdReset: TRUEeinem Benutzer hinzufüge.
Meine Absicht ist es,zwingt den Benutzer, sein Passwort bei der nächsten Anmeldung zu ändern. Nach dem Setzen dieses Attributs kann sich der Benutzer jedoch nicht mehr authentifizieren: Wenn ich versuche, den Benutzer per „su“ zu verwenden (oder mich mit ihm anzumelden), erhalte ich die Fehlermeldung „Authentifizierung fehlgeschlagen“. Außerdem zeigt das Syslog die folgenden Meldungen an:
Mar 4 07:27:11 client-desktop nslcd[3198]: [90cde7] <authc="johndoe"> ldap_result() failed: Insufficient access: Operations are restricted to bind/unbind/abandon/StartTLS/modify password
Mar 4 07:27:11 client-desktop nslcd[3198]: [dcc233] <authc="johndoe"> cn=John Doe,ou=people,cd=domain,dc=com: lookup failed: Invalid credentials
Diese Meldungen sagen mir, dass die Benutzeranmeldeinformationen nicht mehr gültig sind, was logisch ist, da ich sein Passwort zurückgesetzt habe, der Benutzer aber nicht darauf hingewiesen wird, dass er sein Passwort ändern muss oder ähnliches. Außerdem möchte ich die Verwendung von OpenLDAP-Dienstprogrammen wie ldappasswd verhindern, da die Clients keine Experten sind. Daher möchte ich, dass sie weiterhin den typischen Passwd-Befehl verwenden, um ihre eigenen Passwörter zu ändern. Zumindest ist dies möglich, wenn pwdReset nicht festgelegt ist. Ich kann dieses Verhalten auch erreichen, indem ich das shadowLastChangeAttribut auf 0 setze, aber ich möchte alles mit Passwortrichtlinien machen, da ich auch versuche, die Verwendung von Passwörtern mit mindestens 8 Zeichen durchzusetzen. Diese Funktion funktioniert übrigens einwandfrei.
Dies ist ein Auszug meines Basis-DN, damit Sie überprüfen können, ob ich etwas übersehen habe. Beachten Sie, dass es pwdResetbeim Benutzer auf TRUE gesetzt ist und pwdMustChangedie Variable in der Richtlinie selbst auf TRUE gesetzt ist.
# John Doe, people, domain.com
dn: cn=John Doe,ou=people,dc=domain,dc=com
cn: John Doe
sn: Doe
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: johndoe
uidNumber: 1003
gidNumber: 1000
homeDirectory: /home/johndoe
loginShell: /bin/bash
userPassword: e1NTSEF9VWFSMDVsSGNIWFMxcnJ5VzBtaWRkOHFmTDE1ai9RYlQ=
pwdReset: TRUE # This attribute only appears if I explicitly request it
# policies, domain.com
dn: ou=policies,dc=domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
(Die folgenden Attribute gehören zu cn=default,ou=policies, aber aus irgendeinem Grund werden sie nicht angezeigt, wenn ich hier nichts schreibe)
pwdInHistory: 3
pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 30
pwdMustChange: TRUE
pwdSafeModify: FALSE
pwdAllowUserChange: TRUE
pwdFailureCountInterval: 0
pwdGraceAuthNLimit: 0
Und das ist die Konfiguration meines Backends und der Passwortrichtlinien:
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=domain,dc=com
olcAccess: {0}to attrs=userPassword by self write by * auth
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to attrs=userPKCS12 by self read by * none
olcAccess: {3}to * by * read
olcRootDN: cn=admin,dc=domain,dc=com
olcRootPW: {SSHA}############## omited
olcDbCacheSize: 10000
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 15000000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {4}set_lk_max_locks 30000
olcDbConfig: {5}set_lk_max_objects 30000
olcDbIDLcacheSize: 30000
olcDbIndex: objectclass eq
[...more indexes...]
# {0}ppolicy, {1}hdb, config
dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=domain,dc=com
olcPPolicyHashCleartext: TRUE
(Die folgenden beiden Attribute gehören auch zu {0}ppolicy)
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
Ich hoffe, dass jemand Licht in die Sache bringen kann. Ich bin für jede Hilfe sehr dankbar!
Grüße
Bearbeiten:
Ich habe einige Änderungen an der Standardrichtlinie vorgenommen, um zu verstehen, was die Benutzerauthentifizierung behindert hat. Ich habe festgestellt, dass die Benutzerauthentifizierung mit dem Fehler „su: Authentifizierungsfehler“ fehlschlägt, wenn pwdMustChangeauf TRUE gesetzt ist und pwdResetauch auf TRUE gesetzt ist (dieses Mal beim Benutzereintrag). Wenn jedoch pwdResetTRUE und pwdMustChangeFALSE ist, kann ich mich mit diesem Benutzer so oft anmelden, wie ich möchte. Ich denke, dass es nutzlos und nicht intuitiv ist, hierfür zwei Variablen zu haben. Stattdessen sollte eine einzelne Variable nur beim Benutzereintrag verwendet werden, egal wie Sie sie nennen möchten, entweder pwdResetoder pwdMustChange.
Antwort1
Richtlinien auf dem LDAP-Server entsprechen nicht unbedingt den Richtlinien innerhalb des Betriebssystems. Sie scheinen sich ein Framework vorzustellen, in dem Sie diese Overflay-Eigenschaft festlegen und dieBetriebssystemwird sich der Notwendigkeit einer Kennwortänderung bewusst, aber wie Sie sehen, funktioniert das nicht.
Um eine Eingabeaufforderung im Betriebssystem auszulösen, muss ein Abrechnungsmodul (normalerweise PAM) den Zustand bemerken. Die Kennwortrichtlinienüberlagerung von OpenLDAP ist kein POSIX-Standard. Anders als beim Anpassen der shadowEigenschaften eines Benutzers zum Festlegen der Richtlinie pam_unixhat OpenLDAP keine Kenntnis von den Attributen, die Sie festlegen. Das Gleiche kann vom OpenLDAP-Server selbst nicht gesagt werden. Dies führt zu einer Benutzersperrung, da sich der Benutzer nicht beim Linux-Server authentifizieren kann und nicht über ausreichende Informationen zu LDAP verfügt (wie Sie selbst anmerken), um direkt mit dem LDAP-Server zusammenzuarbeiten und sein Kennwort zu ändern.
Wenn Sie Aufforderungen zur Kennwortänderung innerhalb des Betriebssystems auslösen möchten, ist dies nicht das richtige Tool für diese Aufgabe. Ich persönlich würde empfehlen, dass Sie sich mit den relevanten shadowAttributen vertraut machen, sie in LDAP speichern, wenn sie zentral verwaltet werden müssen, und diese verwenden, um die gewünschten Verhaltensweisen auszulösen.
Aus der pam_unix(8)Manpage:
Die Kontokomponente führt die Aufgabe aus, den Status des Benutzerkontos und des Passworts basierend auf den folgenden Schattenelementen zu ermitteln: expire, last_change, max_change, min_change, warn_change. Im letzteren Fall kann sie dem Benutzer Ratschläge zum Ändern seines Passworts geben oder durch die Rückgabe von PAM_AUTHTOKEN_REQD die Bereitstellung des Dienstes für den Benutzer verzögern, bis dieser ein neues Passwort festgelegt hat. Die oben aufgeführten Einträge sind in der Handbuchseite shadow(5) dokumentiert. Sollte der Datensatz des Benutzers einen oder mehrere dieser Einträge nicht enthalten, wird die entsprechende Schattenprüfung nicht durchgeführt.