Ich hatte gerade wieder eine Diskussion über User Mapping bei einem Unix Server
und habe mal das Thema kurz zusammengefasst.
Benutzerkennungen und Linux/Unix-User Mapping
Was bedeutet User Mapping oder warum ist dies für
jede Verwendung von Linux/Unix-SMB-Filern so wichtig?
Das Problem:
MicrosoftWindows, wo SMB herkommt, verwendet Windows-Sicherheitskennungen (SID z.B. S-1-5-21-722635049-2797886035-3977363046-1234), um Benutzer oder Gruppen zu identifizieren oder Freigaben, Dateien und Ordnern ACL-Berechtigungen zuzuweisen. Da der zugehörige Server Teil der SID ist, hat ein Domänenbenutzer eine weltweit eindeutige SID.
Linux oder Unix verwenden eine einfache Zahl wie 1021 für einen Benutzer (uid) oder eine Gruppe (gid). Dies bedeutet, dass eine Unix Benutzer-ID nicht eindeutig sein kann. Einige wie root mit der Benutzer-ID 0 sind sogar auf jedem Unix-Server auf der Erde gleich.
Nutzer und Gruppen mit Unix uid/gid und Windows SID
Jeder SMB-Client benötigt die Windows-SID unbedingt als Referenz. Die Unix-uid/gid wird ansonst für Linux/Unix-Dateifreigabemechanismen wie NFS verwendet. Da ZFS jedoch ein Unix-Dateisystem ist, benötigt jede Datei die Unix-uid/gid-Referenz. Das heißt, wenn ein Windows-Benutzer mit der SID S-1-5-21-722635049-2797886035-3977363046-1234 eine Datei schreibt, ist die Unix-Eigentümer-uid der Datei auf der Festplatte eine einfache Zahl wie 1021. Wenn man eine Beziehung zwischen beiden benötigt, braucht man ein ID-Mapping, was eine Zuordnung zwischen den beiden Nummern bedeutet.
Dies ist kein Problem in einer Einzelserver-/lokalen Benutzerumgebung, in der die SID z.B. S-1-5-21-722635049-2797886035-3977363046-1021 aus einet Unix-Benutzer uid z.B. uid 1021 generiert wird. Eine weitere Alternative ist es diese Zuordnung aufgrund des Benutzernamen zuzuordnen, z.B. Winuser: paul = Unixuser: paul oder Winuser:* = Unixuser:*, wo man aber einen lokalen Unix-Benutzer für jeden Windows-Benutzer mit demselben Namen haben sollte. Mit beiden Optionen kann man Unix-Berechtigungen und Windows-Berechtigungen transparent zuordnen.
SMB-Gruppen
Ein Problem tritt auf, wenn man die Funktionalität von Windows-Gruppen verwenden möchte, bei denen einer Gruppe z. B. "Administratoren" oder "Backup-Operatoren" eine Rolle zugewiesen werden kann, oder wenn man Gruppen benötigt, die Gruppen enthalten können. Unix-Gruppen bieten eine solche Funktionalität nicht. Nur Solaris und seine Forks bieten dies, da sie zusätzlich zu Unix Gruppen eine SMB-Gruppenverwaltung eingebaut haben.
Backup wiederherstellen
Wenn man Dateien sichern und auf einem anderen Server wiederherstellen möchte, hat man das Problem, dass die Berechtigungen nicht erhalten bleiben oder konsistent sind, da beispielsweise ein Benutzer mit der uid 1021 auf dem ersten Server paul und auf dem anderen hanns oder unknown ist. Man benötigt spezielle Einstellungen, Mechanismen oder Zuordnungstabellen, um das Problem zu lösen oder einen zentralisierten Mechanismus wie Active Directory mit Unix-Erweiterungen, um allen Benutzern in der der AD Domäne eine konsistente uid/gid zuzuweisen. Nicht so einfach und simpel wie in einer reinen Windows Server-Umgebung, aber normalerweise die einzige Option, z. B. mit einem Unix-SMB-Server wie SAMBA.
Die Sun-Entwickler waren sich dieses Problems bewusst. Als sie den Kernel-basierten Solaris-SMB-Server in das Betriebssystem und ZFS einbauten benutzten sie nicht die Unix-uid/gid als Sicherheitsreferenz, sondern direkt die Windows-SID als erweitertes ZFS-Dateiattribut. Das bedeutet, wenn man einen Solaris-AD Dateiserver sichert und die Dateien auf einem anderen AD-Server wiederherstellt, bleiben alle ACL ohne weitere Maßnahme intakt.
Wie kann Windows SID als SMB-Dateireferenz in einer Windows Active Directory funktionieren,
da ZFS ein Unix-Dateisystem ist, in dem jede Datei eine Unix-uid/gid benötigt?
Sun löste das Problem mit ephemeral Mappings. Dies ist eine temporäre uid, die nur während einer aktiven SMB-Sitzung gültig ist, um die Unix-Anforderungen zu erfüllen. Für den kernelbasierten SMB Server ist die uid nicht relevant und wird nicht verwendet.
Alles perfekt und die ultimative Lösung auf Solaris/Illumos für SMB. Wenn man aber eine strikte Beziehung zwischen SMB-Benutzern und Unix-Benutzern benötigt, z. B. für spezielle Anwendungen oder Multiprotokoll-Sharing, benötigt man aber auch unter Solaris/Illumos User Mapping, entweder mit einer Mapping-Tabelle oder einer zentralisierten uid/gid für jeden Benutzer vom AD-Server.
Besonderheit von dem kernelbasiertem Solaris SMB Server zusammengefasst
Native Verarbeitung von Windows SID, Windows ntfs artige ACL, Windows-kompatible SMB-Gruppen und ZFS-Snaps ohne Konfiguration = Windows-Vorversionen sind die Alleinstellungsmerkmale für den Solaris- und Illumos-SMB-Server gegenüber der Alternative SAMBA die auch unter Solaris verfügbar ist. Da die NFS- und SMB-Freigabe eine strikte ZFS-Eigenschaft eines Dateisystems ist, ist das Akivieren eines NFS/SMB Shares ein einfaches Ein-/Ausschalten mit zfs set share =on/off (keine samba.cfg)
). Ich hab z.B. unter Solaris schon erst die neue Platte hinzu gesteckt, dann eine vorhandene durch die neue ersetzt (resilver) und erst im nachhinein die alte Platte gezogen. Im Übrigen sieht ja ZFS auch ausdrücklich die Option vor, dem Pool ein "Hot Spare" zuzuordnen, worauf dann eben auch bei Bedarf resilvered werden kann. Siehe z.B.:
