© Gold Stock Images, Fotolia

Mit Samba 4 lässt sich ein Active-Directory-kompatibler Domain Controller betreiben. Das Linux-Magazin schaut sich die Choreografie des darin enthaltenen LDAP-Verzeichnisses genauer an.

Samba 4 landete nach Jahren der Entwicklung im Dezember 2012 in den Repositories. Die größte Neuerung: Anders als ihre Vorgängerversionen kann die Software einen Active-Directory-kompatiblen Domain Controller (DC) betreiben. Da zu den Hauptkomponenten eines Active Directory (AD) ein LDAP-Verzeichnis gehört, bringt auch Samba 4 einen solchen Dienst mit.

Zwar konnte bereits Samba 3 für bestimmte Funktionen (unter anderem zur Authentifizierung von Benutzern) ein LDAP-Backend verwenden, der LDAP-Server steckte jedoch nicht direkt in Samba. Vielmehr musste der Admin einen Open-LDAP-Server ankoppeln, was unter anderem die Kompatibilität mit Active Directory verhinderte. Die Besonderheiten des LDAP-Servers von Samba 4 und die Unterschiede gegenüber Open LDAP schildert dieser Artikel.

Samba 4 ist inzwischen in der Version 4.2 zu haben und steht für viele Linux-Distributionen bereit. Nach der Installation absolviert der Admin mit dem Kommandozeilen-Werkzeug »samba-tool« zunächst das initiale Setup. Das klappt zum Beispiel interaktiv mit folgendem Befehl:

samba-tool domain provision --use-rfc2307 --interactive

Der Konfigurationsassistent fragt sämtliche relevanten Parameter wie beispielsweise den Domainnamen ab und stellt anschließend einen komplett funktionsfähigen Domain Controller mit allen relevanten Komponenten bereit. Im gleichen Zuge legt »samba-tool« auch das für das Active Directory genutzte LDAP-Verzeichnis an. Die Option »–use-rfc2307« sorgt dafür, dass das Tool das Schema um Posix-Attribute wie beispielsweise »uidNumber« oder »gidNumber« erweitert. Das ist insbesondere in solchen Fällen nützlich, in denen Active Directory auch auf Linux- oder Unix-Systemen zum Einsatz kommen soll.

Active Directory mit Windows nutzen

Zuerst integriert der Admin mit den üblichen Methoden [2] einen Windows-Client in die Domäne. Zudem sollten Microsofts Remote Server Administration Tools (RSAT) installiert sein, Details stehen unter [3]. Danach kann der Samba-Tänzer mit Hilfe der Microsoft Management Console (MMC) und bestimmten Erweiterungen (so genannten Snapins) verschiedene administrative Tätigkeiten im Active Directory erledigen.

Abbildung 1: Über die grafische Microsoft Management Console (MMC) erledigt der Admin unter Windows Arbeiten im Active Directory.

Abbildung 2: Für einzelne Benutzer lassen sich in Aduc detaillierte Eigenschaften anzeigen.

Mit dem Snapin Active Directory Benutzer- und Computer Management (Aduc, Abbildung 1) kann er im Active Directory, wie der Name schon vermuten lässt, Benutzer und Computer, aber auch Gruppen oder Kontakte verwalten. Wie üblich erzeugt und löscht er Benutzer und Gruppen, ändert aber auch eine ganze Reihe von benutzerspezifischen Attributen (Abbildung 2), die Samba 4 meist direkt im LDAP-Verzeichnis des Active Directory speichert.

Abbildung 3: ADSI-Editor mit dem Domain-Controller-Objekt in der Detailansicht. Mit ihm kann ein Admin vom Windows-Client aus die komplette Baumstruktur des LDAP-Verzeichnisses betrachten.

Der vollständige Zugriff auf das LDAP-Verzeichnis gelingt jedoch nur mit einem weiteren Snapin, dem so genannten ADSI-Editor (Abbildung 3). Mit ihm lässt sich die komplette Baumstruktur des LDAP-Verzeichnisses betrachten und jedes einzelne Objekt mitsamt seinen Attributen modifizieren.

Der AD-Zugriff mit dem Linux-Client

Soll lieber ein Linux-Client auf das LDAP-Verzeichnis des Active Directory zugreifen, warten auch hierfür verschiedene Möglichkeiten. Funktional vergleichbar zum MMC-Snapin Aduc ist das beim Setup bereits erwähnte Werkzeug »samba-tool« . Mit ihm lassen sich Benutzer, Gruppen, Computer und viele weitere Eigenschaften des Domain Controllers anzeigen und verändern. Das nachfolgende Beispiel legt einen neuen Benutzer an, der dann im Active Directory unter »CN=musterfrau,CN=Users,DC=samdom,DC=example,DC=com« zu finden ist:

$ samba-tool user add musterfrau 'Gehe!mes_ Passwort'User 'musterfrau' created successfully

Für den direkten Zugriff auf das Active Directory verwendet der Administrator üblicherweise die LDAP-Tools des Open-LDAP-Projekts. Die vier wichtigsten Befehle heißen »ldapsearch« , »ldapmodify« , »ldapadd« und »ldapdelete« .

01 # Sucht das Objekt cn=musterfrau:
02 $ ldapsearch -h localhost -D administrator@samdom.example.com -w passwort -b "DC=samdom,DC=example,DC=com" cn=musterfrau
03 dn: CN=musterfrau,CN=Users,DC=samdom,DC=example,DC=com
04 objectClass: top
05 objectClass: person
06 objectClass: organizationalPerson
07 objectClass: user
08 cn: musterfrau
09 instanceType: 4
10 whenCreated: 20150506072613.0Z
11 uSNCreated: 3717
12 name: musterfrau
13 objectGUID:: w3eYpj4DV0uxXKMNck38mg==
14 badPwdCount: 0
15 codePage: 0
16 countryCode: 0
17 badPasswordTime: 0
18 lastLogoff: 0
19 lastLogon: 0
20 primaryGroupID: 513
21 objectSid:: AQUAAAAAAAUVAAAA17nMHW51+5zqbADQUAQAAA==
22 accountExpires: 9223372036854775807
23 logonCount: 0
24 sAMAccountName: musterfrau
25 sAMAccountType: 805306368
26 userPrincipalName: musterfrau@samdom.example.com
27 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
28 pwdLastSet: 130753707740000000
29 userAccountControl: 512
30 whenChanged: 20150506074453.0Z
31 uSNChanged: 3720
32 distinguishedName: CN=musterfrau,CN=Users,DC=samdom,DC=example,DC=com

Aber anders als bei Open LDAP muss sich der Nutzer stets beim Active Directory authentifizieren. Das heißt, der so genannte anonyme Zugriff, der bei Open LDAP üblicherweise den lesenden Zugriff auf nicht sicherheitsrelevante Objekte ermöglicht, funktioniert beim Active Directory nicht, es erwartet vielmehr für alle Aktionen, lesend oder schreibend, immer eine Authentifizierung.

$ ldapmodify -h localhost -D administrator@samdom.example.com -w passwort -f add_mail.ldif

dn: CN=musterfrau,CN=Users,DC=samdom,DC=example,DC=com
changetype: modify
add: mail
mail: musterfrau@example.com

Die erfolgt zum Beispiel über den Benutzer-DN gefolgt von einem Passwort oder mit Hilfe eines Kerberos-Tickets. Die Listings 1 und 2 liefern Beispiele zu »ldapsearch« und »ldapmodify« . Tabelle 1 zeigt, was die Optionen für »ldapmodify« im Detail bewirken.

Parameter wie beispielsweise den Hostnamen oder den Base Distinguished Name konfiguriert der Admin bei Bedarf in der Datei »/etc/ldap/ldap.conf« , wenn er diese nicht bei jedem Aufruf der LDAP-Tools auf der Kommandozeile erneut angeben möchte. Hat er zusätzlich noch ein gültiges Kerberos-Ticket im System, ruft er »ldapsearch« sogar ganz ohne Optionen auf.

Etwas komfortabler lassen sich LDAP-Objekte jedoch mit dem Kommandozeilentool »ldapvi« [4] betrachten und modifizieren. Dieses Werkzeug, das der Admin auf Wunsch mit diversen Optionen füttert, öffnet im Prinzip die Ausgabe von »ldapsearch« in einem Editor (Abbildung 4) und macht es dem Admin auf diese Weise sehr einfach, LDAP-Attribute zu verändern.

Abbildung 4: Mit dem Werkzeug »ldapvi« betrachtet und modifiziert der Administrator auf Linux-Systemen LDAP-Objekte. Er kann es mit verschiedenen Optionen aufrufen.

Objektklassen und Schemata im AD

Jedes Objekt eines LDAP-Verzeichnisses besteht aus einer oder mehreren Objektklassen. Diese definieren, aus welchen Attributen sich ein Objekt zusammensetzt. Ein Benutzerobjekt besteht im AD zum Beispiel aus den Objektklassen »top« , »person« , »organizationalPerson« und »user« , die wiederum unzählige Attribute für das Objekt definieren.

So genannte Schemata bestimmen die Struktur der Attribute und Objektklassen. Sie legen zum Beispiel fest, aus welchen Zeichen der Wert eines Attributs bestehen darf oder ob ein Attribut zwingend einen Wert erhalten muss oder ein optionales Attribut ist. Für AD gibt es unzählige von Microsoft vordefinierte Objektklassen und Attribute, eine Übersicht liefert [5]. Wer sich die im AD aktiven Schemata ansehen möchte, erledigt dies am besten über eine LDAP-Suche. Dafür muss er lediglich die Basis-DN auf »CN=SCHEMA,CN=Konfiguration,DC=…« setzen. Bei einem Samba-4-Server stecken die AD-Schemata in der Datei »sam.ldb« (meist unter »/var/lib/samba/private/« ).

Die Kommandozeilenbefehle »ldbsearch« , »ldbmodify« sowie »ldbadd« (die der Admin im Wesentlichen wie die LDAP-Tools bedient) bearbeiten die Schemata aus dieser Datei direkt. Damit lassen sich zum Beispiel eigene Schemata in ein Active Directory integrieren. Ohne eine vorherige Sicherung sollten die LDAP-Einrichter solche Aktionen allerdings nicht umsetzen. Ein Beispiel für eine Schema-Erweiterung zeigt [6].

Definierte Container

Container sind Objekte im Active Directory, die andere Objekte enthalten. Während in Open LDAP jedes Objekt weitere Objekte enthalten kann, definiert AD sehr genau, welche Objekte das dürfen. Unterhalb der Basis-DN gibt es (unter anderem) folgende Standardcontainer:

• »CN=Builtin« : Unterhalb dieses Objekts befinden sich Microsofts Standardgruppen, zum Beispiel »Administrators« und »Server Operators« .
• »CN=Users« : Hier sammeln sich standardmäßig alle Benutzer, Gruppen und Kontakte, welche die Admins anlegen, sowie einige vordefinierte Benutzer und Gruppen. Natürlich lassen sich weitere Container anlegen, um eine eigene Struktur umzusetzen.
• »CN=Computers« : Hier landen alle in die Domäne aufgenommenen Computer.
• »OU=Domain Controllers« : Wer sich fragt, warum in »CN=Computers« der Domain Controller nicht auftaucht: Er hat im Active Directory eine eigene Organisational Unit (OU) bekommen.

LDAPServer ldap://ldap.example.com
LDAPBindDN "cn=admin,dc=example,dc=com"  "Admin-Passwort"LDAPUsers dc=users,dc=example,dc=com  (uid=%u) (uidNumber=%u)

Von den Objektklassen her unterscheidet sich ein Domain Controller also nicht von einem normalen Computer. Doch gibt es ein weiteres Unterobjekt namens »CN=RID Set« , das unter anderem den nächsten freien RID (Relative Identifier) enthält.

Natürlich ist es auch möglich, selbst definiert Container anzulegen, um etwa die eigene Unternehmensstruktur abzubilden.