Active Directory

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

--ThomasF 07:51, 29. Jun 2007 (CEST)

Active Directory
Basisdaten
Entwickler:	Microsoft
Aktuelle Version:
letzte Veröffentlichung:
Betriebssystem:	Windows
Kategorie:	Samba LDAP
Lizenz:
Deutschsprachig:
Webseite:

Autor: ThomasF

Es mag vielleicht merkwürdig erscheinen das ich hier in einem Linux Wiki die Active Directory von Microsoft so direkt thematisiere

Bei näherer Betrachtung macht es jedoch Sinn sich mit diesem Thema zu beschäftigen. In einem heterogenen Netzwerk ist es z.B. durchaus üblich Linux Clients an einen Microsoft Domain Controller anzubinden.

Anderseits beruht der ADS von Microsoft auf LDAP das einen offenen Standard darstellt.

Das Thema LDAP wiederum hat viele Schnittstellen zu anderen Themen und Anwendungen die LDAP als zentrale Datenbank nutzen können.

Ich möchte nun hier versuchen eine Sammlung von Problemen und deren Lösungen zu sammeln die die Active Directory als LDAP Datenbank direkt oder indirekt betreffen. Dazu gehört auch das Thema Kerberos das in Bezug auf echtes SSO (Single-Sign-On) gerade in letzter Zeit an verschiedenen Stellen aufgegriffen wird ( siehe z.B. ix Artikel 03/07 - 05/07)

Geplante Themen :

Installation eines Active Directory / Aufbau einer Testumgebung

Hier an dieser Stelle soll nun keine detaillierte Installationsanleitung entstehen. Wer sich mit der Installation und Konfiguration eines Windows Servers beschäftigt wird im Internet eine Reihe guter Anleitungen finden können. Vielmehr sollen hier die Rahmenbedingungen für eine Testumgebung definiert werden sodass im weiteren Verlauf darauf Bezug genommen werden kann.

Durch die weitreichende Integration der DNS Auflösung in der Active Directory ( AD ) legen wir nun als erstes die "Domain", den Servernamen und die IP Adressen unserer Umgebung fest :

Domain : meinefirma.de

Servername : PDC

IP Adressbereich : 192.168.1.0/24

Bei der Installation des Windows 2003 Server wird nun zunächst das Grundsystem installiert wobei jedoch noch keine "Aufgabe" des Server festgelegt werden muss. Es folgt die Installation der Support-Tools, am besten gleich auch die Services für Unix (SFU) und der Updates.

Der nächste Schritt ist nun die Installation und Konfiguration des DNS Servers. An dieser Stelle soll nochmals auf den Zusammenhang zwischen DNS und dem späteren Aufbau der Active Directory ( AD ) hingewiesen werden. Man sollte also keinesfalls leichtfertig oder vorschnell irgendwelche Entscheidungen in Bezug auf die Namensgebung treffen die sich später nicht mehr so einfach ändern lassen.

Wir halten uns also an die oben definierte Variante und nutzen "meinefirma.de" als Domain, in der AD wird daraus später dc=meinefirma,dc=de ( DC == Domain Component). Die DNS Zone heißt aber meinefirma.de. Für die AD aktiviert man am besten die dynamischen Updates des DNS-Servers. Aber auch hier gehen wir nicht näher auf die Installation des DNS Servers ein, derjenige der wirklich die konkrete Absicht hat eine AD zu implementieren wird sich mit diesem Thema zwangsläufig intensiver beschäftigen müssen.

Nun können wir unserem Server die "Rolle" eines "Domain Controllers" zuweisen, und bei dieser Aktion wird dann seit dem Windows 2000 Server auch die Active Directory konfiguriert.

Ist dieser Vorgang abgeschlossen haben wir nun die Grundlage für unsere Testumgebung geschaffen. Der Server alleine nutzt uns natürlich relativ wenig, wir benötigen also noch mindestens einen weiteren Rechner den wir als Client benutzen. Die Verwendung eines Windows-Clients sparen wir uns an dieser Stelle auch und konzentrieren uns auf die Linux-Clients und gehen davon aus das wir diesen in einer Grundinstallation vor uns stehen haben die schon in der Lage ist auf das Netzwerk zuzugreifen.

