Interop 1: LDAP-Anfragen von Linux an AD

In dieser Serie von Blogeinträgen möchte ich Schritt für Schritt erklären, wie man die Vorteile des AD auch für Linux nutzen kann. Ich hab mir gedacht, ist ein bisschen viel für einen Artikel, daher werde ich das jetzt abschnittweise vorstellen.

In diesem ersten Teil geht es um LDAP-Abfragen an das AD, wie es der Titel eigentlich auch schon sagt. Und genau das werden wir jetzt zusammen machen.


Was braucht es dazu? Naja, zum einen ein Linux, und natürlich ein Active Directory auf der anderen Seite. Über die Linux-Seite will ich gar nicht viel verlieren, da gibt es unzählige Distributionen, alle etwas unterschiedlich. Das werde ich möglichst so beschreiben, dass es jeder selbst auf die Feinheiten seiner Distribution anpassen kann. Ausprobiert habe ich das mal auf Rotem Hutlinux (so übersetzt zumindest dieser unsägliche automatische Knowledgebase-Translator RedHat) und bevorzugt unter Debian/Ubuntu.

Auf der Windows-Seite muss (und kann) ich schon etwas detaillierter schreiben. Ich setze mal ein funktionierendes AD voraus (DNS in Ordnung, Replikation läuft, keine Fehlermeldungen – und ich meine wirklich keine Fehlermeldungen!). Falls das schon nicht erfüllt ist, wenden Sie sich an den MVP ihres Vertrauens.

Unsere Demo-Domäne heißt contoso.com, der DC heißt dc1.contoso.com (10.0.0.1), da läuft ein DNS-Server und ein WINS drauf, und es ist ein Windows Server 2003R2 oder höher. Am besten ist natürlich Windows Server 2012R2 oder was grade aktuell ist. Mindestens aber 2003R2, ab da ist das Schema nämlich RfC 2307 kompatibel, das macht das Leben leichter. Man kann aber auch 2003 oder früher nehmen, dann aber bitte die (kostenlosen) Services for Unix einmal installieren (genauer den NIS-Server), dann passt das Schema. Mehr dazu später, wenn es um die Linux-Konfiguration geht. Den NIS-Server übrigens am besten gleich wieder deinstallieren, und wer nicht weiß, warum, der darf gerne mal nach den Stichworten Security und NIS googeln oder bingen (gibt’s das Verb auch schon?).

Wir legen unsere Benutzer in einer OU namens OU=employees an, und nennen unseren Linux-Client client1 mit der IP 10.0.0.2. Fragen? Keine? Prima, dann weiter!

Auf dem client1 kann man mal versuchen, folgende Zeile einzugeben (in einer Zeile natürlich):

ldapsearch -x -h 10.0.0.1 -s sub -b ou=employees,dc=contoso,dc=com

Damit wird der DC1 (der hat die IP 10.0.0.1 – wir erinnern uns?) per LDAP angesprochen und mittels einfacher Authentifizierung (-x) veranlasst, unterhalb (-s sub) der OU employees (-b) alle Ergebnisse auszugeben.

Nun gibt es zwei Möglichkeiten:

1) ldapsearch kann nicht gefunden werden

Jetzt kommt die Stunde der Linux-Spezialisten: das Programm ist in irgendeinem Package enthalten, vielleicht was mit ldap-client oder so. Installieren und nochmal versuchen. Die absoluten Profis holen sich natürlich den Source und compilieren das selbst. Jeder wie er es verdient 🙂

2) irgendwas mit Zugriff verweigert

Das ist etwas komplizierter, ist aber normal, dass das passiert. Zumindest ist das Package schon installiert, ist ja auch schon mal was. Aber warum Zugriff verweigert?

Die Lösung ist eigentlich ganz einfach: Der Lese-Zugriff auf das AD ist standardmäßig nur für „Authentifizierte Benutzer“ freigegeben, wir kommen aber als anonymer Benutzer an. Kein Wunder also. Wenn wir uns authentifizieren würden, dann würde es vielleicht klappen. Einen Versuch isses sicher wert. Also los: Wir suchen uns einen Benutzer (nennen wir ihn mal harryp) in der Employees-OU. Dann sieht die Suche etwa so aus:

ldapsearch -x -h 10.0.0.1 -s sub -b ou=employee,dc=contoso,dc=com -D cn=harryp,ou=employee,dc=contoso,dc=com -W

