Samba als PDC konfigurieren - ein Erfahrungsbericht

Hallo.

Ich habe vor ca. 2 Wochen angefangen mein NAS als PDC zu konfigurieren.
Mittlerweile läuft es und ich wollte für alle, die evtl. ähnliche Schwierigkeiten
haben wie ich, hier kurz festhalten wie ich diese gelöst habe.

Kurz zu meiner Umgebung:
Das NAS ist ein TS-259Pro+, derzeit mit FW V3.4.2 build 0331T.
Auf den PCs läuft Win XP Pro.

Angefangen habe ich mit dem Script von Eraser
(siehe: [Howto] Tipps und Tricks zu SAMBA incl. PDC-Erweiterung ).
Es hat mir zu einem schnellen ersten Erfolg verholfen.
An dieser Stelle von mir ein dickes Danke an Eraser für seine Arbeit!

Weitere nützliche Infos:
Samba 3.x als PDC mit ACLs

Ach ja und noch was vorweg:
Auch wenn ich in meinem Bericht ab und an darauf eingehe, dass ich Probleme mit besagtem Script hatte,
will ich damit nicht Eraser irgendwie am Zeug flicken.
Ich will lediglich versuchen anderen, die nach mir kommen und evtl. die selben Probleme haben, zu helfen.

Also los geht's.

Bitte daran denken, die Domäne anders zu benennen als die bisherige Arbeitsgruppe.
Wer das nicht macht, muss mit seltsamen Effekten im Netzwerk rechnen (wer findet
welchen Rechner?).
Der Domänenname steht übrigens in der smb.conf hinter dem Eintrag "workgroup".

Das erste worüber ich gestolpert bin, war der Ort für die Datei "storage.conf".
Das Script erwartet die Datei in /etc/config - bei mir liegt sie aber in /etc.
Leider hat das Script nicht gesagt, dass es die Datei nicht findet.
Ausgewirkt hat sich das so, dass das Script glaubte meine Daten lägen unter
/share/HDA_DATA obwohl meine Daten unter /share/MDO_DATA liegen.

Um das zu umgehen versuchte ich zuerst einen Symlink in /etc/config anzulegen,
der auf die Datei in /etc zeigt, aber mein Qnap hat diesen Link wieder gelöscht.
Ich musste also das Script patchen.
Das sieht bei mir nun so aus:

#STORAGE_CFG_FILE="${CONFIG_FOLDER}/storage.conf"
#
if [ -f "${CONFIG_FOLDER}/storage.conf" ]; then
	STORAGE_CFG_FILE="${CONFIG_FOLDER}/storage.conf"
elif [ -f "/etc/storage.conf" ]; then
	STORAGE_CFG_FILE="/etc/storage.conf"
else
	echo "*** STORAGE_CFG_FILE not found."
	echo "*** Looked in ${CONFIG_FOLDER}/storage.conf."
	echo "*** Looked in /etc/storage.conf."
	exit
fi

Im Hauptmenü gibt es dazu sogar Ausgaben, die aber auskommentiert sind.
Ich habe sie wieder aktiviert um den Pfad jederzeit kontrollieren zu können.

Danach hat das Script die Dateien und Verzeichnisse an der richtigen Stelle angelegt.
Allerdings hat das Script intern das Anlegen von ein paar Domänengruppen auskommentiert,
weil diese auf anderen Qnaps wohl bereits angelegt waren ("ntdomcontrollers", "ntdomcomputer",
"Administrators", "Users").
Ich hatte ein paar seltsame Effekte (an die ich mich allerdings nicht mehr genau erinnere)
die verschwanden, nachdem ich diese Gruppen und die zugehörigen Mappings in dem Script
wieder aktiviert hatte.

So ungefähr zu der Zeit hat das Aufnehmen meines PCs in die Domäne und das einloggen
als Domänenuser funktioniert. Auch das Ausführen von Loginscripten ging.
Das Aufnehmen / bekannt machen des PCs in die Domäne habe ich über das Script erledigt.
Dann den PC über Windows mit Adminrechten an der Domäne anmelden.

Erstes Etappenziel erreicht.

Nun wollte ich die "Roaming Profiles" angehen, denn das war für mich der eigentliche Grund,
warum ich mein NAS als PDC aufbohren wollte.

