Windows XP, Vista und 7 Profile kopieren

... ich kann es zwar selbst nicht wirklich glauben, aber ich werde nun tatsächlich einen Artikel über Windows und das kopieren / übertragen von dessen Profilen schreiben! Ich hoffe der Internet Explorer klettert in meinen Zugriffsstatistiken trotzdem nicht auf Platz 1 ;D

Dieser Artikel entstand, weil ich auf der Arbeit gerade einen neuen PDC implementiere und hierfür selber eine Lösung gesucht habe, wie ich die bestehenden Profile (lokal und Domänen-Roaming-Profile) dabei möglichst nahtlos in die neue Domäne übernehmen kann. Besonders tricky hierbei war, das die aktuelle Domäne nicht wirklich fehlerfrei funktioniert und nun ein Wildwuchs aus lokalen Profilen (da nicht jede Anmeldung an der Domäne funktionierte) und Domänenprofilen besteht und wir nun von Roaming Profiles auf lokale Profile wechseln.
... mal ehrlich: Hat _irgendjemand_ schonmal Roaming Profiles benutzt ohne entweder dazu überzugehen den PC nicht mehr abzuschalten oder(/und?) Dateien nur noch ausserhalb der eigentlich zum speichern vorgesehenen Ordner abzulegen? Wenn ja: Ich hoffe er kriegt seine Medizin ;D

Ich habe nun für alle drei aktuellen Windowsversionen (XP, Vista und 7 - Wer noch <=2000 im Unternehmensumfeld einsetzt bekommt hoffentlich psychologische Hilfe und vorallem Prügel ;D ... "Das ist das stabilste Betriebssystem überhaupt - seit 5 Jahren habe ich keine Sicherheitsupdates mehr einspielen müssen!" ... ihr armen, armen irren Kacknoob-Möchtegern-Admins ... ) einen mehr oder weniger einheitlichen Weg gefunden dieses zu realisieren! Vieles basiert auf dieser (englischsprachigen) Anleitung, jedoch bevorzuge ich für meine Zwecke eher eine hybride Variante aus dieser und einer zweiten Methode.
Keine Sorge, das hier wird eine Schritt-für-Schritt - Anleitung und keiner muss sich diese beiden Englischen Artikel durchlesen. Ich erwähne diese hier nur, damit ich mich nicht mit fremden Federn schmücke.

Am Ende dieses Artikels findet Ihr eine chronologische Screenshotreihe, welche diese Anleitung verdeutlichen soll.

Ich gehe im folgenden davon aus, das ein Profil aus einer alten Domäne (MFC2) für einen identischen Account (mr) in einer neuen Domäne (MFC3) bereitgestellt werden soll. Die Screenshots stammen, sofern nicht anders erwähnt, von einem Windows XP. Die Dialoge und die Vorgehensweise ist in den unterschiedlichen Windowsversionen jedoch nahezu identisch. Daher beschreibe ich auch zunächst einmal das grundsätzliche Vorgehen und erwähne hinterher, welcher Punkt unter Vista/7 einer kleine Abweichung bedarf.
Damit man diesem Guide gut folgen kann, sollte man sich die alte und die neue SID des zu migrierenden Accounts notieren, ehe man anfängt. Passiert das ganze von einem Samba-Server auf einen Samba-Server, ist es einfach: Einfach auf beiden DC folgenden Befehl ausführen:

pdbedit -Lv mr | egrep '\^User SID'

Diese Zeichenketten notiert man sich nun und nicht vergessen zu vermerken, welche die alte und welche die neue ist.

Ich gehe davon aus, das der User, dessen Profil migriert werden soll, sich bereits früher am System angemeldet hat und das gecachedte Profil sich somit bereits auf der lokalen Festplatte befindet. Sollte dem nicht so sein, weil der PC z.B. gleich mit erneuert werden soll, oder weil man diesen Guide erstmal "durchspielen" will, sollte man dieses also zunächst tun, damit das Profil auf das System kopiert wird.

Die folgenden Schritte führt man am besten als ein Domänenadmin aus - Mit dem lokalen Admin geht es nicht, da dann die Domänen-SID-Username Mappings nicht zur Verfügung stehen.

