Linupedia.org - Benutzerbeiträge [de]

Active Directory

2007-07-05T12:50:12Z

ThomasF: /* Kerberos */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 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 ...

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T12:25:29Z

ThomasF: /* Probleme von Linux Clients bei der Anbindung an einem Microsoft Server */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 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.

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T12:24:58Z

ThomasF: /* Kerberos */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 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.

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T12:07:14Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 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===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T11:40:18Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 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===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T11:40:01Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 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===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T11:39:05Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 Secure LDAP Active Directory environment]

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

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

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

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T11:22:26Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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 -> [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 Secure LDAP Active Directory environment]

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T11:21:57Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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 [http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 Secure LDAP Active Directory environment]

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T11:21:34Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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

[http://www.tools4ever.com/documentation/user-management-resource-administrator/ldap_ad_secure.htm?content=7030 Secure LDAP Active Directory environment]

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T10:10:52Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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.

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T10:04:42Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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.

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T09:05:40Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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"

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T09:05:14Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

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"

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T07:46:00Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

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

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T07:24:49Z

ThomasF: /* Passwortbasierte Methode */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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.

.... to be continued ...

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T07:19:31Z

ThomasF: /* LDAP, der gemeinsame Nenner */

{{UnderConstruction}}--[[Benutzer:ThomasF|ThomasF]] 07:51, 29. Jun 2007 (CEST)

{{Infobox Software
|Name= Active Directory
|Screenshot=
|Beschreibung=
|Hersteller= Microsoft
|AktuelleVersion=
|AktuelleVersionFreigabeDatum=
|Betriebssystem= Windows
|Kategorie= [[Samba]] [[LDAP]]
|Lizenz=
|Deutsch=
|Website=
}}
Autor: [[Benutzer:ThomasF|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===

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[Samba in Win2000 Domain]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-07-05T07:10:15Z

ThomasF: /* LDAP, der gemeinsame Nenner */

Active Directory

2007-07-05T06:50:16Z

ThomasF:

Active Directory

2007-07-05T06:49:19Z

ThomasF: /* Installation eines Active Directory / Aufbau einer Testumgebung */

Active Directory

2007-07-05T06:48:53Z

ThomasF: /* Installation eines Active Directory / Aufbau einer Testumgebung */

Active Directory

2007-07-05T06:39:38Z

ThomasF: /* Installation eines Active Directory / Aufbau einer Testumgebung */

Active Directory

2007-07-05T06:20:48Z

ThomasF: /* Installation eines Active Directory / Aufbau einer Testumgebung */

Active Directory

2007-07-05T06:13:32Z

ThomasF: /* Installation eines Active Directory / Aufbau einer Testumgebung */

Active Directory

2007-07-05T06:04:05Z

ThomasF: /* Installation eines Active Directory / Aufbau einer Testumgebung */

Active Directory

2007-07-05T05:48:53Z

ThomasF: /* Installation eines Active Directory / Aufbau Testumgebung */

Active Directory

2007-07-05T05:32:32Z

ThomasF: /* Vergleich mit Openldap und Einsatzort der ADS */

Active Directory

2007-06-29T05:57:30Z

ThomasF:

Active Directory

2007-06-27T10:30:29Z

ThomasF: /* Probleme von Linux Clients bei der Anbindung an einem Microsoft Server */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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.

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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:29:42Z

ThomasF: /* Probleme von Linux Clients bei der Anbindung an einem Microsoft Server */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml 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.

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:09:33Z

ThomasF: /* Probleme von Linux Clients bei der Anbindung an einem Microsoft Server */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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

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 -> [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:09:11Z

ThomasF: /* Probleme von Linux Clients bei der Anbindung an einem Microsoft Server */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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

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 [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:08:48Z

ThomasF: /* Probleme von Linux Clients bei der Anbindung an einem Microsoft Server */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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

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 * [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:07:43Z

ThomasF: /* Quellen und weiterführende Links */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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

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.

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:07:14Z

ThomasF: /* Quellen und weiterführende Links */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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

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.

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock [1] ]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:06:00Z

ThomasF: /* Quellen und weiterführende Links */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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

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.

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* [http://www.uni-rostock.de/Rechenzentrum/sware/WindowsNT/SUSE102ADAM.shtml HowTo der Uni Rostock]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T10:01:14Z

ThomasF: /* Probleme von Linux Clients bei der Anbindung an einem Microsoft Server */

Autor: [[Benutzer:ThomasF|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 :

==Vergleich mit Openldap und Einsatzort der ADS==

==Möglichkeiten der Authentifizierung an der ADS==

===Passwortbasierte Methode===

===Kerberos===

==Samba und die ADS==

==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

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.

... to be continued

==siehe auch==
* [[SUSE in Win2000 Domain und Acitve Directory]]
* [[Linux und active directory]]

==Quellen und weiterführende Links==
* [[w:Active Directory|Active Directory in der Wikipedia]]
* [http://technet2.microsoft.com/windowsserver/en/technologies/featured/ad/default.mspx Microsofts Active Directory Seite]
* [http://www.microsoft.com Microsoft]
* [http://www.opentechsupport.net/forums/archive/topic/16708-1.html SRV records]
* [http://www.windowsitlibrary.com/Content/155/09/1.html WINS (Windows Internet Naming Service)]
* [http://www.dmtf.org Distributed Management Task Force]
* [http://www.samba-ldap.de Deutsches Debian-Samba-LDAP HowTo (samba-ldap.de)]

* Hier Links zu dem Thema eintragen
----
[[Samba|zurück zu Samba]] 
[[LDAP|zurück zu LDAP]]

[[Category:Samba]] [[Category:LDAP]][[Category:Windows]]

Active Directory

2007-06-27T09:40:22Z

ThomasF: /* Diverses */

Active Directory

2007-06-27T09:39:09Z

ThomasF:

OpenLDAP

2006-09-21T08:37:57Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> [http://www.linux-club.de/faq/Grafische_LDAP_Tools Grafische_LDAP_Tools]

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

'''Code:'''

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

'''Code:'''

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-21T08:37:01Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> [http://www.linux-club.de/faq/Grafische_LDAP_Tools] Grafische_LDAP_Tools.

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

'''Code:'''

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

'''Code:'''

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-21T08:36:39Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> [http://www.linux-club.de/faq/Grafische_LDAP_Tools]Grafische_LDAP_Tools.

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

'''Code:'''

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

'''Code:'''

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-21T08:36:12Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> [[http://www.linux-club.de/faq/Grafische_LDAP_Tools]]Grafische_LDAP_Tools.

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

'''Code:'''

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

'''Code:'''

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-21T08:35:30Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> [[ http://www.linux-club.de/faq/Grafische_LDAP_Tools#GQ]]Grafische_LDAP_Tools.

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

'''Code:'''

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

'''Code:'''

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-21T08:34:44Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> [[ Grafische_LDAP_Tools http://www.linux-club.de/faq/Grafische_LDAP_Tools#GQ]].

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

'''Code:'''

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

'''Code:'''

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-21T08:33:43Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> [[http://www.linux-club.de/faq/Grafische_LDAP_Tools#GQ]].

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

'''Code:'''

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

'''Code:'''

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-21T08:31:19Z

ThomasF: /* Linux Authentifikation */

{{UnderConstruction}}

Also hier versuche ich jetzt mal eine Anleitung nach dem Motto " Quick and Dirty " zu erstellen.

Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.

Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt,
da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.

=== Theorie ===

LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.

Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.

Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.

Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.

Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar.
Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....

Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet.
Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.

Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.

Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.

Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.

Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.

Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst.
Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.

Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.

'''Hinweis :'''

Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich.

'''Beispiele für Containerobjekte :'''
c : Country
o : Organization
ou : Organizational Unit

Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.

In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen.
Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.

Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.

Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.

Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.

Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann

'''Beispiele für Blattobjekte :'''

cn : Common Name
uid: UserID
...

'''Beispiele für Attribute:'''

userPassword
homeDirectory
loginShell
telephoneNumber
...

Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können.
Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.

Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.

Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.

== Planung ==

Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut,
also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.

Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.

Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.

'''Hinweis :'''
Anstatt o=meineFirma ,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen
und dann bei dieser auch bleiben !!!
Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt.
Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist !!!

Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht.
In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)

Besser passt in diesem Fall der Vergleich mit einer Internet-Domain.
Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.

Gut, also das Root-Objekt hat also in unserem Beispiel die Form :

dn: o=meineFirma, c=de

Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de

dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt.
Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.

Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht,
ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten.
Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.

Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen.
Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen.
Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.

Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".

Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?

Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand.
Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn,
sodass wir hier diesen Fall nicht berücksichtigen.

Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.

Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :

ou = Users
ou = Groups
ou = Workstations

== Aufsetzen eines Openldap-Servers ==

Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen)
kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.

Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.

Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.

Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.

Zum bearbeiten der Konfigurationsdateien selber kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.

Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.

'''Wichtig:'''

Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...)

Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!!
Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.

Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.

Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.

'''Wichtig :'''
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein.

Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :

core.schema
cosine.schema
nis.schema
inetorgperson.schema
samba.schema (oder samba3.schema)
misc.schema

Ein Beispiel für die slapd.conf wäre nun:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

'''Hinweis :'''
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann.

Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.

Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix"
Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen.
Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :

suffix "o=meineFirma, c=de"

sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.

Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"

'''Bitte beachten :'''
Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.

Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :

rootdn "cn=admin, o=meineFirma, c=de"

Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.

Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.

Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd

Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.

'''Code:'''
slappasswd >> passwort.txt

Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :

{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

Hinweis : Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war.

Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!!
Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!

Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :

rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C

nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.

'''Code:'''
rcldap start

Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.

Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )

Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.

Auch kann man mit :

'''Code:'''
nmap localhost

testen ob der Port 389 in Benutzung ist.

Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client )
kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.

Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten.
Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )

Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:

'''Code:'''

ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W

Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.

== Linux Authentifikation ==

Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.

Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich
an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.

Wir beginnen mit der Anmeldung an einem Linux System.
Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.

Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der /etc/group.

Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:

'''Code:'''

root:x:0:0:root:/root:/bin/bash

Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist.
Aus der shadow brauchen wir dann auch nur das Passwort.

Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein.
Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.

Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :

'''Code:'''

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/misc.schema

Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :

/usr/share/doc/packages/samba/examples/LDAP/samba.schema

Und sollte dann nach /etc/openldap/schema kopiert werden.

Damit wären erst einmal die Grundvoraussetzung erfüllt ...

'''HINWEIS :'''
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht.

Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt, mitlerweile aber aus anderen Quellem siehe -> http://www.linux-club.de/faq/Grafische_LDAP_Tools.

Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.

Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster"
Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".

In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen.
Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.

Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:

o (Organization)
ou (Organizational Unit)
posixAccount (Userdaten für Linux User)
posixGroup (Gruppeninformationen für Linux)

Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein.
Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit.
Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson.
Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.

Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.

Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus.
Dort sieht man dann die Templates die schon erstellt wurden.
Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.

In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen.
In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.

In diesem Fall ist das außer dem Eintrag dn noch das Attribut o.
Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.

Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen.
In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.

Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.

Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"

Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.

Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....

Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.

Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:

Code:

dn: cn=user, ou=groups, o=meineFirma, c=de
cn: user
gidNumber: 1500

Ähnlich sieht es bei dem Anlegen eines Users aus:

Code:

dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc

Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.

Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...

Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen.
Siehe z.B : http://www.padl.com/OSS/MigrationTools.html
_________________

== Einrichten eines LDAP Client ==

== LDAP und SAMBA ==

[[LDAP]]
[[Category:LDAP]]

OpenLDAP

2006-09-18T11:12:39Z

ThomasF: /* Aufsetzen eines Openldap-Servers */

OpenLDAP

2006-09-18T11:11:07Z

ThomasF: /* Aufsetzen eines Openldap-Servers */

OpenLDAP

2006-09-18T11:04:48Z

ThomasF: