ubuntuusers.de

🛈 Aktuell gibt es im Wiki ca. 750 Artikel, die nur für Xenial getestet sind. Dies entspricht ca. 10 % aller Wikiartikel. Damit diese im nächsten Frühjahr nicht alle archiviert werden müssen, ist eure Mithilfe gefragt!

ActiveDirectory

Archivierte Anleitung

Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Wiki/Icons/service.png ActiveDirectory ist der Standard-Verzeichnisdienst der Firma Microsoft und dient in einer Windows-Umgebung als zentrale Instanz für Autorisierung, Rechte-Management und Benutzerverwaltung. Intern handelt es sich dabei um eine auf Kerberos und LDAP basierende Implementierung, die sich nicht ganz an die Standards hält. Im Gegenzug reicht es aber nicht, selbst einen Kerberos- und LDAP-Server unter Linux als ActiveDirectory zu betreiben.

Aktuell ist es nicht möglich, einen Windows-Client ohne weitere Maßnahmen gegen einen Kerberos v5 Server zu authentifizieren. Der Samba-Dienst ist erst ab Version 4 in der Lage, ein ActiveDirectory zur Verfügung zu stellen. Da diese Version derzeit jedoch nur als Testversion zur Verfügung steht, wird in diesem Artikel nur auf die aktuelle Samba Version 3 eingegangen.

Samba-Server

Wie eingangs erwähnt, ist es aktuell nicht möglich, ein ActiveDirectory unter Linux zur Verfügung zu stellen. Samba in Version 3 kann nur als "AD-Mitglied" betrieben werden. Das bedeutet, dass über vorhandene Kerberos-Tickets authentifiziert wird. Für homogene Linux-Netzwerke reicht das aus. Eine "echte" ActiveDirectory-Umgebung wird nicht benötigt.

Hat man es jedoch mit einem Netzwerk aus gemischten Betriebssystemen zu tun, bekommt man bei dieser Kombination ein Problem. Da sich Windows-Clients nicht gegen Open Source Kerberos-Systeme authentifizieren können, bekommen sie auch kein Ticket und somit keinen Zugriff auf Freigaben (Shares).

Voraussetzung für alle Konfigurationsszenarien ist eine funktionierende Kerberos-Umgebung und eine fertig vorkonfigurierte Samba-Installation.

Samba in einer homogenen "nicht Windows" Umgebung

Dies ist der einfachste Anwendungsfall und wird benutzt, wenn einige Geräte im Netzwerk angeschlossen sind, die Kerberos und CIFS/SMB unterstützen, aber nicht NFS. Zum Beispiel ein Router oder Embedded Devices wie TV-Set-Top Boxen. In diesem Fall reicht ein Samba-Server und ein Kerberos DC (KDC).

In der Konfigurationsdatei /etc/samba/smb.conf muss folgende Anpassung im Abschnitt "[GLOBAL]" gemacht werden:

security = ADS
realm = MY.REALM.ROOT
kerberos method = system keytab
encrypt passwords = true

Zusätzlich muss man noch ein passender Kerberos-Key in der Keytab des Servers hinterlegt werden.

sudo kinit some_new_admin/admin
ktadd cifs/server.my.realm.root
addprinc -randkey cifs/server.my.realm.root 

Hinweis:

Auch wenn beim Samba Server die Security auf ADS gesetzt wurde, authentifiziert SAMBA weiterhin Nutzer gegen das "passdb backend". Wurde SAMBA vorher als PDC betrieben oder sind in diesem Backend aus anderen Gründen Benutzer-Kennungen enthalten, können sich diese Nutzer weiterhin ohne Kerberos-Ticket anmelden. Das ist von den Entwicklern explizit so vorgesehen worden. Wenn man diesen Seitenkanal schließen will, muss man das "passdb backend" leeren / die unerwünschten Benutzer löschen.

Samba in einer heterogenen Umgebung mit Windows Clients

Aktuell ist die einzige Variante eines ActiveDirectory mit vollem Funktionsumfang ein Windows-Server als ActiveDirectory-Server. Der MIT- und Heimdal-Implementierungen von Kerberos können sich mit dem KDC des ActiveDirectory synchron halten und auch das LDAP-Directory kann man mit OpenLDAP spiegeln. Dies macht jedoch nur in größeren Netzwerken Sinn, da jeder der Open Source Kerberos-Clients ohne weiteres in der Lage ist, sich gegen ActiveDirectory zu authentifizieren bzw. diesen als KDC zu nutzen.

Soll in eine solche Umgebung ein Samba Datei-Server eingebracht werden, läuft alles wie im vorherigen Szenario, nur dass noch "weitere" Keys benötigt werden. Das kann man bequem über folgenden Befehl erledigen.

sudo net ads join -U Administrator%Passwort  

Samba mit Kerberos und PDC als FallBack

Dieses Szenario ist aktuell die einzige Möglichkeit, Windows-Rechnern einen SMB-Share zur Verfügung zu stellen, wenn kein "echter" ActiveDirectory-Server zur Verfügung steht. Dazu nutzt man den beschriebenen "Sonderfall" des Samba-Dienstes aus, dass dieser noch Anmeldungen (Logins) mit User-Credentials entgegen nimmt und gegen sein "passdb backend" authentifiziert, obwohl er nur ActiveDirectory-Benutzer zulassen sollte.