NACHTRAG 02.11.2011: Es ist hierbei sehr wichtig, das der folgende Schritt nicht mit dem User gemacht wird, dessen Profil kopiert werden soll! Benutzt hierfür einen anderen; der User, dessen Profil kopiert werden soll, darf währenddessen nicht eingelogged sein.

Zunächst muss das bisherige Profil des Users kopiert werden.
Unter Windows XP navigiert man dazu nach : Systemsteuerung -> System -> Tab: Erweitert -> Benutzerprofile: Einstellungen.
Unter Windows Vista und 7 navigiert man dazu nach : Systemsteuerung -> Benutzerkonten -> Erweiterte Benutzerprofileinstellungen konfigurieren.

Es öffnet sich jeweils ein Fenster namens "Benutzerprofile" mit einer Liste der bestehenden Userprofile. Man wählt hier nun das zu kopierende Profil aus; im Beispiel: MFC2\mr.
... nun würde man gerne auf "Kopieren nach" klicken, richtig? Aber ratet mal: Dieser Weg war Microsoft zu einfach. Also hat man es einfach kurzerhand deaktiviert und verweist stattdessen auf den KB 973289. Damit nicht genug die Funktion zu deaktivieren: Diese Sadisten grauen den nur aus statt zu entfernen, um allen unter die Nase zu reiben "So leicht könnt's sein ...". Aber glücklicherweise kommt uns genau diese Tatsache nun zu gute:

Ich weise an dieser Stelle darauf hin, das mir zwar keine Meldung bekannt ist, das das folgende Verfahren irgendwo einmal zu einem Problem geführt hat. Jedoch handelt es sich nicht um das offizielle Microsoft - Vorgehen und jeder handelt dabei auf eigene Gefahr.
Zunächst läd man das kleine Tool "Windows Enabler" herunter. Es handelt sich dabei um ein kleines Programm, welches nicht installiert werden muss. Dieses tut man schließlich auch. Achtung: Unter Windows 7/Vista bitte unbedingt "Ausführen als Administrator" auswählen. In der Systemleiste neben der Uhr erscheint daraufhin ein kleines, blaues Icon. Klickt man 1x darauf, erscheint "On" darin. Klickt man nun auf die ausgegraute "Kopieren nach" Schaltfläche, wird sie verfügbar -> Verarscht! ;)

Wir klicken nun auf die neu verfügbare "Kopieren nach" - Schaltfläche. In dem sich daraufhin öffnendem Dialog wählen wir als Ziel "Dokumente und Einstellungen\<username>.<neue_domäne>" (im Beispiel: "Dokumente und Einstellungen\mr.MFC3"; unter Vista/7: "Users"- o. "Benutzer"\<username>.<neue_domäne>). Dieser Ordner kann nicht im sich hier öffnendem Dialog angelegt werden, daher dieses bitte zuvor selbst im Explorer tun. Bei großen Profilen kann es sein, das das Fenster eine zeitlang den Eindruck macht es sei abgestürzt; einen Fortschrittsbalken gibt es nicht. Aber das ist glaube ich eine Sache, mit der man in einer eigentlich deaktivierten Funktion ganz gut leben kann ;)

Ist dieses abgeschlossen, bringt man den PC in die neue Domäne und startet neu. Anschließend meldet man sich am besten als Domänenadmin an - Mit dem lokalen Admin geht es nicht, da dann die Domänen-SID-Username Mappings nicht zur Verfügung stehen.
Man klickt den neuen Profilordner nun mit rechts an und wählt "Eigenschaften"; im sich öffnendem Fester wechselt man zum Tab "Sicherheit". Man sieht hier nun mindestens eine SID mit einem weißen Symbol. Diese User entfernt man zunächst, indem man ihn durch einen Klick auswählt und anschließend auf "Entfernen" klickt. Das sind die Useraccounts der alten Domäne, die der neue Domänencontroller natürlich nicht auflösen kann.
Der nächste Schritt besteht nun darin, das man dem neuen User rekursiv Vollzugriff auf diesen Profilordner gewährt. Hierzu klickt man auf "Hinzufügen" und gibt im Feld "Geben Die die zu verwendenden Objektnamen ein" den Usernamen ein (Im Beispiel: mr). Hierbei ist darauf zu achten, das im Feld "Suchpfad" der Name der neuen Domäne angezeigt wird. Nach einem Klick auf "OK" taucht der User in der Rechteliste auf, sofern er in der neuen Domäne gefunden wird.
Man wählt diesen Eintrag nun an und setzt danach im Feld "Berechtigungen für USERNAME" alle Haken auf "Zulassen". Anschließend klickt man auf "Erweitert" und setzt den Haken bei "Berechtigungen für alle untergeordneten Objekte durch die angezeigten Einträge, sofern anwendbar, ersetzen.". Nun bestätigt man alle Dialoge mit "OK". Es kann anschließend zu einer Fehlermeldung kommen, das nicht alles richtig gesetzt werden konnte. Das kann man jedoch in der Regel ignorieren.