LDAP, der gemeinsame Nenner

So, der Windows Domain Controller mit der Active Directory ist Betriebsbereit. Nun sitzen wir an einem Linux Client und fragen uns was uns das nun nutzt.

Im Grunde ist die AD ja nichts anderes als ein LDAP Server und damit eine Datenbank die Informationen speichern kann. Welche Informationen das sind ist im Grunde gleichgültig. In diesem Fall werden dort Informationen gespeichert die der Domain Controller für seine Aufgabe benötigt. Also zum Beispiel die Benutzerdaten, die notwendig sind um es einem User zu ermöglichen, das er sich auf einem Rechner im Netzwerk anmelden kann und von dort aus auf andere Netzwerkresourcen zugreifen zu können (Daten, Drucker, ... usw).

Dabei stehen natürlich für einen Microsoft Domain Controller die Windows Clients im Vordergrund. Da ein LDAP Server, in diesem Falle die AD, wie oben schon erwähnt in der Lage ist beliebige Daten zu speichern und außerdem einen offenen, in der RFC 2251 definierten, Standard darstellt ist es auch problemlos möglich diese Daten einem Linux Client zur Verfügung zu stellen.

Dies gilt sowohl für die Benutzer-Authentifizierung als auch für Anwendungen wie zum Beispiel ein Adressbuch usw.

Um unter Linux nun auf diesen Server zugreifen zu können benötigen wir natürlich auch ein paar Tools, die je nach Distribution in Paketen wie ldap-client oder ldap-tools zu finden sind.

Eins dieser Tools das wir uns jetzt einmal anschauen ist ldapsearch.

Um mehr über ldapsearch heraus zu bekommen nutzt man die unter Linux üblichen Quellen ( man ldapsearch oder ldapsearch --help)

Möglichkeiten der Authentifizierung an der ADS

Passwortbasierte Methode

Die einfachste Möglichkeit unter Linux mit der AD Kontakt aufzunehmen ist bei der Verbindung mitzuteilen wer, welcher User, die Verbindung wünscht, natürlich im Zusammenhang mit dem entsprechenden Passwort.

ldapsearch -x -Hldap://pdc.meinefirma.de -b "dc=meinefirma,dc=de" -DAdministrator@meinefirma.de -W

Wenn alles richtig konfiguriert ist sollte man nach der Eingabe des Administrator-Passwortes nun die Ausgabe des gesammten LDAP Baums bekommen. Unabhängig von den LDAP spezifischen Hintergrund, was zum Beispiel Objektklassen und Attribute betrifft kann man schon am Aufruf des oben gezeigten Aufrufs mehrere Dinge erkennen.

-Hldap://pdc.meinefirma.de : Der Host auf dem der LDAP Server läuft

-b "dc=meinefirma,dc=de" : Die BaseDN des LDAP Baumes

-DAdministrator@meinefirma.de : Der User mit dem man sich Authentifizieren möchte ( Bind )

-W : Steht einfach nur dafür das man die Eingabeaufforderung für das Passwort bekommt.

-x : Steht für "Simple Bind"

Dabei sollte jedem der sich schon einmal mit LDAP oder speziell Openldap beschäftig hat zweierlei auffallen.

Erstens der Bind-User "Administrator@meinefirma.de" ... diese Syntax ist eine Eigenart der AD und könnte damit auch dazu verwendet werden einen weiteren Administrator in einem andernen Zweig zu identifizierten.

Zweitens "-x" ... prinzipiell nichts außergewöhnliches, denn auch unter Openldap benötigt man -x für Simple Bind Verbindungen. Anderseits bedeutet "Simple Bind" die Übertragung der Passwörter im Klartext, die man überall wo es möglich ist vermeiden sollte. Also mindestens mit einer TLS verschlüsselten Verbindung.

