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.

Vielmehr wende ich mich gerade wieder verstärkt dem Know-How meines ewigen Steckenpferdes rund um den PC und verstärkt Linux und verwandten Techniken zu.
Was sind “verwandte Linuxtechniken”? Ich würde, nach jüngsten Erfahrungen, sagen: Alles, was zukunftsweisend  und in irgendeiner Weise kreativ ist und mit IT zu tun hat ist heutzutage eine verwandte Linuxtechnik.

Ich möchte an dieser Stelle gerne zwei Beispiele aus meiner aktuellen Arbeitswoche heranziehen:

1) PHP

Wie alt ist PHP inzwischen? Ich meine nicht so direkt die Sprache, sondern vielmehr: Wie lange ist PHP denn inzwischen bitte die Programmiersprache im Internet und der modernen IT? Ich komme zwar noch aus der “Windows for Workgroups” – Ära, aber selbst mir fällt es schwer, mich heute noch an eine Zeit ohne dynamische Webseiten, wo man schlichtweg der King war, wenn man ein DataBecker HTML4 Buch grob angelesen hatte, zurück zu erinnern. Inzwischen wird wohl keiner, der sich ernsthaft mit Webseiten und Trends im Web auseinander setzt bestreiten, das ohne PHP und die unaufhaltsame Verbreitung von OpenSource-Giganten wie Apache HTTPd und Linux das Web heute ein anderes (und ich behaupte: Schlechteres!) Web wäre. Schaut Euch nur mal die Alternativen an: ISS, Windows Server, Microsoft Silverlight, … wer will denn auch nur eines davon haben bitte?? Das finden ausschließlich solche Idioten gut, die kognitiv nicht in der Lage sind Lizenzbedingungen zu lesen und zu verstehen. Da fallen “Argumente” wie

“das kostet doch sooo viel Geld, da wollen Sie mir doch wohl nicht erzählen, das diese kostenlose Freeware legal dasselbe leistet!?“

Ich werde das nie vergessen: Dieser Satz fiel in meiner Berufsausbildung wirklich! Und zwar von meinem damaligen, technischen Ausbildungsbetreuer bei Computacenter. “Freeware”. Das muss man sich mal vorstellen … OpenSource und GPL – völlige Fremdworte.
Ich fürchte diese geistige Haltung ist nach wie vor weit verbreitet – zum Glück sterben diese Idioten aber immer mehr aus. Das ganze kann, in meinen Augen, garnicht schnell genug gehen.

Wie auch immer: Ich wollte heute für ein Plugin für Eclipse auf einer Windowsmaschine PHP 5.3.x installieren. Fertig – das ist die vollständige Anforderung! Zunächst einmal muss man dabei, meiner Meinung nach, den simplen Weg dahin nachvollziehen. Ich lade ausdrücklich jeden Leser ein, den folgenden Weg nachzuvollziehen: Ladet Euch alleine mal ein PHP 5.3 für Windows herunter.
Man geht zunächst auf die Homepage von PHP unter www.php.net . Hier findet man sofort den Link “download” oben auf der Homepage. Dann kann man sich primär PHP 5.3 oder die ältere, abgekündigte Version 5.2 herunterladen. Die primäre Wahl stellt sich hier in einem GZip oder BZip2 Archiv dar – ohne Diskussion: Sourcecode geht hier ab! … als dritte Option wird nun auch noch eine fast abseits stehende Option angeboten: ”For the Windows binaries and installer, see http://windows.php.net/download/.“. Wirkt ein wenig wie “Ach ja, wir haben da auch noch ein behindertes Kind …” im Kinderheim.
Aber – wenn der ganze Kram, egal wie uninovativ diese statisch gelinkte Binär-Scheisse auch sein mag, dann wenigstens funktionieren würde. TUT ES ABER NICHT!!! Macht Euch mal den Spass: Ladet den PHP Installer für Windows herunter, startet nur die php.exe – was passiert? Der Mist stürzt ab, weil ihm DLL Dateien fehlen! Man darf nun wiederum hoffend, das diese Projekte DLLs anbieten, diese ganzen Abhängigkeiten erstmal erfüllen, bis mein eine lauffähige PHP Installation zu Wege bringt.

Mal ehrlich: Fühlt sich das an wie das Jahr 2011? DIE Top-Webtechnik, nicht nativ verfügbar. Wie kann jemand, der ernstzunehmend PHP entwickelt, heute zutage noch Windows einsetzen?
Es gibt, als PHP Entwickler-Workstation, heutzutage kein einziges Argument mehr für Windows!!!!!!! Beweißt mir gerne das Gegenteil!

2) Samba

Warum gibt es Samba? Nur, weil diese ganzen alteingesessenen (böse Zungen würden sagen: festgefahrenen) Anwender weiterhin auf ihrem “Ich bin zwar zu faul mich in etwas anderes als Windows einzuarbeiten und selbst da zu blöd für Admin-Rechte, will aber trotzdem auf alles und jeden Zugriff haben” – Standpunkten bestehen! 90% meines aktuellen Rechte-Chaos-Alltages gehen aktuell dafür drauf, Probleme zu beheben, die es nicht geben würde, wenn Microsoft langsam mal im Jahre 2011 ankommen und sich dem Markttrend gemäß entwickeln würde! Die Jungs kriegen es sogar hin, mit Ihrem Officepaket Dateien über Samba Rechte zu verpassen, die eigentlich unmöglich sind. Stichwort: “Ich möchte gerne, das ich auf die Datei, die ich gerade abspeichere, weder Lese- noch Schreibrechte habe“.