Hier hat anfangs gar nichts geklappt und ich habe mir letztlich viel von der SAMBA-Doku zu
diesem Thema durchgelesen.

Lange Zeit bekam ich beim Login die Meldung, dass kein Profil auf dem Server zur Verfügung stehe.
Das erste was nicht stimmte war, dass in der smb.conf in der Sektion [global] der Eintrag
"logon path" einen falschen Parameter hatte. Bei mir stand \%N\profiles\%u (nur ein Backslash
am Anfang!).
Der Eintrag muss aber mit 2 Backslashes beginnen: \\%N\profiles\%u
In der Sektion [profiles] war der Eintrag "path" mit der Variablen %a versehen.
Das hat mein NAS irgendwie verwirrt - möglicherweise, weil unter /share ein Symlink
angelegt wird, der auch das %a enthält. Linux kann das %a ja nicht auflösen, das kennt
ja nur Samba.
Also habe ich den Eitrag auf "path = /share/MDO_DATA/Profiles" gesetzt.

Immer noch kein Zugriff.

In der Weboberfläche vom NAS müssen alle (d.h. die Gruppe "everyone") Schreib-Lese-Rechte
auf diese Freigabe erhalten. Dies legt quasi fest, wer denn über diese Freigabe "einsteigen"
darf. Und natürlich muss jeder in der Lage sein auf die Freigabe für die Profile zugreifen
zu dürfen. (Dies taucht in der smb.conf dann in der Sektion [profiles] unter "write list" auf.)
Die Zugriffe auf die einzelnen Profile werden dann als Zugriffsrechte für die einzelnen
Verzeichnisse im Dateisystem gesetzt.
Wer ACLs aktiviert hat, kann es auch über die Weboberfläche machen.

Verzeichnisse für die Profile hat das Script ja angelegt.
Nachdem ich erstmal wirklich allen RW-Rechte gegeben habe, hat der Zugriff auf die Profile
endlich geklappt. Das Einschränken der Rechte war dann einfach...

Die Variable %a habe ich dann in der Sektion [global] bei "logon path" mit angegeben.
"logon path = \\%N\profiles\%a\%u"
Jetzt auch im Dateisystem für %a entsprechende Directories anlegen, das wurde bei mir nicht
von Samba oder von dem Script gemacht - bei mir war das "WinXP".
Dorthin habe ich dann die ganzen (von Erasers Script angelegten) Profilverzeichnisse verschoben.
Daran denken, die Berechtigungen für das Verzeichnis WinXP auch für alle auf R/W zu setzen.

Auf diese Weise habe ich den Vorteil der separaten Profileordner für jedes OS, aber ich
verwirre mein NAS nicht mit dem %a in der Sektion [profiles].

Zweites Etappenziel erreicht.

Wer nun noch darüber nachdenkt, ob er dies auch von Win XP Home aus nutzen kann, sollte mal hier
nachsehen:
http://www.heise.de/artikel-archiv/ct/05/12/148/
http://www.heise.de/artikel-archiv/ct/05/15/050/
http://www.wintotal.de/tipparchiv/?id=1144
(Die ersten beiden sind die kostenpflichtigen Originalartikel, das letzte ist eine
darauf aufbauende Zusammenfassung mit ein paar weiteren Tools)

Letztendlich wollte ich noch von M$ den User Manager (usrmgr.exe) und den Server Manager
(srvmgr.exe) zum Laufen bekommen.
Die Version die man derzeit (Mitte 2011) bei M$ herunterladen kann, lies sich zwar installieren
und auch starten, aber sobald ich irgendwas machen wollte, bekam ich eine Fehlermeldung mit
dem Wortlaut "Ein an das System angeschlossenes Gerät funktioniert nicht."; teilweise gab es
auch Abstürze.

Mittlerweile habe ich herausgefunden, dass es wohl unterschiedliche Versionen dieser Programme
gibt. Vermutlich darin begründet, dass M$ seinen RPC-Mechanismus irgendwann zwischen NT 4 und
Win 7 geändert hat. Die Versionen die man derzeit bei M$ runterläd sind deshalb wohl für Vista
oder Win 7 (habe ich aber nicht ausprobiert).
Was ich ausprobiert habe, sind die Servertools, die damals von M$ mit den NT 4 Installations-CDs
ausgeliefert wurden - und siehe da, die funktionieren wie erwartet (wenn man sie mit ausreichenden
Rechten aufruft; also als Admin bzw. als Domänen-Admin).

Der Nutzen dieser Programme ist aber eh' eingeschränkt, da nicht alle Operationen aus
dem User-Mgr heraus funktionieren (z.B. hinzufügen in Gruppe). Er dient also eher als
Viewer denn als Management-Tool. Beim Server-Mgr sieht es wohl ähnlich aus (nicht getestet).
Dazu fehlen serverseitig vermutlich die notwendigen Scripte.
Die Einträge in der smb.conf dazu lauten
add user script; add group script; delete group script; add user to group script;
delete user from group script; rename user script; set primary group script;
add machine script; addprinter command; deleteprinter command; add port command;
add share command; delete share command; change share command;
Ausprobiert habe ich das allerdings nicht, da ich das was ich brauche gut über
die Web-Oberfläche oder Erasers Script machen kann.
Da meine Umgebung eher statisch ist und nur selten neue Kennungen oder neue Rechner
dazu kommen, war mir das nicht so wichtig.

Die Sektion [homes], die Erasers script angelegt hat, habe ich mittlerweile wieder auskommentiert,
da ich die Homedirectories für die User über den Wizard der Weboberfläche anlegen lasse, wenn ich
einen neuen User anlege.
Einen Automatismus wie mit [homes], der die Homedirectories "on the fly" anlegt finde ich eher
irritierend...

Nun galt es die bestehenden User (= Familienmitglieder) möglichst reibungslos auf den Domänenserver
umzuziehen. Ich versuchte über Systemsteuerung / Verwaltung / Computerverwaltung die Eigenschaften
der lokalen User zu editieren. Auf dem Tab "Profil" trug ich unter "Profilpfad" den Wert
"\\NAS\profiles\WinXP\domusr" ein. Unter "Verbinden von" trug ich "N:" und "\\NAS\domusr" ein.
Damit das ohne Fehlermeldung klappt, muss ich mich als Admin wenigstens einmal auf die Freigabe
"\\NAS\domusr" verbunden haben.
Natürlich waren alle Pfade auf dem NAS mit offenen Berechtigungen angelegt und leer.
Trotzdem wurde beim nächsten Login kein Server-Profil genutzt; aber die Fehlermeldung war eine andere
als ich sie jemals vorher gesehen hatte. Die Freigabe war gefunden worden, aber die Zugriffsrechte
hatten nicht gepasst.
Um dies zu lösen, trägt man in der Sektion [profiles] die Zeile "profile acls = yes" ein.
Nun kann man sich an einem Workgroup-PC mit einem servergestützten Profil anmelden.
Nach dem ersten Logout werden die lokalen Profildaten auf den Server kopiert.

Hinweis am Rande:
Falls jemand nur auf die Roaming Profiles aus ist, müsste ihm das völlig reichen.
Ein voller PDC mit zentraler Nutzerverwaltung ist dafür augenscheinlich nicht nötig.

Nachdem die Profildaten auf dem Server waren habe ich den PC als lokaler Administrator
über Arbeitsplatz / Eigenschaften / Computername / Ändern... in die Domäne gehoben
und neu gebootet.
Beim Einloggen hat er auf das existierende Profil zugegriffen, aber nicht alle Einstellungen
übernommen. vermutlich liegt das an den unterschiedlichen SIDs, die die User haben.
(In dem Profil sind Berechtigungen gesetzt.)

Also Profil auf dem Server wieder gelöscht...

Nächster Versuch:
PC des Users booten.
Als Domänen-User anmelden und ein leeres Profil für den User erzeugen lassen.
Abmelden.
Wer will kann hier zur Sicherheit booten - ich habe es gemacht...
Als Admin (lokaler Admin oder Domänenadmin - ist egal) anmelden.
Arbeitsplatz / Eigenschaften / Erweitert / Benutzerprofile - Einstellungen
Das alte lokale Profil auswählen und Button "Kopieren nach" drücken.
Unter "Kopieren nach" den Prad auswählen, unter dem gerade das leere Profil für den
Domänen-User angelegt wurde. Unter "Benutzer - Ändern" die Kennung des Domänen-User
angeben (zur Sicherheit auf "Namen überprüfen" klicken).
Kopiervorgang mit OK starten und warten. Je nach Größe des Profils kann das dauern.
Komischerweise kopiert das nur einen Teil des Profils - dafür stimmen da aber nun
die Berechtigungen. Als nächstes habe ich den beiden Profilverzeichnissen
Vollzugriff für den jeweis anderen User gegeben. Also dem Profil des lokalen Users
Vollzugriff für den Domänenuser und umgekehrt. Dann mit einem Sync-Tool (ich nahm
den Total Commander, der hat sowas mit an Bord) die fehlenden Dateien kopiert.
Bei zwei Files musste ich trotzdem noch mit Adminrechten nachhelfen - fragt mich nicht warum...

