Zusammenfassung

  • RFC 3062 machte die Passwortänderung unabhängig davon, ob eine Identität als DN dargestellt wurde und ob das Passwort als Attribut eines LDAP-Eintrags vorlag.
  • Der Server durfte erst nach einer erfolgreichen Änderung Erfolg melden und musste das Passwort bei einem Fehlschlag unverändert lassen. Das belegt weder eine spätere Anmeldung noch die Verteilung an alle externen Dienste.

Der Eintrag konnte am falschen Ort liegen

LDAP Modify ändert Attribute eines bestimmten Verzeichniseintrags. Das passt, wenn ein Benutzer einen Distinguished Name (DN) hat und sein Passwort etwa im Attribut userPassword gespeichert ist. Mit externen Authentifizierungsdiensten wurde diese Annahme brüchig: Eine Identität konnte kein DN sein, und der Dienst konnte das Passwort außerhalb des Verzeichnisses halten. Eine Änderung am LDAP-Eintrag änderte dann nicht zwingend das Geheimnis, das bei der Anmeldung geprüft wurde.

Kurt Zeilenga veröffentlichte RFC 3062 im Februar 2001 als eigene Operation, statt jedes Passwort zum Attribut umzudeuten. Die Password-Modify-Extended-Operation trägt die OID 1.3.6.1.4.1.4203.1.11.1. Eine Anfrage darf userIdentity, oldPasswd und newPasswd enthalten; jedes Feld ist optional. Der RFC beschreibt den Änderungsaufruf, nicht ein einheitliches Speicherlayout.

Sitzungsidentität oder explizite Kennung

Ist userIdentity vorhanden, kann sein Oktettstring ein LDAP-DN sein, muss es aber nicht. Fehlt das Feld, gilt die Anfrage dem Benutzer, der der aktuellen LDAP-Sitzung zugeordnet ist. Der Client kann also auf die bereits gebundene Identität zurückgreifen oder eine Form übermitteln, die der Server versteht. Keine Variante verrät dem Client, wo das Passwort liegt oder wie der Server die Identität dem änderbaren Geheimnis zuordnet.

Das ist die architektonische Verschiebung: LDAP stellt eine gemeinsame Anforderungsgrenze bereit, ohne das Passwort zum Verzeichnisattribut zu erklären. Der Server kann ein Attribut, einen anderen Speicher oder einen externen Authentifizierungsdienst verwenden. RFC 3062 lässt diese Modelle zu, beschreibt aber keine konkrete Implementierung und garantiert keine einheitliche Identitätsauflösung.

Ein Erfolg mit klarer Grenze

Der Server darf Erfolg nur melden, nachdem er das Benutzerpasswort erfolgreich geändert hat. Andernfalls muss er es unverändert lassen und einen Nicht-Erfolg zurückgeben. Ein falsches mitgeliefertes altes Passwort darf die Änderung ebenfalls nicht auslösen. Lässt der Client newPasswd aus, muss der Server ein Passwort erzeugen und es bei Erfolg als genPasswd zurückgeben oder fehlschlagen. Fehlt oldPasswd, darf eine andere Serverrichtlinie über die Erlaubnis entscheiden; Administratoren dürfen die Operation einschränken.

Damit gibt es eine nützliche Commit-Grenze: Die Antwort soll zwischen abgeschlossener Änderung und fehlgeschlagenem Versuch unterscheiden. Sie ist aber kein Ende-zu-Ende-Nachweis für eine Anmeldung. Sie beweist weder, dass ein späterer Bind gelingt, noch dass alle Replikate eines externen Dienstes den neuen Wert erhalten haben, der Benutzer ein erzeugtes Passwort sicher kennt oder eine Identität einer bestimmten realen Person gehört. Dafür braucht es jeweils andere Evidenz.

Fähigkeitsanzeige ist kontextabhängig

RFC 3062 empfiehlt, die OID im supportedExtension-Attribut des Root DSE anzubieten, und Clients sollen vor dem Aufruf nachsehen. Der Server darf die Erweiterung jedoch nur dann anzeigen, wenn der Client berechtigt ist und/oder der erforderliche Schutz besteht. Die sichtbare Fähigkeit kann somit von der Sitzung abhängen. Fehlt die OID in einer Antwort, beschreibt das zunächst diesen Kontext – nicht zwingend jeden Principal oder Zugangsweg.

Die Operation selbst liefert weder Vertraulichkeit noch Integrität. RFC 3062 untersagt anonyme Nutzung und verlangt Vertraulichkeitsschutz, etwa TLS. Alte und neue Passwörter können in der Anfrage stehen; ein erzeugtes Passwort kann in der Antwort zurückkommen. Eine Verbindung zu einem externen Geheimnisspeicher hilft nicht, wenn sie das Geheimnis auf dem Transport preisgibt.

RFC 3062 definierte die Erweiterung im LDAPv3-Rahmen von RFC 2251. RFC 4511 löste RFC 2251 später ab und beschreibt den allgemeinen Aufbau von ExtendedRequest und ExtendedResponse. Diese Entwicklung erklärt die Protokollhülle, belegt aber weder die Implementierung von Password Modify auf einem bestimmten Server noch gleiches Verhalten zwischen Servern.

Der RFC Editor führt zwei verifizierte Errata: Erratum 340 korrigiert im historischen Hintergrund „where“ zu „were“; Erratum 4899 ergänzt Kommas in der ASN.1-Feldfolge. Die formale Interpunktion wird präziser, die Grenze zwischen Identitätsform, Verzeichnis und Passwortspeicher bleibt unverändert.

RFC 3062 ermöglichte LDAP also, eine Passwortänderung anzufragen, ohne ein Verzeichnisattribut oder einen DN vorauszusetzen. Der Server musste die Anfrage weiterhin mit der tatsächlichen Instanz verbinden, die das Passwort kontrolliert. Die Protokollantwort beschreibt nur das Ergebnis, das an dieser Operationsgrenze zugesagt wird.

Quellen