Zusammenfassung

  • RFC 2307 beschrieb LDAP-Einträge für Unix-Konten, Gruppen und Netzwerkdaten. Die Klasse posixAccount enthielt uidNumber, die numerische Kennung, nach der Systemfunktionen ein Konto finden konnten.
  • Der Sicherheitsteil benannte die Folge eines falsch gesetzten Schreibrechts: Wer uidNumber ändern durfte, konnte das eigene Konto dem Superuser gleichstellen. Entscheidend war die Kontrolle über die Änderung, nicht allein die Form des Schemas.

Die Suche nach einem Konto beginnt mit einer Zahl

Ein Unix-Prozess bittet das Verzeichnis nicht um eine Biografie. Er übergibt eine Zahl an die C-Bibliothek und erhält die zugehörigen Kontodaten. RFC 2307 führt getpwuid() als Beispiel an: Die Funktion ordnet einer Benutzer-ID einen Login-Namen zu. In dem vorgeschlagenen LDAP-Modell sucht das System nach einem posixAccount, dessen uidNumber mit der übergebenen Zahl übereinstimmt.

Auf dem Bildschirm sieht das nach einem Feld aus. Für die Software ist es eine Identität.

Unix-Netze teilten Konten und Hostinformationen bereits vor LDAP über den Network Information Service (NIS). Suns Solaris-Administrationshandbuch beschreibt NIS-Maps als Tabellen aus Schlüssel und Wert. Ein Master-Server hält die Maps einer Domäne; Slave-Server bewahren Kopien auf; Clients können beide abfragen. passwd.byname sucht nach dem Login-Namen, passwd.byuid nach der Benutzer-ID. Administratoren erzeugen die Maps auf dem Master aus lokalen Dateien und verteilen sie anschließend an die Slaves.

Damit wird eine lokale Datei zur Antwort im Netz. Ein Administrator ändert die Quelldatei, erstellt die Map neu, und die Clients der Domäne erhalten einen anderen Kontodatensatz. Die Suchfunktion prüft die Zahl nicht in einer Abstimmung mit den Clients. Sie verwendet den Wert, den der Namensdienst zurückgibt.

Das SunOS-Handbuch von 1999 bewahrt noch eine Namensgeschichte: NIS hieß früher Sun Yellow Pages. Nach einer Änderung wegen eines britischen Markenrechts blieb die Funktion erhalten. Der Name wechselte; die Konten-Map blieb ein Betriebsmittel.

LDAP verschob die Ablage. Wer schreiben durfte, blieb eine Verwaltungsfrage

RFC 2251 definierte LDAPv3 im Dezember 1997 als ressourcenschonenderen Zugang zu X.500-Verzeichnissen als das vollständige DAP. Rund drei Monate später erschien RFC 2307, An Approach for Using LDAP as a Network Information Service. Der Vorschlag beschrieb LDAP-Klassen und -Attribute für Unix- und TCP/IP-Daten.

Es ging um mehr als Hostnamen. Konten und Gruppen, Dienstnamen und Protokollnummern, RPC-Kennungen, Bootparameter, Netzwerkadressen und NIS-Netzgruppen gehörten zum Modell. posixAccount konnte Login-Name, Anzeigename, uidNumber, gidNumber, Home-Verzeichnis und Login-Shell speichern. RFC 2307 zeigte zudem, wie sich eine Zeile im Stil von /etc/passwd in Verzeichnisattribute überführen ließ.

Die Verbindung hatte einen praktischen Grund. Unix-Anwendungen fragten Kontodaten ohnehin über die C-Bibliothek ab. Sie konnten die Quelle von einer lokalen Datei auf ein Netzwerkverzeichnis umstellen, ohne das Muster jeder einzelnen Abfrage neu zu erfinden. Der Implementierungsabschnitt des RFC nennt einen NIS-Server, der LDAP statt lokaler Dateien verwendete, eine Referenzimplementierung für die C-Bibliothek und Skripte zum Laden von /etc/passwd oder /etc/hosts in LDAP.

RFC 2307 erschien als Experimental und ordnete nicht jedem Unix-Standort eine Migration an. Das Dokument berichtet von einigen erfolgreichen Implementierungen, zählt aber weder Installationen noch Marktanteile.

Die Zahl wurde zur Berechtigungsgrenze

Der Sicherheitsabschnitt des RFC behandelt Verzeichniseinträge als Eingabe für das Betriebssystem. Einträge, die Systemobjekte abbilden, sollten nur von Administratoren geändert werden. Der Grund ist konkret: Könnte ein Benutzer uidNumber ändern, könnte er die Sicherheit unterlaufen und sein Konto dem des Superusers gleichstellen.

RFC 2307 beschreibt damit ein bedingtes Risiko und den Kontrollpunkt. Unix-Software verknüpft die Zahl mit einem Konto; ein Verzeichnis kann diese Zuordnung an viele Clients ausliefern; wer Schreibzugriff hat, kann die Identität ändern, die diese Clients sehen. Das Schema legt das Format fest. Die Zugriffsregel legt fest, wer die Bedeutung des Werts verändern darf.

Derselbe Abschnitt markiert eine zweite Kollision zwischen Suche und Geheimhaltung. Können nicht privilegierte Nutzer verschlüsselte Passwort-Hashes lesen, die mit verbreiteten Verfahren wie crypt() erzeugt wurden, sind Wörterbuch- und Brute-Force-Angriffe möglich. Der RFC verband diese Form mit Kompatibilität zu bestehenden Unix-Systemen und empfahl für Umgebungen mit höheren Sicherheitsanforderungen einen starken Authentifizierungsdienst. Ein gemeinsames Verzeichnis erleichtert Abfragen; es kann zugleich mehr Clients an sensible Kontodaten heranlassen.

Belegt sind der Vorschlag und die Warnung im Dokument. Wie weit LDAP-gestützte Unix-Konten verbreitet waren, zeigen diese Quellen nicht; dafür wäre eine unabhängige Installationsstatistik nötig.

Die entscheidende Änderung bestand nicht darin, einem Datenspeicher ein Schema hinzuzufügen. Das Betriebssystem ließ eine Antwort auf eine lokale Frage aus dem Netz kommen. uidNumber war eine Spalte; erst die Software, die sie las, gab ihr Wirkung. Mit dem Wechsel von /etc/passwd zu NIS oder LDAP verschoben sich auch die Kontrollpunkte: Welche Quelle gilt als maßgeblich? Welche Kopie enthält die aktuelle Map? Und wer darf eine Benutzerkennung ändern?

Quellen