Beim Ausprobieren der Anwendungen war alles ok.
Nur ein paar Kleinigkeiten haben auf den Profilwechsel hingedeutet.
So hat z.B. Outlook nach dem Passwort für den Mail-Account gefragt, und Firefox
wollte wissen, ob er der Standardbrowser sein darf.

Einzig ProjecX hat seine Einstellungen verloren. Warum weiss ich noch nicht.
Vielleicht weil es eine Java-Anwendung ist...

Letztes Etappenziel erreicht.
(Puh!)

Am Ende hatte ich also das Script von Eraser von vorne bis hinten ziemlich gut verstanden
und auch einiges der Samba-Doku gelesen.
Letzteres kann ich übrigens nur jedem empfehlen, der über den Einsatz von
Samba als PDC nachdenkt. Wer das nicht macht, oder die Doku nicht versteht, wird vermutlich immer
wieder Probleme mit seiner Netzwerinstallation bekommen...

hth,
Quacksalber

Hm, kann seltsamerweise meinen eigenen Eintrag nicht mehr editieren...
Dann führe ich halt ein Selbstgespräch und antworte mir selbst.

Der Grund warum ProjectX seine Einstellungen verloren hat war der Folgende:
Als ganz normaler Workgroup-PC zeigen die Evironment-Variaben %HOMEDRIVE%
und %HOMEPATH% nach C:\Dokumente und Einstellungen\...
Mit den Roaming Profiles zeigen die beiden Variablen auf das Netzlaufwerk
auf dem NAS. Das war zu dem Zeitpunkt aber leer.
Offensichtlich gehört ProjectX zu den wenigen Programmen, die diese
Variablen auswerten. Nachdem ich die Konfigfiles von ProjectX dorthin
kopiert hatte, waren die Einstellungen wieder da.

Wer diesen Ansatz weiter verfolgen will, kann sich überlegen, ob er z.B.
den Pfad für "eigene Dateien" mit Tools wie dem MS Powertoys / TweakUI
auf dieses Laufwerk umbiegt. Damit wird ggf. das verbleibende Roaming
Profile deutlich verkleinert, was die Zeit beim an- und abmelden verkürzt.
Außerdem schadet es nicht mal nachzusehen, ob nicht Programme wie bspw.
der "TV-Browser" seine Daten dort ablegt.
Oft kann man diese Verzeichnisse innerhalb der Anwendungen umbiegen.

Trotzdem habe ich mittlerweile den bereits angelegten Domänenuser wieder
deaktiviert und arbeite wieder mit dem lokalen User.

Warum?

Ich habe Samba eigentlich nur wegen der Roaming Profiles als PDC konfiguriert.
Und die Roaming Profiles bekomme ich auch ohne die zentral verwalteten User etc.
mit der Einstellung "profile acls = yes".

Ich will die Roaming Profiles aus 2 Gründen:
1)
Ich will die Daten einfach sichern können. Und alles was auf dem NAS liegt kann
ich sehr einfach in mein nächtliches Backup mit aufnehmen.

2)
Ich will auf dem PC meiner Frau die selben Einstellungen wie auf meinem PC.

Das Migrieren des Profils wie ich es oben beschrieben habe, hat nicht so funktioniert,
wie ich es mir vorgestellt habe. Das lag daran, dass das neue Profil des Domänenusers
einen anderen Namen hatte als das alte des lokalen Users.
Das Profil des lokalen Users lautete "user", das Profil des neuen Domänenusers lautete
"user.DOMAIN".