Als letzten Schritt muss man eine kleine Anpassung in der Registry vornehmen. Die Datei "NTUSER.dat" im neuen Profil hat nun zwar bereits die passenden Berechtigungen für den neuen User, jedoch hat diese Datei in sich auch nocheinmal eine Berechtigungsstruktur, die wir nun setzen.
Hierzu öffnet man zunächst den Registrierungs-Editor ("regedit" eingeben unter Start->Ausführen) und wählt den Schlüssel "HKEY_LOCAL_MACHINE" durch anklicken aus. Anschließend klickt man auf "Datei" und wählt "Struktur laden ..." aus. Man navigiert nun in den neuen Profilordner. Hierin befindet sich eine Datei namens "NTUSER.dat". Es kann sein, das sie garnicht oder ohne ".dat" angezeigt wird. Das kommt darauf an, ob man in Windows die Anzeige von bekannten Dateiendungen und Systemdateien aktiviert hat, oder nicht. Wie auch immer: Diese Datei muss nun ausgewählt werden. Anschließend wird man aufgefordert, sich einen temporären Namen für diese Struktur auszudenken. Das Originaltutorial empfiehlt hier "chickenfucker" - tatsächlich sind der Phantasie hier jedoch keine Grenzen gesetzt und hat keinerlei Auswirkungen, da es nur temporär benutzt wird ;)
Die geladene Struktur wird nun mit dem soeben vergebenem Namen unter  "HKEY_LOCAL_MACHINE" eingebunden. Man öffnet nun mit einem Rechtsklick auf diesen Namen das Kontextmenü und wählt "Berechtigungen...". Es öffnet sich nun derselbe Dialog wie wir ihn schon vom setzen der Berechtigungen auf den neuen Profilordner her kennen. Man setzt nun einfach dieselben Rechte erneut und entfernt die Alt-Domain SIDs. Auch hier kann man den Hinweis, das einige Teile nicht gesetzt werden konnten, ignorieren.
Achtung! Der folgende Schritt ist sehr wichtig: Ist das ganze durchgelaufen, klickt man erneut auf "Datei" und wählt "Struktur entfernen ...".

Das war's! Meldet sich nun der User an, für den wir auf diesem Wege das Profil vorbereitet haben, sollte er genau dieselben Einstellungen vorfinden, wie er sie auch in der alten Domäne hatte; inklusive Hintergrundbild und sogar Anordnung der Desktop-Symbole ;)
Sollte das nicht der Fall sein, könnte es daran liegen, das Windows einen anderen Ordner für das Profil gewählt hat als wir es gedacht haben. In freier Wildbahn ist mir so z.B. schon "user.domäne.000" begegnet.
In diesem Fall meldet man sich als Admin an (dieses Mal kann es ruhig der lokale Admin sein); es muss aber unbedingt ein anderer User sein als der, dessen Profil man umbiegt! Diesen meldet man vor dem folgendem Schritt ab.
Man startet nun erneut den Registrierungs-Editor ("regedit" eingeben unter Start->Ausführen) und navigiert zur Struktur "HKEY_LOCAL_Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList". Darin befinden sich eine Menge Unterschlüssel, beginnend mit "S-1-5-21-". Diese Namen stehen für SIDs, daher brauchen wir nun die Liste der SIDs vom neuen Domänencontroller, die man zu Beginn dieses Artikels auslesen sollte. Sucht nach dem Schlüssel, der 1:1 identisch mit der SID des Users auf dem Domänencontroller ist und klickt darauf. Darin befindet sich unter anderem ein REG_EXPAND_SZ mit dem Pfad zum zu verwendendem Domänenprofilcache als Wert. Dieser Wert kann einfach auf den richtigen Profilordner geändert werden.
Nach einem Neustart sollte schließlich das richtige Profil geladen werden.