Ich migriere gerade den aktuellen Samba-PDC in unserer Firma von Version 2.5.x auf 3.5.8 . Die Userdaten migrieren: Kein Problem! Reines Datei-kopieren. Was passiert aber, sobald sich ein User unter einem Windows ab Vista (getestet: Windows Vista, 7, Server 2008 R2) anmeldet? Sofortige Wiederabmeldung, ohne Fehlermeldung. Super!!

Ich sage Euch: Wenn Spiele und Branchenriesen wie Adobe Photoshop / Dreamweaver sauber unter Linux laufen würden, hätte ich diesen Krampf schon vor Jahren auch privat von meiner Hardware verbannt

Wir hatten hier in meiner Firma das Problem, das man sich an Windows XP Workstations anmelden konnte und problemlos auf eine von einem Linux Samba Server bereitgestellte Ressource zugreifen konnte, jedoch als derselbe User, der an einer Windows Vista Workstation angemeldet ist, auf dieselbe Ressource keinen Zugriff bekam.

Ich habe zunächst vermutet, das ich einen Fehler in meiner PDC Konfiguration hatte oder ähnliches, da der Domänencontroller und die Bindung der Samba Dateiserver an diesen erst recht neu implementiert wurde. Jedoch liegt es an einem neuen “Feature” von Windows Vista das diese Zugriffe überhaupt nicht klappen können.

Nach kurzer Suche bin ich auf dieses Blog gestossen, in dem genau dieses Problem beschrieben wurde.

Ich denke ohne diesen Beitrag wäre ich da nie drauf gekommen.

Da ich immer Angst habe, das Beiträge die ich verlinke in naher Zukunft wieder verschwinden, kopiere ich den Inhalt des erwähnten Beitrages in mein eigenes Blog. Ich hoffe Jörn hat nichts dagegen. Ansonsten bitte einfach einen Kommentar schreiben

Vista und Samba Shares

Ich habe mir Vista zum Testen installiert. Da ich ein WL700gE habe nutze ich auch die eingebaute Platte als Netzlaufwerke. In den ersten Wochen ging noch alles gut mit den Netzlaufwerken unter Vista.
Nachdem ich aber eines Tages auf meine Laufwerke zugreifen wollte bekam ich die Abfrage nach einem anderen “richtigen” Passwort, da der alte Nutzer nicht authentifiziert werden konnte. Ich habe nicht lange nachgedacht und schnell mein Username und Passwort eingetippt, und.. nichts. Es funktioniert nicht.

Nach etwas Suchen habe ich dann eine Lösung gefunden.

Vista nutzt eine neuen Version des SMB Protokolls. Soll sicherer sein, einziges Problem war nur, dass Samba dieses nicht unterstützt. Und da mein WL700g auf einem Linux läuft und Samba für die Shares nutzt kann es nicht funktionieren.

Um das Problem zu beheben muss man die Lokalen Sicherheitsrichtlinien bearbeiten. Erstmal den Richtlinieneditor über

Start -> Eingabeleiste -> secpol.msc

starten und dann folgenden Pfad hinunter hangeln.

Lokale Richtlinien -> Sicherheitsoptionen

Dort findet ihr dann auf der rechten Seite einen Punkt der
Netzwerksicherheit: LAN-Manager-Authentifizierungsebene
heißt. Dort ein Doppelklick und die Option

LM-und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden)

auswählen. Dann nur noch auf Ok klicken und den Editor wieder schließen.
Nun sollte es wieder möglich sein Samba Shares zu öffnen und zu verbinden. Falls nicht sollte noch ein Neustart gemacht werden. Bei mir hat es zwar ohne funktioniert, aber bei Windows kann man ja nie wissen.

Ob das jetzt ein Versuch von Microsoft sein soll Linux als Fileserver Betriebssystem auszustechen ist fraglich, da es zu einfach zu umgehen ist.
Grüße Jörn

Kleine Ergänzung noch von mir selbst:

Bei  Vista Home Basic und Vista Home Premium soll es anders sein. Da sind stattdessen folgende Schritte notwendig:

• In der Registry den Schlüssel “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr ol\Lsa” suchen
• Den Wert für LmCompatibilityLevel von “3″ auf “1″ ändern

Dieses kann ich nur leider nicht nachstellen, da wir diese Versionen in der Firma nicht haben.

Ich hatte wie der Autor des Blogeintrages, durch welchen ich letztendlich mal wieder fündig wurde, das Problem das ich das Programm convmv kannte, damit auch schonmal gearbeitet hatte, ich mir den Namen jedoch nicht wirklich gut einprägen konnte.

Unter openSuSe 10.3 heisst das RPM auch einfach convmv.

Um nun Dateien eines Samba – Shares gescheit umzubenennen, gibt man convmv folgende Parameter mit:

convmv -f cp850 -t utf-8 --notest -r ordner

Mit -f wird der aktuelle Zeichensatz angegeben.

-t definiert den Ziel-Zeichensatz.

-r führt das ganze Programm rekursiv auf das ganze Verzeichniss aus und

--notest sorgt dafür, das die Dateien effektiv umbenannt werden.

Achtung:

Wer sich über das Ergebniss nicht ganz sicher ist, der sollte die Option --notest zunächst mal weglassen. Dann Zeigt das Programm nur an was es tun würde.

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