Interop 5: Samba mit Kerberos an AD

In dieser Serie von Blogeinträgen möchte ich Schritt für Schritt erklären, wie man die Vorteile des AD auch für Linux nutzen kann. Ich hab mir gedacht, ist ein bisschen viel für einen Artikel, daher werde ich das jetzt abschnittweise vorstellen.

In den vergangenen Kapiteln haben wir ein Linux mit wenigen Schritten so aufgesetzt, dass es Benutzerinfos direkt aus einem AD holt und ein Login per Kerberos erlaubt. Hier möchte ich ein Beispiel zeigen, wie man das nicht nur für Login nutzen kann, nämlich beim Einsatz von Samba.

Samba macht einen Linux-Server, salopp gesagt, zu einem Windows-Fileserver. Hierzu gibt man Linux-Verzeichnisse per Samba frei, auf die Windows-Clients dann mit der dort üblichen Konvention, also per UNC-Pfad (\\server\sharename) zugreifen können. Samba kann sich als Member Server in eine Windows-Domäne einbringen und dann die Benutzerinfos des AD nutzen. Es verwendet dabei ein Modul namens „winbind“, das etwa vergleichbar ist mit der Nameservice-per-LDAP-Geschichte, die ich in Interop 2 beschrieben habe. Ok, winbind macht noch mehr, aber manchmal auch nicht alles richtig. Die Frage ist, ob man die zusätzliche Funktionalität braucht? Ich will mal kurz zeigen, was man mit einem „nackten“ Samba machen kann, und wie einfach das geht (vorausgesetzt, man ist auf dem Stand von Interop 4).

Einfach ein Samba installieren ohne winbind, falls nötig das winbind deaktivieren. Das winbind trägt sich (genau wie unser LDAP-Client) in die /etc/nsswitch.conf ein, dort gegebenenfalls das „winbind“ wieder rausnehmen und das „ldap“ drin lassen. Wir holen uns zum Test ein Kerberos-Ticket für einen Domänen-Admin-User, nennen wir ihn mal snape@CONTOSO.COM:

kinit snape@CONTOSO.COM

Wenn alles geklappt hat, sollten wir mit „klist“ ein krbtgt-Ticket sehen. Jetzt zur Samba-Konfiguration. Hier mal eine ganz einfache:

workgroup = CONTOSO
netbios name =
server string = %h server

security = ads
realm = CONTOSO.COM
encrypt passwords = true
password server = dc1.contoso.com
use kerberos keytab = yes

wins server = 10.0.0.1
wins support = no
domain master = no
local master = no
preferred master = no
os level = 0

logfile = /var/log/samba/log.%m
max log size = 1000

[temp]
comment = This is the (surprise!) TEMP folder
browseable = yes
writeable = yes
create mask = 0700
path = /tmp
public = yes

Samba benötigt ein paar mehr Principals, damit es richtig funktioniert, Bevor wir uns jetzt mit Keytabs abmühen, nutzen wir einfach ein Programm aus der Samba-Suite:

net ads join -U snape

Vorsicht: Damit wird eine eventuell schon existierende Kerberos-Keytab (unter /etc/krb5.keytab) überschrieben. Unser Samba geht jetzt davon aus, dass es alle Infos einfach aus der lokalen Benutzerverwaltung des Systems bekommt. Dass unser Linux sich die Daten selbst wieder von woanders holt, das bekommt das Samba gar nicht mit – und es interessiert sich auch gar nicht dafür. Die eigene Keytab, die Samba verwendet, die muss sein, da stehen jede Menge Principals drin.

Ein kleines Problemchen trübt das Bild, aber nur etwas: Winbind kann Windows-Gruppen automatisch mappen für Linux. Was das heißt? Beispiel: Ein Benutzer ist in der Windows-Gruppe Domänenbenutzer und hat die uidnumber 1001. Das reicht winbind schon an Infos aus. Winbind erkennt die Windows-Gruppe, macht eine weitere Abfrage nach der Gruppe, sucht deren uidnumber und liefert die mitsamt den restlichen Benutzerinfos in einem Paket zurück, also quasi als ob es eine einzige Abfrage gewesen wäre. Ohne winbind müssen wir dem Benutzer neben der uidnumber auch eine gidnumber geben, die seine primäre Gruppe beschreibt. Wir müssen also die Windows-Gruppen und die Unix-Gruppen beide pflegen.

Das klingt nach einem großen Nachteil, in der Praxis hat sich das nicht als kompliziert herausgestellt: Entweder man hat ein Identity Management System, das macht das dann automatisch (wenn man es so programmiert hat oder genug Geld für den Consultant hatte), oder man zieht Änderungen händisch nach. Letzteres birgt die Gefahr, Inkonsistenzen zu erzeugen, wo die Windows-Gruppen und Unix-Gruppen nicht mehr übereinstimmen, aber da kann ein Check-Script zum Einsatz kommen, der stündlich das AD durchsucht nach solchen Fällen. Solche Check-Scripte sind sowieso was Feines, und dieser hier ist recht simpel.

Wenn man mit obiger smb.conf (Neustart des Samba-Deamon nicht vergessen!) jetzt von einem Windows-Domänen-Client ein Share zum Client aufmacht (\\client1\temp), dann sollte das Temp-Verzeichnis jetzt angezeigt werden, so ganz ohne Benutzername und Passwort. „Moment!“ werden jetzt einige sagen, das geht doch auch sonst. Korrekt, allerdings speichert der Windows Client die Login-Informationen zwischen und schickt sie bei Bedarf an den Client (unter gewissen Randbedingungen). Aber hier ist das anders. Einfach mal auf dem Client ein „klist“ eingeben, und schon sollte man ein Ticket sehen mit dem Diensttyp „CIFS“, und das bekommt man eben nur bei einer Kerberos-Authentifizierung. Nix mehr Passwort übers Netz.

Das mit der eigenen Kerberos-Keytab hat übrigens noch einen anderen Nachteil, wenn es darum geht, für andere Dienste eine Keytab zur Verfügung zu stellen, zum Beispiel für einen Apache-Server. Dazu mehr in einem eigenen Kapitel.

Übrigens: Wen das mit der gidnumber usw näher interessiert, auch dafür gibt es hier einen Blogeintrag.

Advertisements

Über Ralf Wigand

...arbeitet für Microsoft und war von 2008-2015 MVP für Directory Services.
Dieser Beitrag wurde unter Active Directory, Kerberos, LDAP, Linux, Windows Server veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s