Hier ist jetzt ein sogenannter Bind-DN dazu gekommen (-D), das ist der distinguished Name des Benutzers, als der die Anfrage durchgeführt werden soll. das -W sorgt für eine Passwort-Abfrage. Jetzt müsste es eigentlich gehen. Bitte beachten, dass in diesem Beispiel das Passwort im Klartext über das Netzwerk geht!

Nun treffen da aber zwei Philosophien aufeinander: Zum einen kann man bei jeder Abfrage einen Benutzer (mit Passwort) angeben, zum anderen könnte man ja auch den anonymen Lese-Zugriff auf das AD freigeben. Beides hat Vor- und Nachteile, die ich in einem eigenen Beitrag mal kurz beschrieben habe. Ich bevorzuge die anonyme Methode (ja ehrlich!) und will sie daher hier auch beschreiben.

Einer OU oder überhaupt einem Objekt im AD kann man genau wie Dateien oder Verzeichnissen eine ACL (Access Control List) ankleben, die regelt, wer hier was darf. Also muss man lediglich in „Active Directory Benutzer und Computer“ bei der OU employees rechtsklicken und „Sicherheit“ auswählen (falls das nicht angezeigt wird, dann mal unter „Ansicht“ die „Erweiterten Features“ einschalten, dann geht’s). Dann noch „Hinzufügen“ und „Anonymous“ hinzufügen! Geht nicht? Stimmt.

Standardmäßig verhindert das AD, dass dem Benutzer „Anonymous“ irgendwelche Rechte vergeben werden können, eine (sinnvolle) Sicherheitseinstellung, die uns aber auch nur kurz aufhält: Wir starten adsiedit.msc (früher bei den Support Tools dabei) und wählen die „Configuration“-Partition. Klingt kompliziert? Nein, ist es nicht. Probieren Sie es ruhig mal aus, vielleicht erst mal in einer Testumgebung :-). Ein prima Tool, dieses adsiedit, das sollte man sich in „Friedenszeiten“ mal angesehen haben, bevor man es wirklich braucht…

Aber zurück zu unserer Aufgabe. Also in die Configuration-Partition und dann nach Services, Windows NT, Directory Service. Dort rechtsklicken und Eigenschaften, da gibt es ein Attribut namens dsHeuristics, und da kommt eine 0000002 rein (also 6 Nuller und eine 2), aber nur, wenn da noch nichts drin steht (das ist der Standard, sonst bitte nachlesen!).

Das war es auch schon. Das macht man nur ein einziges Mal, da das (Configuration-Partition! Wir erinnern uns an den MOC-Kurs?) für den ganzen Forest gilt. Damit hat man jetzt noch nicht den anonymen Zugang freigegeben, keine Angst, sondern man hat nur die zusätzliche Sicherheitssperre ausgeschaltet, d. h. man kann jetzt „Anonymous“ Rechte zuweisen (tut man’s nicht, hat er nach wie vor keine). Also wieder zu unserer OU und dem „Anonymous“ Leserechte geben. Vererbung ist eine prima Sache (aber Vorsicht!), machen wir hier auch, bitte kontrollieren (je nach Mitgliedschaft des Benutzers werden die Rechte zyklisch wieder auf Standard gesetzt)! Hier sieht man übrigens auch den Vorteil der Anonymous-Lösung: man kann den Lesezugriff für „Anonymous“ gezielt für einzelne Verzeichnisse freigeben, statt den Lesezugriff für „Authentifizierte Benutzer“ überall wegnehmen zu müssen…

So, das war es auch schon. Nochmal die Zeile mit dem ldapsearch von oben (ohne den -D und -W), und es sollte ein Ergebnis kommen (natürlich nur, wenn man auch Benutzer in dieser OU angelegt hat :-). Man kann das übrigens auch ohne Linux testen, die Support Tools bringen so eine Art LDAP-Browser mit (ldp.exe). Dort reicht es jetzt dann aus, auf Connect zu gehen, ein nachfolgendes Bind ist jetzt (im Gegensatz zu sonst) nicht mehr nötig. View, Tree und ou=employees,dc=contoso,dc=com, und schon geht’s auch hier ab.

Das war es auch schon für den ersten Teil dieser Serie. Im zweiten Teil möchte ich zeigen, was man jetzt mit so einer funktionierenden LDAP-Abfragemöglichkeit machen kann.

Advertisements

Über Ralf Wigand

...arbeitet für Microsoft und war von 2008-2015 MVP für Directory Services.
Dieser Beitrag wurde unter Active Directory, LDAP, Linux veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Eine Antwort zu Interop 1: LDAP-Anfragen von Linux an AD

  1. Pingback: AD-Interoperabilität mit Linux | faq-o-matic.net

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s