Nun beherrscht der Windowsserver jedoch einerseits keine TLS Verschlüsselung, anderseits ist es aber auch nicht zulässig z.B. über eine unverschlüsselte Verbindung Passwörter zu ändern, mehr noch Passwörter bzw. deren Hashes werden überhaupt nicht angezeigt. Man könnte also darüber diskutieren wozu es überhaupt Sinnvoll sein könnte diese Verbindungart zu wählen. Selbst wenn sich Linux-Clients hier Authentifizieren können ist es mit Sicherheit angebracht darüber nach zu denken diese Simple Binds zu verbieten. Und tatsächlich kann man über die Gruppen-Richtlinien auf dem Server eine verschlüsselte Verbindung erzwingen ( Network security: LDAP client signing requirements )

Tatsächlich kann man dort die Verwendung von SSL erzwingen ... Allerdings muss man für diesen Fall den Windows Server für die Verwendung von SSL konfigurieren. Siehe -> Secure LDAP Active Directory environment

Wenn dann die Zertifikate erstellt und eingebunden wurden klappt auch der verschlüsselte Zugriff :

ldapsearch -x -Hldaps://pdc.meinefirma.de -b "dc=meinefirma,dc=de" -DAdministrator@meinefirma.de -W

Im Prinzip also nur ldaps ( Port 636 ) anstatt ldap (Port 389)

Kerberos

Das Thema Kerberos ist etwas umfangreicher.

Auch hier benötigen wir unter Linux ein paar Hilfs-Tools ... die Pakete sind wieder je nach Distribution unterschiedlich benannt (z.B krb5-user oder krb5-client ....) Nach der Installation dieser Tools und deren abhängiger Bibliotheken stehen uns ein paar neue Befehle zur Verfügung ( kinit, klist, kdestroy, kpasswd ...)

... to be continued ...

Diverses

Probleme von Linux Clients bei der Anbindung an einem Microsoft Server

Eines der bekanntesten Probleme ist das Mounten der Homeverzeichnisse eines Linux Clients von einem Windows Servers oder auch eines Samba-Shares.

Zwar ist das Mounten an sich kein Problem mehr, da es mit pam_mount einen Mechanismus gibt der gleich bei der Authentifizierung das Verzeichnis einbindet, ohne darauf angewiesen zu sein das Passwort im Klartext aus einer Datei lesen zu müssen, dennoch unterstützt dieses Filesystem nicht alle Features die ein Linux Client benötigt.

Ein Beispiel hierfür stellen die Sockets dar. Im Homeverzeichnis eines Linux Users trifft man diese zwar selten an, aber zum Beispiel KDE und Gnome nutzen sie.

/home/user/.kde/socket-rechnername -> /tmp/ksocket-user

Dies ist auch der Fall wenn auf dem Windows-Server die Homes per NFS exportiert werden.

Ein Workaround für dieses Problem besteht darin KDE aufzufordern das .kde Verzeichnis nicht im Home des Users zu suchen sondern Beispielsweise direkt in /tmp Ein Script muss dann dafür sorgen dieses Verzeichnis mit dem im Home des Users syncron zu halten.

Siehe auch -> HowTo der Uni Rostock

Dieser Workaround ist jedoch nur Suboptimal. Bei einem Absturz von KDE wird Beispielsweise der Sync nicht durchgeführt und alle in dieser Sitzung durchgeführten Änderungen sind verloren, es sei denn der Sync wird dann per Hand nachgeholt.

Eine andere Lösung wäre in diesem Fall einen eigenen NFS Server unter Linux für die Linux Clients bereit zu stellen, und die reinen Daten der User an anderer Stelle einzubinden.

siehe auch

• Samba in Win2000 Domain
• Linux und active directory

Quellen und weiterführende Links

• Active Directory in der Wikipedia
• Microsofts Active Directory Seite
• Microsoft
• SRV records
• WINS (Windows Internet Naming Service)
• Distributed Management Task Force
• Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)
• HowTo der Uni Rostock

• Hier Links zu dem Thema eintragen

---

zurück zu Samba
zurück zu LDAP