[gallery link="file"]

Teilen per: TwitterEmail


Wie man unter Linux einen Samba Server zum Domänenmitglied macht

Ich habe nun fast einen monat herumprobiert, ehe ich aufgegeben habe und alle Samba Datenbanken wieder gelöscht habe um von vorne anfangen zu können. Was immer ich beim ersten Durchlauf falsch gemacht habe: Nun habe ich diesen Schritt offenbar weggelassen :)

Damit auch andere von meinen Erfahrungen profitieren können, schreibe ich mein Vorgehen hier auf:

Eine kurze Übersicht über die Namen der Rechner und der User vorweg:

  • linhir: Domänenmitgliedsserver, der User die sich verbinden wollen am PDC anfragen soll
  • mrdomtest: User, der auf einefreigegebene Ressource auf linhir zugreifen können soll
  • mordor: Der NetBIOS Name des PDC
  • MFC: Name der Testdomäne

Ich bin dabei nach der offiziellen Dokumentation der Samba Foundation vorgegangen. Jedoch habe ich vorher ein paar weitere Schritte gemacht um sicher zu stellen, das mir kein Fehlerhafter Datenbankeintrag den Erfolg verwehrt:

  1. Samba Server auf dem Mitgliedsserver beendet (Daemons smb, nmb, winbind)
  2. Alle Dateien die dem Schema *.tdb entsprechen im Verzeichnis /etc/samba/ und /var/lib/samba/, sowie in deren Unterverzeichnissen, gelöscht.
  3. Den Useraccount linhir\$ auf dem PDC aus der Unix Benutzerdatenbank (passwd/shadow/group) entfernt (userdel -r linhir\$)
  4. Maschienenaccount von linhir (linhir\$) aus der Samba Nutzerdatenbank des PDCs entfernt (pdbedit -x -u linhir\$)

Nun sollte alles wieder auf Ausgangsposition sein.Hier meine smb.conf des Domänenmitgliedservers linhir:

[global]
workgroup = mfc
security = domain
password server = mordor

netbios name = linhir
server string = MFC Fileserver (%h) running Samba version %v

passdb backend = tdbsam
unix extensions = no
encrypt passwords = yes
wins server = mordor
name resolve order = wins lmhosts host bcast

log file = /server/logs/smb/samba/%m.log

[jukebox]
comment = jukebox
path = /server/data/samba/jukebox
valid users = MFC\mrdomtest
create mask = 0664
directory mask = 0775
browseable = yes
read only = no

So, wenn ich nichts vergessen habe ist das System nun wieder "nackt".

Der Vollständigkeit halber hier auch nochmal meine PDC Konfiguration (mordor)

[global]
workgroup = mfc
netbios name = mordor
server string = MFC PDC (%h) running Samba version %v

logon script = netlogon.cmd
logon path = \\%h\profiles\%U\%a.msprofile
logon home = \\%h\%u
logon drive = Z:
domain logons = Yes
os level = 190
preferred master = Yes
domain master = Yes
local master = Yes
wins support = Yes
passdb backend = tdbsam
unix extensions = no

security = user

encrypt passwords = yes

name resolve order = lmhosts host wins bcast

time server = Yes
log file = /server/logs/smb/samba/%m.log
log level = 1

add user script = /usr/sbin/useradd -c "Samba Useraccount (auto - add user script)" -g samba -s /bin/false "%u"
add machine script = /usr/sbin/useradd -c "Samba Maschinenenaccount (auto - add machine script)" -g machines -s /bin/false "%u"

delete user script = /usr/sbin/userdel "%u"
add group script = /usr/sbin/groupadd "%g"
delete group script = /usr/sbin/groupdel "%g"
add user to group script = /usr/sbin/groupmod -A "%u" "%g"
delete user from group script = /usr/sbin/groupmod -R "%u" "%g"
set primary group script = /usr/sbin/usermod -g "%g" "%u"

