Interop 2: Benutzerinfos für Linux per LDAP aus 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.

Nachdem ich im ersten Teil erklärt habe, welche Voraussetzungen erfüllt sein müssen, um LDAP-Abfragen ans AD zu senden, geht es in diesem zweiten Teil darum, das sinnvoll zu nutzen.

Linux speichert Infos über Benutzer in der Datei /etc/passwd, darunter der Loginname, eine Benutzer-ID, eine Gruppen-ID, das Home-Verzeichnis und noch so ein paar Dinge. Kommt einem bekannt vor? Richtig, das AD macht ja auch nichts anderes. Wie kann man jetzt die Daten, die im AD liegen, dafür verwenden? Geht das überhaupt? Die gute Nachricht heißt: Ja, das geht. Die schlechte Nachricht: Es ist ein bisschen Aufwand. Aber das soll uns nicht abhalten. Los geht’s:

Schon mal gefragt, wie ein Betriebssystem sich merkt, wem welche Datei gehört? Nun, es gibt jedem Benutzer eine eindeutige Nummer (ID), unter Windows heißt die SID, unter Linux UID. Gleiches gilt für Gruppen, da nennt man das unter Linux GID. Leider kann Windows nix mit einer UID anfangen, und Linux nix mit einer SID. Also was tun? Nun, es gibt Attribute im AD, die genau für einen solchen Zweck da vorgesehen wurden, nämlich uidnumber und gidnumber. Leider hat man das Frontend (oder auch GUI genannt) vergessen bzw. entweder nur mit den Services for Unix oder ab Windows Server 2008 (Rolle Identitätsmanagement) zur Verfügung. Man kann aber auch anderweitig die Attribute füllen, zum Beispiel mit adsiedit (siehe oben) oder per Script. Hier mal die Minimalversion eines VB-Scripts:

sServer=“LDAP://dc1.contoso.com/“
sUser=“cn=ralfw,ou=employees,dc=contoso,dc=com“
set oUser=getobject(sServer & sUser)
oUser.uidnumber = 10001
oUser.gidnumber = 10000
( … )
oUser.setinfo

Anstelle der … können noch weitere Attribute gefüllt werden, kommen wir später noch dazu. Das Ganze als moduser.vbs ablegen und

cscript.exe moduser.vbs

führt das dann aus. Damit haben wir auf Windows-Seite alle Voraussetzungen geschaffen, dass ein Linux-Client Benutzerinformationen direkt aus dem ADDS abrufen kann. Jetzt wechseln wir zur Linux-Seite.

Linux Clients speichern die Benutzerinformationen wie gesagt klassisch in einer Textdatei, die im Verzeichnis /etc liegt und passwd heißt. Dort findet die Zuordnung (Mapping) zwischen UID und Benutzername statt. Das ist aber nicht die einzige Möglichkeit, vielmehr kann man dem Client sagen, von wo überall und in welcher Reihenfolge er die Informationen suchen soll. Dazu gibt es den sogenannten Name Resolution Service und die Konfigurationsdatei /etc/nsswitch.conf. Einfach mal mit dem Editor ihrer Wahl öffnen (ich nehm immer den VI, ganz klassisch – der geht immer, wenn man weiß, wie…) und die Zeile suchen mit dem passwd vorne. Da steht dann so etwas wie:

passwd: files

und wir machen daraus sowas wie:

passwd: files ldap

Fertig. Die Reihenfolge ist übrigens Absicht, damit lokal eingetragene Benutzer stets Vorrang haben!

Jetzt weiß unser Linux, dass es außer in der normalen /etc/passwd auch noch per LDAP nach Benutzerinfos suchen soll – aber auf welchem LDAP-Server denn? Genau das müssen wir noch konfigurieren. Hier (und leider nicht nur hier) unterscheiden sich diverse Linux-Varianten. Bei manchen heißt die richtige Datei /etc/libnss_ldap.conf, bei anderen einfach nur /etc/ldap.conf, bei neueren Debians /etc/libnss-ldap.conf (genau, nicht mehr mit dem Unterstrich, sondern mit einem Minus). Diese Datei wird von dem Name Service Switch verwendet, der lediglich Benutzerinfos holt. Will man auch Benutzerlogins via LDAP authentifizieren, dann benötigt man sogenannte PAM-Module (siehe späteres Kapitel). Diese nutzen manchmal die gleiche Konfigurationsdatei, manchmal eine eigene, manchmal auch einen symbolic link auf die libnss-ldap.conf. Ein neueres Debian verwendet zum Beispiel /etc/pam_ldap.conf (ja, wieder mal mit Unterstrich). Hat man zwei Dateien (manchmal wird da auch mit Links gearbeitet!), dann kann man theoretisch die Namensauflösung und eine Authentifizierung verschieden konfigurieren. Wozu das gut sein soll? Naja, bei einer reinen Namensauflösung geht an sich nichts Geheimnisvolles übers Netz, daher würde eine normale LDAP-Verbindung reichen. Bei Authentifizierungen sollte es aber schon eine LDAPS sein, das ist allerdings etwas langsamer durch die Verschlüsselung. Vorteil erkannt? Prima. Weiter mit der Konfiguration für die /etc/libnss-ldap.conf. Hier eine (Fast-)Minimalversion:

