Samba als PDC in der Version 3.x mit ACLs sowie
Kontenmangement mit dem MS-Tool „Usermanager for Domains“



Angeregt durch das Tutorial von Marcus Rossmann dachte ich mir, es sei sinnvoll, hier anzuknüpfen und basierend auf SLES 9 bzw. SuSe Prof. 9/10 und Samba 3.0.2a eine aktuellere Version hinzuzufügen. Dies im besonderen, da sich gerade bezüglich des Groupmappings sowie der mächtigen net-Befehlsgruppe einiges getan hat.

Ziel soll sein, einen Samba-PDC einzurichten, welcher neben den homes und profiles eine netlogon-share sowie Daten hält. Die Authentifizierung erfolgt über das tdbsam-Backend, die gesamte Kontenverwaltung über das kostenlose MS-Tool „Usermanager for Domains“ (www.microsoft.com)
welches es auch „nicht-Linux-kundigen“ Administratoren erlaubt, Benutzer und Gruppen von einer NT- oder XP-Workstation aus zu modifizieren.
Dieses kleine Tutorial will kein Tiefenwissen vermitteln, sondern anhand eines schnellen Erfolges zum Experimentieren und Weiterlernen anregen.

Ich arbeite zwar mit SuSe SLES 9 / SP3 doch gilt das Folgende auch für die Versionen SuSe 9 und 10. Unter der Anpassung der Pfade sollte das Gesagte aber auch für andere Distributionen gelten.


OK. Neu in Samba 3.x ist das sog. Groupmapping, welches beinhaltet, dass globale Domänengruppen auf lokale Unixgruppen abgebildet – gemappt - werden . Jeder, der schon einmal mit der Verwaltung einer MS-Domäne zu tun hatte, kennt sie: die Domänenadministratoren, -benutzer und –gäste. Genauso die lokalen Gruppen wie Druckoperatoren, Hauptbenutzer, Sicherungsoperatoren usw. , welche nach der Installation von Microsoft Workstation oder Server bereits angelegt sind. Es handelt sich hier um sog Built-in-Groups von denen drei für eine Domäne unerlässlich sind: das sind die Domain Admins mit der rid 512, die Domain Users, rid 513 sowie die Domain Guests mit der rid 514.
Ebenso notwendig ist das Vorhandensein einer SID, ( S-1-5-21..... ) welche der Domäne eindeutig zugeordnet sein muss.
Nach der Installation von Samba 3.x wird ein solche SID erzeugt, welche die einzurichtende Domäne eindeutig identifiziert. Wir erhalten diese SID mit dem Befehl
net groupmap list

System Operators (S-1-5-32-549) -> -1
Replicators (S-1-5-32-552) -> -1
Guests (S-1-5-32-546) -> -1
Domain Users (S-1-5-21-3732367786-856876144-3282938955-513) -> -1
Domain Admins (S-1-5-21-3732367786-856876144-3282938955-512) -> -1
Power Users (S-1-5-32-547) -> -1
Domain Guests (S-1-5-21-3732367786-856876144-3282938955-514) -> -1
Print Operators (S-1-5-32-550) -> -1
Administrators (S-1-5-32-544) -> -1
Account Operators (S-1-5-32-548) -> -1
Backup Operators (S-1-5-32-551) -> -1
Users (S-1-5-32-545) -> -1

Und da sind sie, unsere MS Built.in-Groups. An dieser Stelle müssen nun die lebensnotwendigen Gruppen (rid 512-514) auf vorhandene Unixgruppen gemappt werden um sie für die Administration von einem Windows-Client aus zugänglich zu machen. Hier können Standard Unixgruppen (ntadmin, users, guests) oder eigene verwendet werden. Der Befehl zum mappen lautet:
net groupmap modify ntgroup=[Gruppenname] unixgroup=[Gruppenname]

Wenn wir also Die MS-Domänengruppe Domain Admins auf die Unixgruppe ntadmin abbilden möchten, so wäre das:

net groupmap modify ntgroup=“Domain Admins“ unixgroup=ntadmin

Diesen Schritt wiederholen wir für die Domain Users und Domain Guests und erhalten mit
net groupmap list

System Operators (S-1-5-32-549) -> -1
Replicators (S-1-5-32-552) -> -1
Guests (S-1-5-32-546) -> -1
Domain Users (S-1-5-21-3732367786-856876144-3282938955-513) -> users
Domain Admins (S-1-5-21-3732367786-856876144-3282938955-512) -> ntadmin
Power Users (S-1-5-32-547) -> -1
Domain Guests (S-1-5-21-3732367786-856876144-3282938955-514) -> nobody
Print Operators (S-1-5-32-550) -> -1
Administrators (S-1-5-32-544) -> -1
Account Operators (S-1-5-32-548) -> -1
Backup Operators (S-1-5-32-551) -> -1
Users (S-1-5-32-545) -> -1

Wie bereits erwähnt, sind alle anderen Built-in-Groups zur Einrichtung einer Domäne nicht erforderlich.. Der Parameter modify wird hier verwendet, da die zu mappenden NT-Gruppen bereits existieren. Sollte mal der Fall eintreten, ein mapping vollständig an der Linuxconsole eingeben zu müssen, ist dies natürlich auch möglich. Als Erstes wird hierzu mit
groupadd[Gruppenname] eine lokale unixgruppe erstellt. Dann erfolgt das mapping mit
net groupmap add unixgroup=[Gruppenname] ntgroup=[Gruppenname] type=domain
Also: groupadd testgruppe
Net groupmap add unixgroup=testgruppe ntgroup=testgruppe type=domain

Unser net groupmap list würde nun ergeben:

System Operators (S-1-5-32-549) -> -1
Replicators (S-1-5-32-552) -> -1
Guests (S-1-5-32-546) -> -1
testgruppe (S-1-5-21-3700398112-441439466-3868696347-3003) -> testgruppe
Power Users (S-1-5-32-547) -> -1
Print Operators (S-1-5-32-550) -> -1
Administrators (S-1-5-32-544) -> -1
Domain Users (S-1-5-21-3700398112-441439466-3868696347-513) -> users
Domain Admins (S-1-5-21-3700398112-441439466-3868696347-512) -> ntadmin
Account Operators (S-1-5-32-548) -> -1
Domain Guests (S-1-5-21-3700398112-441439466-3868696347-514) -> nobody
Backup Operators (S-1-5-32-551) -> -1
Users (S-1-5-32-545) -> -1



Bevor wir zur smb.conf kommen und die beiden deamons nmb und smb erstmalig starten, ist noch ein Schritt notwendig. Da später das Anlegen von Benutzern über das Script useradd erfolgt, ist es erforderlich die Standardeinstellungen für neu erstellte Benutzer zu ändern.
Dazu starten wir yast/Sicherheit und Benutzer/Benutzer bearbeiten und anlegen und wählen dann Optionen für Experten/Standardeinstellung für neue Benutzer.
Die Standardgruppe sollte die sein, auf welche die NT-Gruppe Domain users gemappt ist.
Die sekundären Gruppen (uucp, dailout etc) sollten entfern werden; Microsoft kennt diese Gruppen nicht und quittiert das mit entsprechenden Fehlermeldungen.
Die Standard Shell sollte auf /bin/false gesetzt werden – ein Windowsbenutzer benötigt keine shell.
Der Pfad für das home-Verzeichnis sollte an dieser Stelle, falls nötig, angepasst werden.

So weit, so gut; kommen wir zur smb.conf:

[global]

workgroup = tuxdom # Name der Domäne
netbios name = pegasus # Netbiosname des PDC
server string = samba_pdc # Kommentar
security = user # Benutzername/Passwort erforderlich
domain master = yes # dient als Hauptbrowser f. Netbiosn.
domain logons = yes # Server ist Authentifizierungsserver


passdb backend = tdbsam # neben smbpasswd, winbindd, oder ldap
# ein weiterer Authentifizierungsmecha.
add user script = /usr/sbin/useradd "%u" -m
add machine script = /usr/sbin/useradd -s /bin/false "%u" -g machines
add group script = /usr/sbin/groupadd "%g"
add user to group script = /usr/sbin/groupmod -A "%u" "%g"
delete user from group script = /usr/sbin/groupmod -R "%u" "%g"
delete group script = /usr/sbin/groupdel "%g"
delete user script = /usr/sbin/userdel "%u"
set primary group script = /usr/sbin/usermod -g "%g" "%u"
wins support = yes # Server bietet WINS-Support
logon path = \\%L\profiles\%U # Profilverzeichnis
logon script = ntlogon.cmd # loginscript
logon drive = P: # Laufwerksbuchstabe, auf den home
# gemappt wird

Der Usermanager for Domains benutzt die Zeilen 2-9 zur vollständigen Verwaltung von Benutzern und Gruppen. Zur Bedeutung der einzelnen Parameter sei auf die manpages verwiesen. Bitte beachten, dass die Gruppe machines noch angelegt werden muss.
Nun die drei Systemfreigaben:

[netlogon]

path = /local/samba/netlogon
read only = yes
browseable = no

[profiles]

path = /local/samba/profiles
read only = no
browseable = no
create mask =700
directory mask = 700

[homes]

path = /local/samba/homes/%S
valid users = %S
read only = no
browseable = no
read only = no
create mask = 700
directory mask = 700


.
Nun müssen wir noch mit smbpasswd –a root den Benutzer root und Samba einander bekannt machen sowie mit rcnmb start und rcsmb start samba starten (bitte nicht vergessen diese deamons später automatisch starten zu lassen).
An der console des Servers geben wir nun testparm , ein script zur logischen und syntaktischen Überprüfung der smb.conf, ein. Das Ergebnis sollte so aussehen:

Load smb config file from [Pfad zur smb.conf]
Processing section „[netlogon]“
Processing section „[profiles]“
Processing section „[homes]“
Loaded services file OK
Server role ROLE_DOMAIN_PDC


Wenn wir soweit sind, ist es an der Zeit einen Windows-Client der Domäne anzuschließen.
Dies wird wie gewohnt durch einen Wechsel aus der Arbeitsgruppe in die Domäne tuxdom erledigt. Der hierzu berechtigte Benutzer ist natürlich root mit seinem samba-Passwort.
Achso: in Grunde gibt es nur einen „echten“ Domänenadmin, und das ist root. Zwar ist es möglich durch username map = file in der [global] Sektion auch Claudia und Peter auf root zu mappen, jedoch habe ich es bisher noch nicht fertig gebracht, dass diese Benutzer ein von root abweichendes Kennwort benutzen können.

Nach erfolgtem Domänenanschluß rufen wir den Usermanager auf und setzten zuerst die Primary Group des Benutzers root auf Domain Admins. Dies deshalb, da die Windows-Clients mit der Primary Group root ( in dieser ist der Benutzer root per default) nichts anfangen können. Danach nehmen wir die globale Gruppe Domain Admins in die lokale Gruppe Administratoren auf.
So, nun Benutzer ,Gruppen und einige Maschinenkonten anlegen; Mitgliedschaften zuweisen und sehen, ob alles funktioniert.

ACLs

In der Windowswelt reicht das einfache Berechtigungssystem von Unix mit rwx für owner, group and other oftmals nicht aus, so daß hier ACLs herhalten müssen. Nehmen wir an, wir hätten eine Datei, eine Gruppe, nennen wir sie Gruppe1 und drei user in dieser Gruppe mit user1, user2 und user3. User1 und 2 sollen schreibenden, user3 nur lesenden Zugriff haben.
Die beiden zentralen Befehle hier sind getfacl zum Betrachten der ACLs und setfacl zum Setzen.
Schauen wir uns das bei ein von root erstellten Datei ohne ACLs an:

a) getfacl Datei ergibt # file: datei1
# owner: root
# group: ntadmin
user::rw-
group::rw-
other::---

Dies entspricht einem 660.

Nun setzen für Gruppe1 Schreibrecht:

b) setfacl –m group:Gruppe1:rw datei1 und getfacl bringt:

# file: datei1
# owner: root
# group: ntadmin
user::rw-
group::rw-
group:Gruppe1:rw-
mask::rw-
other::---