Nachteil dieser Variante ist, dass kein echtes "Single Sign On" (SSO) mehr möglich ist. Es wird immer zwei Passwörter geben, welche manuell synchron gehalten werden müssen. Das kann auch nicht gelöst werden, wenn Samba als "passdb backend" LDAP nutzt. Das Samba-Schema benutzt zwei weitere Password-Felder (sambaLMPassword und sambaNTPassword). Das Werkzeug smbpasswd setzt diese beiden und das Standart-Feld userPassword korrekt.

Kerberos kann LDAP als KeyStore benutzen oder LDAP kann mittels des SASL-Modus Kerberos zur Authentifizierung nutzen. In beiden Fällen gerät das Gespann Samba/Kerberos aus dem Tritt, sobald ein Benutzer von einem Client aus sein Password ändert. Entweder überschreibt smbpasswd den SASL-Modus oder Kerberos ändert userPassword, ohne die weiteren Felder nach zu ziehen. Auch wenn beide Authentifizierungs-Information in der gleichen Datenbank liegen, existieren de facto zwei Schlüssel-Datenbanken, von der der jeweils andere Dienst keine Kenntnis hat.

Der Vorteil der einheitlichen Benutzer-/Passwortverwaltung durch LDAP geht damit leider verloren. Wenn der Administrationsaufwand für die Synchronisation der User-ID/Group-ID über alle System geringer ist als das Einrichten und Verwalten eines LDAP-Servers, kann man auf LDAP an dieser Stelle auch verzichten.

Da die Passwörter sowohl bei Kerberos als auch bei Samba als Hashes/Keys gespeichert werden, ist eine nachträgliche Synchronisierung nicht möglich. Das Password muss vor dem Hashing auf das jeweils andere Backend gespiegelt werden. Folgende Möglichkeiten existieren:

  • Kerberos Passwortänderung am Client (kpasswd): Unter Linux kann man die Änderung des Passworts mittels PAM abfangen und an Samba übergeben. Dazu gibt es das PAM-Modul smbpass (siehe SAMBA-Doku: pam_smbpass.so 🇩🇪)

  • Passwortänderung von Windows-Clients (smbpasswd): Zu diesem Zweck gibt es unter Samba die Möglichkeit, auf dem Server ein Skript oder Programm aufzurufen, um die Passwortänderung weiterzuleiten (siehe SAMBA-Doku: passwd chat 🇬🇧).

Sonstige Möglichkeiten

Neben diesen Varianten gibt es noch die Möglichkeit, Samba in Version 4 selber zu bauen und als "echten" ActiveDirectory-Server in Betrieb zu nehmen. Dies ist derzeit jedoch für den Produktiveinsatz nicht zu empfehlen und daher auch nicht Teil dieses Artikels (Stand: Dezember 2011).

Als letzte Möglichkeit könnte man Windows-Clients so "patchen", dass sie sich direkt gegen Kerberos authentifizieren können und so kein ActiveDirectory nötig ist (siehe pGina-Authentication for Windows 🇬🇧).

Samba - Client

Auf Client-Seite ist die Konfiguration ungleich leichter. Für den Samba- und Kerberos-Client spielt es keine Rolle, ob gegenüber Kerberos oder ActiveDirectory authentifiziert wird. Wie im Hauptartikel Kerberos beschrieben, muss auf dem Client eine Kerberos-Umgebung installiert und konfiguriert sein. Wenn gegen einen Samba-Server arbeitet wird, reicht folgender Befehl:

sudo kinit some_new_admin/admin
ktadd cifs/client.my.realm.root 

Wenn man gegen einen ActiveDirectory-Server arbeitet, braucht man noch einen host-Principal. Man kann sich die Keytab aber auch einfacher mit folgendem Befehl erzeugen lassen:

sudo net ads join -U Administrator%Passwort 

Hinweis:

Dieser Befehl macht auch nichts anderes, als alle benötigten Keys zu erzeugen und in der Keytab zu hinterlegen. Leider wird dabei die bisherige Keytab geleert. Dementsprechend muss man die verlorenen Keys nachtragen.

An dieser Stelle kann man einen ersten Test machen:

smbclient -k -L //server.my.realm.root/Share1 

Kommt ein Listing, funktioniert die Authentifizierung. Mounten kann man die Freigabe wie folgt:

mount -t cifs //server.my.realm.root/Share1 /mnt/cifs-share -o sec=krb5 

Hinweis:

Schlägt das Einbinden (mounten) fehl, muss man noch die UID in den Optionen setzen:

mount -t cifs //server.my.realm.root/Share1 /mnt/cifs-share -o sec=krb5,uid=1001 

Achtung!

Mountet man CIFS in einer Multiuser-Umgebung, muss man beachten, dass CIFS die Verbindung mit der angegebenen UID kennzeichnet (flaggt). Beim Verbinden wird zwar geprüft, ob die UID zu den vorhandenen Kerberos-Keys passt, ist der Share aber erst einmal gemountet, findet keine weitere Prüfung statt. Greift ein anderer am Rechner angemeldeten Benutzer auf den gemounteten Share zu, tut er dies unter der UID des Mount-Users.

Auf Serverseite lässt sich nicht auseinander halten, von welchem Benutzer welche Aktion durchgeführt wurde. Sind am Client Benutzer mit Superuser-Rechten ausgestattet, können sie ohne Probleme auf jeden gemounteten Samba-Share zugreifen.

Diese Revision wurde am 18. April 2020 19:16 von Heinrich_Schwietering erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Kerberos, Sicherheit, System, Netzwerk, Server