host 10.0.0.1
base OU=employees,DC=contoso,DC=com
scope sub
#RFC 2307 (AD) mappings
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member

Die Zeilen nach dem RFC 2307 sind normalerweise alle schon vorhanden und müssen nur auskommentiert werden. Hier findet ein Mapping statt zwischen den Attributsnamen der klassischen LDAP-Welt (links) und den Attributsnamen, wie sie in Windows verwendet werden (rechts). Prinzipiell kann man alles auf alles mappen, solange der Typ stimmt. Hier wird zum Beispiel definiert, dass das LDAP-Attribut „uid“ im ADDS als „sAMAccountName“ bekannt ist. Zwar gibt es in ADDS auch ein Attribut „uid“, aber das ist vom Typ Unicode-Zeichenfolge und außerdem mehrwertig und nicht gesetzt.

uidnumber und gidnumber müssen nicht gemappt werden, die heißen in beiden Welten gleich. Verwendet man eine ältere Version des AD, sagen wir mal 2003 und früher, dann gibt es die Attribute beispielsweise nicht. Dann kann man entweder ein neues Schema einspielen (R2 oder 2008), oder die Services für Unix installieren, für letzteres bringt Linux auch einen geeigneten Satz von Mappings mit, denn die Attribute heißen da irgendwas mit dem Präfix msSFU30…

homeDirectory muss gemappt werden auf unixHomeDirectory, denn homeDirectory gibt es zwar auch in ADDS, wird aber von Windows selbst verwendet für das (Windows)-Homeverzeichnis.

Wenn man die Datei abgespeichert hat, dann sollte die folgende Zeile funktionieren, auch ohne dass der Benutzer in der lokalen /etc/passwd eingetragen ist – nur im ADDS muss er in der richtigen OU stehen:

getent passwd harryp

Zurück kommt dann sowas ähnliches wie:

harryp:*:10001:10000:harryp::

wobei die erste Zahl die UID ist und die zweite die GID. Wie, klappt nicht? Dann mal folgende Checkliste durchgehen:

  • sicherstellen, dass der Benutzer auch wirklich existiert
  • in der richtigen OU?
  • hat die Vererbung der ACLs von der OU nach unten geklappt?
  • hat der Benutzer eine gültige UIDNUMBER?
  • hat der Benutzer eine gültige GIDNUMBER? (uidnumber und gidnumber müssen beide angegeben sein!)
  • werden die Attribute mittels ldp.exe vom DC aus angezeigt? Wenn ja, Firewall prüfen!
  • Ist die Angabe vom Host in der ldap.conf korrekt (mal anpingen!)
  • ist der NSCD im Einsatz? Name Service Caching Daemon tut genau das, was er sagt, er speichert Benutzerinfos zwischen. Ändert sich eine Benutzerinfo, dann bekommt man eventuell immer noch die alte Info angezeigt, weil der NSCD sich einschaltet. Am besten mal Daemon beenden und vorläufig aus den Startscripten rausnehmen.

Wenn es jetzt immer noch nicht klappt, dann am besten einen MVP ihres Vertrauens buchen (oder mir eine Mail schicken).

Wer es übrigens genau wissen will: der LDAP-Client (zumindest meiner hier) sendet eine LDAP-Anfrage nach

(&(objectClass=user)(sAMAccountName=harryp))

und den Attributen:

  • sAMAccountName (eigentlich nach den Attribut uid, aber das ist ja gemappt)
  • userPassword
  • uidnumber
  • gidnumber
  • cn
  • unixHomeDirectory (auch hier eigentlich homeDirectory, aber gemappt)
  • loginShell
  • gecos
  • description
  • objectclass

wobei wie gesagt uidnumber UND gidnumber gesetzt sein müssen. Zu den Gruppen-IDs hab ich auch mal einen anderen Artikel verfasst.

Noch ein Wort zu der Konfig-Datei. Möchte man keinen anonymen Zugriff auf das AD zulassen, dann muss man in der Konfigurationsdatei einen Benutzer angeben, ähnlich wie bei den Kommandozeilen-Versuchen des letzten Kapitels. In älteren Versionen musste das Passwort für diesen Benutzer dann auch in der Konfig-Datei drinstehen (im Klartext!), und die Datei musste auch von allen lesbar sein. Neuere Versionen lagern das Passwort aus in eine ldap.secret (oder ähnlich, je nach Version), und diese Datei ist dann nur für root lesbar. Ist glaub ich vertretbar. Dennoch sollte dieser LDAP-Benutzer nach wie vor nur über minimale Rechte verfügen, zum Beispiel Domänen-Gast.

So. Wir haben jetzt quasi die passwd-Datei auf den LDAP-Server, sprich DC, ausgeweitet. Jetzt können wir beispielsweise schon Filesysteme per NFS mounten und die dortigen Benutzer- und Gruppen-IDs in Namen auflösen, für die die Info aus dem AD stammt. Im nächsten Schritt möchte ich eine Authentifizierung per LDAP versuchen, siehe Interop 3.

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.

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