Und da wir wollen, dass user3 nur Leserecht erhält:

c) setfacl –m user:user3:r datei1 ergibt:

# file: datei1
# owner: root
# group: ntadmin
user::rw-
user:user3:r--
group::rw-
group:Gruppe1:rw-
mask::rw-
other::---



Selbstverständlich ist auch folgendes Szenario denkbar: 2 Gruppen, davon hat eine Lese- die andere Schreibrecht auf ein Verzeichnis:

d) setfacl –m g:Gruppe1:rwx,g:Gruppe2:rx testdir/ ergibt:

# file: testdir
# owner: root
# group: ntadmin
user::rwx
group::rwx
group:Gruppe1:rwx
group:Gruppe2:r-x
mask::rwx
other::---

Es gibt drei Möglichkeiten, bestehende Rechte zu ändern:

Mit setfacl –m g:Gruppe2:rwx testdir/ erhält Gruppe2 ebenfalls Schreibrecht aus Beispiel d). mit setfacl g:Gruppe1:r wird in b) Gruppe1 das Schreibrecht auf die Datei entzogen.
Mit setfacl –x g:Gruppe2 testdir/ wird Gruppe2 völlig aus der ACL entfernt.
setfacl –b testdir/ entfernt alle ACLs.

Eine weitere interessante Möglichkeit ist das Setzen von default Rechten. Diese geben an, mit welchen ACLs Dateien und Verzeichnisse erzeugt werdern.

e) Mit setfacl –d –m g:Gruppe1:rwx,g:users:rx testdir/ erhalten wir:

# file: testdir
# owner: root
# group: ntadmin
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:group:users:r-x
default:group:Gruppe1:rwx
default:mask::rwx
default:other::---

Gruppe1 hat also Schreibrecht auf alle neuen Dateien und Verzeichnisse, users (Domain User) Leserecht.
Hier steckt auch eine kleine Stolperfalle: diese ACL besagt, dass neue Objekte mit diesen Rechten erstellt werden, sie besagt jedoch nicht, dass wir das auch jetzt schon dürfen!

f) Hierzu ist noch setfacl –m g:Gruppe1:rwx,g:users:rx testdir/ nötig. Wir haben dann:

# file: testdir
# owner: root
# group: ntadmin
user::rwx
group::rwx
group:users:r-x
group:Gruppe1:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:users:r-x
default:group:Gruppe1:rwx
default:mask::rwx
default:other::---


Weiterhin ist die mask Option noch erwähnenstwert. Mit ihr ist es möglich, für alle Zugriffsberechtigten – mit Ausnahme des Eigentümers - den Zugriff auf default-Werte zu setzen.
Hierzu noch einmal unser Beispiel f):

g) mit setfacl –m mask:r testdir/ bekommen wir:

# file: testdir
# owner: root
# group: ntadmin
user::rwx
group::rwx #effective:r--
group:users:r-x #effective:r--
group:Gruppe1:rwx #effective:r--
mask::r--
other::---
default:user::rwx
default:group::rwx
default:group:users:r-x
default:group:Gruppe1:rwx
default:mask::rwx
default:other::---


Nur noch der Eigentümer ( hier root ) hat Schreibrecht.
Selbstverständlich ist setfacl mit der Option –R rekursiv anwendbar.

Drei Dinge sind im Zusammenhang mit ACLs noch erwähnenswert:

Zum einen sollte der chmod-Befehl nicht auf solche Dateien angewendet werden. Zum zweiten sollten Verzeichnisse und Dateien immer der Gruppe ntadmin (Domain Admins) mit rwx gehören (default-Wert einstellen!); ein Domain Admin ohne Rechte ist keiner.
Schließlich habe ich die Erfahrung gemacht, dass die Manipulation der ACLs von einem Windowsclient aus Inkonsistenten verursachen kann. Mit

nt acl support = no

in der jeweiligen share entferne ich deshalb grundsätzlich die Registerkarte „Sicherheit“ aus den Dateieigenschaften. Bei sauber angelegten Gruppen und Benutzern ändern sich Zugriffsrechte nur selten.

Für Kritik und Anregungen bin ich gerne zu haben!

Rainer