[[Vorlage(Archiviert)]]
[[Vorlage(Fortgeschritten)]] 

{{{#!vorlage Wissen
[:Pakete installieren: Installation von Programmen]
[:Terminal: Ein Terminal öffnen]
[:sudo: Root-Rechte]
}}}
[[Inhaltsverzeichnis()]]

[[Bild(Wiki/Icons/service.png, 48, align=left)]]
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 [:Archiv/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 [wikipedia:Set-Top-Box: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.

{{{#!vorlage Befehl
sudo kinit some_new_admin/admin
ktadd cifs/server.my.realm.root
addprinc -randkey cifs/server.my.realm.root
}}}

{{{#!vorlage 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.

{{{#!vorlage Befehl
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 [http://gertranssmb3.berlios.de/output/pam.html#id2588910 SAMBA-Doku: pam_smbpass.so] {de})
 * 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 [http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#PASSWDCHAT SAMBA-Doku: passwd chat] {en}).

== 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 [http://www.pgina.org/index.php/Main_Page pGina-Authentication for Windows] {en}).

= 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 [:Archiv/Kerberos:] beschrieben, muss auf dem Client eine Kerberos-Umgebung installiert und konfiguriert sein. Wenn gegen einen Samba-Server arbeitet wird, reicht folgender Befehl:

{{{#!vorlage 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:

{{{#!vorlage Befehl
sudo net ads join -U Administrator%Passwort
}}}

{{{#!vorlage 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:

{{{#!vorlage Befehl
smbclient -k -L //server.my.realm.root/Share1
}}}
Kommt ein Listing, funktioniert die Authentifizierung. Mounten kann man die Freigabe wie folgt:

{{{#!vorlage Befehl
mount -t cifs //server.my.realm.root/Share1 /mnt/cifs-share -o sec=krb5
}}}

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

{{{#!vorlage Befehl
mount -t cifs //server.my.realm.root/Share1 /mnt/cifs-share -o sec=krb5,uid=1001
\}}}
}}}

{{{#!vorlage Warnung
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.
}}}

= Links =
 * [http://support.microsoft.com/kb/555092/en-us Microsoft KB 555092] {en} - Providing Active Directory authentication via Kerberos protocol in Apache
 * [:Archiv/Active_Directory_Client_Authentifikation:]
 * Samba3:
  * [http://www.samba.org/samba/docs/man/Samba-Guide/kerberos.html Samba-Doc: Active Directory, Kerberos, and Security] {en}
  * [http://gertranssmb3.berlios.de/output/domain-member.html Samba-Doc: Domänen-Mitgliedschaft] {de}
  * [:Samba:] im Ubuntuuser.de-Wiki:
 * [http://wiki.samba.org/index.php/Samba4 Samba4 Wiki] {en} - Dokumentation
 * [:Archiv/Kerberos:]
 * [:Serverdienste:] {Übersicht} Übersichtsartikel

# tag: Netzwerk, System, Sicherheit, Server, Kerberos