[homes]
comment = Home Directory von %u
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes

[netlogon]
path = /server/service/smb/samba/netlogon/
read only = yes
browseable = no

[profiles]
comment = Network Profiles Service
path = /server/data/smb/samba/ntprofile/
read only = no
browseable = no
create mask = 0660
directory mask = 0770

Ab hier folge ich also der o.g. Doku der Samba Foundation.

Wie ihr anhand der "add user|machine script"e sehen könnt, verwende ich die Methode "On-the-Fly Creation of Machine Trust Accounts", wie sie in der Doku genannt wird.

Weiter steht darin in kürze, das man auf dem Domänenmitgliedsserver nur folgende Werte ändern braucht:

security = domain
workgroup = %DOMAINNAME
password server = %PDC_NETBIOS_NAME

Ich setze "password server = mordor", um den Wildcard - zweifel zu beseitigen (Ob der Server das richtig auflösen kann, etc).

Ich starte nun Samba (smb und nmb) auf linhir.

Die *.tdb Datenbankdateien wurden wieder angelegt, was richtig ist.

Die Doku fährt nun wie folgt fort:

net rpc join -S DOMPDC -UAdministrator%password

Auf meine Domäne umgeschlagen entspricht das:

net rpc join -S mordor -U root

Also gebe ich folgendes auf der Shell ein und erhalte folgende Ausgabe:

linhir:/etc/samba # net rpc join -S mordor -U root
Password:
Joined domain MFC.
linhir:/etc/samba #

Hat also alles geklappt.
Der User wurde auf mordor auch gescheit in die passwd, samba Datenbank, usw eingetragen.

Nächstes laut Doku: Samba Daemons neu starten. OK, also auf linhir UND mordor nmb und smb neu starten.

Done :)

Nun folgt auch der Hinweis weswegen ich der Meinung bin ich brauche einen Winbind daemon:

Please refer to Winbind: Use of Domain Accounts, for information on a system to automatically assign UNIX UIDs and GIDs to Windows NT domain users and groups.

Aber OK - bleiben wir zunächst bei der Handarbeit.
Zumal der Punkt "Sharing User ID Mappings between Samba Domain Members" mal wieder nur eine Methode per LDAP berücksichtigt..

Das wär's dann auch. Mehr ist laut diesem hochoffiziellen Guide nicht zu tun.
Ausser dieses hier:

Currently, domain security in Samba does not free you from having to create local UNIX users to represent the users attaching to your server. This means that if domain user DOM\fred attaches to your domain security Samba server, there needs to be a local UNIX user fred to represent that user in the UNIX file system.

Mein Testuser heisst "mrdomtest". Das sich dieser User am PDC authentifizieren kann, teste ich zunächst indem ich einen zur selben Domäne hinzugefügten Windows XP Professional Rechner nehme und mich dort als "mrdomtest" anmelde ... Klappt!

Jetzt ändere ich den Punkt "valid users" des shares "jukebox" auf linhir wie im Howto als Beispiel für fred angegeben: MFC\mrdomtest .

Damit Samba auch auf den gleich heissenden Unix User im Filesystem referieren kann, checke ich ab das es auch diesen gibt, sowie das es keinen solchen in der Samba Datenbank gibt:

linhir:/etc/samba # grep mrdomtest /etc/passwd
mrdomtest:x:9031:100::/home/mrdomtest:/bin/false
linhir:/etc/samba # pdbedit -L
linhir:/etc/samba #

Nun teste ich mich mit dem Windows XP Domänenrechner mit eingeloggedem User mrdomtest auf das Share "jukebox" des Servers "linhir" zu verbinden: Klappt!

Der User "mrdomtest" ist laut Ausgabe des Befehls "pdbedit -L" auf linhir nach wie vor nicht in der Samba Userdatenbank zu finden. Also hat alles funktioniert :)

Ich hoffe dieser Beitrag ist dem einen oder anderem eine kleine Hilfe.

Ich freue mich stets über Feedback :)

Teilen per: TwitterEmail