Mit der von mir beschriebenen Methode kann man zwar alle Anwendungen mit den
bisherigen Einstellungen weiter verwenden, ABER es werden nicht alle Einstellungen
in dem NEUEN Domänenprofil gespeichert. Das liegt daran, dass viele Programme
sich den Pfad merken - und der hatte (zum damaligen Zeitpunkt) als Profilnamen
halt nunmal "user" und nicht "user.DOMAIN".
Deshalb konnte ich diese Daten zwar weiterhin nutzen, ich konnte sie auch verändern,
aber sie waren letztlich nicht Bestandteil des Roaming Profils,
weil sie nach wie vor unter dem Pfad des lokalen Profils gespeichert wurden
und wurden deshalb auch nicht auf das NAS hochgeladen.

Ich habe versucht, die Pfade manuell zu ändern, aber einige Programme haben den
Pfad in Binärfiles gespeichert - da war's nix mit editieren. Mal ganz davon
abgesehen, dass es ein ziemlich zeitaufwendiges Gefrickel ist.

Dann habe ich zu guter letzt das alte lokale Profil gelöscht (umbenannt) und unter
dem Namen des alten Profils einen Hardlink auf das neue Profil des Domänenusers
gesetzt. Nun sollte eigentlich alles funktionieren, dachte ich, da ja auch Zugriffe
auf das vermeintlich alte Profil nun im neuen Domänenprofil landeten.

Leider war dem nicht so. Ich erlebte einige mir überhaupt nicht erklärbare Effekte.
Und das war der Zeitpunkt wo ich beschloss, dass ich mein eigentliches Ziel auch
ohne Domänenuser erreichen kann. Ich muss nur die lokalen User auf jedem PC so
konfigurieren, dass sie alle das selbe servergespeicherte Profil verwenden.

Bei 3-4 PCs mit je 3-4 Kennungen ein überschaubarer Aufwand. Auf jeden Fall weniger
als mich das (erfolglose) Migrieren der Profile jetzt schon gekostet hat...

Mein Fazit:
Wer eine bestehende Installation mit gut funktionierenden Usereinstellungen hat,
wird viel Arbeit in die Migration der Profile stecken müssen. Möglicherweise wird
die Migration mehr Zeit erfordern als das Anlegen eines komplett frischen Profils
mit einer Neukonfiguration.
Wer mit einer frischen Installation anfängt und keine existierenden Profile
migrieren muss / will, bekommt mit dem Samba-PDC eine schöne leichtgewichtige
Lösung für (s)ein kleines Netzwerk.

hth,
Quacksalber

Ein letzter Nachtrag um die Hoffnungen nicht allzuhoch zu hängen...

Mittlerweile habe ich alle meine Rechner von XP auf Win7 umgestellt.
Wobei ich dazu sagen muss, dass ich vorher nur XP Professional im Einsatz
hatte und jetzt habe ich sowohl Win7 Professional als auch Win7 Home Premium
im Einsatz.

Leider musste ich feststellen, dass ich in dieser Konstellation (zumindest unter
Win7) keine echten Roaming Profiles hinbekomme.

Ich kann sehr wohl mit der oben beschriebenen Methode für alle Rechner
die Profile auf dem NAS ablegen - auch für die Home Premium Rechner.
Das hat immerhin den Vorteil, dass ich es einfach sichern kann, und dass
es mir auch nach dem wieder Einspielen eines älteren Plattenimages
noch zu Verfügung steht. Es ist quasi ein Remote Profile.

Ein echtes Roaming Profile in dem Sinne, dass ich auf einem anderen PC
dieses Profil nutzen kann, funktioniert nicht. Das liegt daran, dass Standalone-
User (im Gegensatz zu Domänen-Usern) auf jedem PC eine andere SID (GUID)
bekommen. Diese ist wohl irgendwo in der Registry hinterlegt, und zwar in
dem Teil, der im Profil abgelegt wird. (in der Registry zu finden unter HKCU
bzw. im Users-Ast).

Da diese User-SID auf unterschiedlichen Standalone-PCs (die also keiner Domäne
angehören) unterschiedlich sind, führt jeder Versuch sich mit dem Profil
von einem Fremdrechner anmelden zu wollen zu einer Fehlermeldung,
die einem irgendwas von Gruppenrichtlinien erzählt.

Wenn mann dann in das Eventlog schaut wird man meist Fehlermeldungen
vorfinden, dass der Zugriff auf einen Prad in der Registry nicht funktioniert hat.
Typischerweise wird dieser Pfad eine SID enthalten.

Tja, schade eigentlich...

hth,
Quacksalber