Anonymer AD-Zugriff?

Dieser Artikel erschien zuerst auf Ralfs Blog.

Eine LDAP-Authentifizierung oder eine Namensauflösung über LDAP funktioniert in zwei Schritten:

Es erfolgt eine subtree-Suche unterhalb der Searchbase nach (uid=loginname). Als Ergebnis wird der komplette DN des gefundenen (und hoffentlich eindeutigen) Objektes zurückgeliefert.
Anschließend erfolgt eine Abfrage der benötigten Attribute dieses Objektes bzw. bei LDAP-Login der Versuch eines Bind als das Objekt mit dem eingegebenen Passwort.

Das Problem insbesondere bei Schritt 1 ist die Grundeinstellung von AD, die eine anonyme LDAP-Abfrage nicht erlaubt. Für Leserechte benötigt man mindestens die Mitgliedschaft in “Authentifizierte Benutzer”. Nun gibt es zwei Möglichkeiten, das zu ermöglichen:

den Zugriff für Anonymous freigeben oder
einen Benutzer anlegen, der vom LDAP-Client anstelle von anonymen Anfragen verwendet wird. Am besten packt man den nur in die Gruppe der Domänengäste, dann kann er sich schon mal nicht an einer Workstation anmelden.

Was sind nun die Vor- und Nachteile der beiden Varianten?

Nachteil der Anonymous-Lösung ist sicherlich, dass jeder und wirklich jeder das AD abfragen kann. Wenn der Eingangsrouter oder die Firmenfirewall den LDAP/LDAPS-Port nicht sperrt, dann sogar weltweit. Bei 2) benötigt man immerhin noch einen Benutzer und ein Passwort, aber das muss in vielen Applikationen im Klartext stehen und ist meistens für einen viel zu großen Benutzerkreis lesbar. Mindestens muss man es jedem Benutzer, der einen Client selbst administriert und LDAP verwendet, mitteilen. Und schon bald ist der Unterschied zu “Jeder” deutlich geschrumpft. Nimmt man mal an, dass alle Benutzer einer Organisation auch ein Konto im AD haben, und nimmt man weiterhin an, von außen ist kein LDAP-Zugang möglich (nebenbei noch vorausgesetzt, dass es keine öffentlich zugänglichen Netzwerkdosen gibt), dann ist es schlichtweg egal, ob die Suche anonym erfolgt: Jeder Benutzer kann mit seinem Account mindestens das gleiche, wenn nicht sogar mehr. Es werden also keine weiteren Daten zugänglich gemacht, jeder Benutzer kann das sowieso schon.

Entscheidend ist für mich aber der folgende Umstand: Im AD besitzt jedes Objekt eine Access Control List, kurz ACL. Hier muss man auf die Objekte, die abfragbar sein sollen, dem Benutzer Anonymous entsprechende Leserechte gewähren. Dies kann sogar auf Attribut-Ebene erfolgen, also zum Beispiel Leserechte auf die Heimatadresse, aber nicht auf die Heimat-Telefonnummer (was für einen Sinn auch immer das haben sollte 🙂 . Durch Vererbung bzw. Stoppen der Vererbung ist ein genaues Dosieren der Rechte möglich. Im Gegensatz hierzu ist bei Lösung 2) das notwendige Recht schon an jedem Objekt vorhanden, nämlich Leserechte für “Authentifizierte Benutzer”. Um die Sichtbarkeit einzuschränken, muss also der umgekehrte Weg gegangen werden, nämlich Rechte verweigern. So soll vielleicht der CN-Users-Container nicht abfragbar sein oder auch der CN=Computers. Bei einem Verweigern greift man aber in die Standard-Rechtevergabe des ADDS massiv ein, denn “Verweigern” schlägt stets “Erlauben” (kurz gesagt). Es ist daher nicht auszuschließen, dass man hinterher ein nicht mehr funktionierendes ADDS hat – und wer will das schon, mal die Consultants ausgenommen?

Was ändert sich durch Anonymous?

Nochmal zum Mitschreiben: Standardmäßig hat Anonymous keine Rechte! Wenn man jetzt auf die OU=employees,DC=contoso,DC=com dem Anonymous Leserechte gibt und das nach unten vererbt, dann lassen sich mit jedem LDAP-Client Suchanfragen für diese Searchbase und Subtree-Scope durchgeführt werden, aber zum Beispiel nicht für CN=Users,DC=contoso,DC=com. Verwendet man einen LDAP-User, dann muss man zwar keine ACL für die OU=employees setzen, dafür ist aber der Zugriff auf CN=Users auch möglich und müsste (besser: sollte) eingeschränkt werden.

Ich bin immer abgeneigt, Verweigern-Rechte zu setzen, wenn es nicht unbedingt sein muss. Daher nehme ich immer die Anonymous-Lösung. Und wenn Euch mal ein Benutzer namens “padl” begegnet, dann ist das mit großer Wahrscheinlichkeit ein solcher “Search”-User, dann padl wird gerne als Benutzernamen für ein solches Account verwendet, weil es zum einen LDAP von hinten gelesen ist, und zum anderen Teil des Firmennamens von PADL Software Pty Ltd.