9
Fileserver Migration von Workgroup in Domäne
Hallo,
ich habe eine Arbeitsgruppe mit ca. 50 Clients und einem Fileserver. Alle Benutzer arbeiten mit dem selben lokalen Benutzer. Dieser hat diverse Berechtigungen auf dem Filserver. Nun möchte ich eine Domäne aufbauen, in der der Fileserver dann zum Memberserver wird. Sämtliche Clients werden auch in die Domäne gehoben. Dann passen aber die Berechtigungen nicht mehr. Ich habe schon gesehen, dass man mit "subinacl" einiges an den ACLs anpassen kann. Ich habe allerdings keine Möglichkeit gefunden, bestehende ACLs sozusagen zu duplizieren und gleichzeitig zu ändern.
Mein Ziel ist es, vorhandene ACLs der Workgroup bestehen zu lassen, und analog zu diesen auch den Domänenaccount mit denselben Berechtigungen hinzuzufügen, damit ich auch eine Koexistenz habe, da nicht alle Clients an einem Tag migriert werden.
Das heißt zum Beispiel:
C:\Testordner -> Ändern-Recht für "Fileserver\Benutzer"
nun soll hinzugefügt werden -> Ändern-Recht für "Domäne\Benutzer".
Wie stelle ich das am geschicktesten an? Danke.
ich habe eine Arbeitsgruppe mit ca. 50 Clients und einem Fileserver. Alle Benutzer arbeiten mit dem selben lokalen Benutzer. Dieser hat diverse Berechtigungen auf dem Filserver. Nun möchte ich eine Domäne aufbauen, in der der Fileserver dann zum Memberserver wird. Sämtliche Clients werden auch in die Domäne gehoben. Dann passen aber die Berechtigungen nicht mehr. Ich habe schon gesehen, dass man mit "subinacl" einiges an den ACLs anpassen kann. Ich habe allerdings keine Möglichkeit gefunden, bestehende ACLs sozusagen zu duplizieren und gleichzeitig zu ändern.
Mein Ziel ist es, vorhandene ACLs der Workgroup bestehen zu lassen, und analog zu diesen auch den Domänenaccount mit denselben Berechtigungen hinzuzufügen, damit ich auch eine Koexistenz habe, da nicht alle Clients an einem Tag migriert werden.
Das heißt zum Beispiel:
C:\Testordner -> Ändern-Recht für "Fileserver\Benutzer"
nun soll hinzugefügt werden -> Ändern-Recht für "Domäne\Benutzer".
Wie stelle ich das am geschicktesten an? Danke.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 254358
Url: https://administrator.de/contentid/254358
Printed on: April 18, 2024 at 19:04 o'clock
9 Comments
Latest comment
Hi,
wenn der Fileserver z.Z. DER Server ist und Du noch keine Domäne hast, also bei Null anfängst, dann könntest Du den FS zum ersten Domaincontroller der neuen Domäne (und Gesamtstruktur) machen. Später dann einen weiteren Server zum DC promoten (der Domäne hinzufügen) und den FS wieder demoten.
Dabei würde die lokale Sicherheitsdatenbank des FS zu der der Domäne werden. Die Domäne bekommt die SID des FS und die Konten des FS sollten anschließend 1:1 in der Domäne existieren, mit denselben SID.
Damit würden schon mal die Berechtigungen des Fileserver für das (jetzt) Domänen-Konto erhalten bleiben. Die Benutzer müssten sich dann lokal mit dem Domänen-Konto anmelden (nicht mehr mit dem jeweils lokalen Konto).
Mal abgesehen davon ob die Praxis mit dem nur einen Konto bisher gut und/oder sinnvoll war und ob Du das beibehalten willst. Es hat ja offensichtlich für Eure Zwecke funktioniert. Du könntest dann so weitermachen.
Wenn Du dann aber doch auf mehrere Konten umstellen willst, dann kannst Du in der Domäne eine oder mehrere Gruppen erstellen, die Benutzerkonten dort gruppieren und dann mit
subinacl ..... /replace=[DomainName\]OldAccount=[DomainName\]NewGroup .....
die Berechtigungen ersetzen.
E.
wenn der Fileserver z.Z. DER Server ist und Du noch keine Domäne hast, also bei Null anfängst, dann könntest Du den FS zum ersten Domaincontroller der neuen Domäne (und Gesamtstruktur) machen. Später dann einen weiteren Server zum DC promoten (der Domäne hinzufügen) und den FS wieder demoten.
Dabei würde die lokale Sicherheitsdatenbank des FS zu der der Domäne werden. Die Domäne bekommt die SID des FS und die Konten des FS sollten anschließend 1:1 in der Domäne existieren, mit denselben SID.
Damit würden schon mal die Berechtigungen des Fileserver für das (jetzt) Domänen-Konto erhalten bleiben. Die Benutzer müssten sich dann lokal mit dem Domänen-Konto anmelden (nicht mehr mit dem jeweils lokalen Konto).
Mal abgesehen davon ob die Praxis mit dem nur einen Konto bisher gut und/oder sinnvoll war und ob Du das beibehalten willst. Es hat ja offensichtlich für Eure Zwecke funktioniert. Du könntest dann so weitermachen.
Wenn Du dann aber doch auf mehrere Konten umstellen willst, dann kannst Du in der Domäne eine oder mehrere Gruppen erstellen, die Benutzerkonten dort gruppieren und dann mit
subinacl ..... /replace=[DomainName\]OldAccount=[DomainName\]NewGroup .....
die Berechtigungen ersetzen.
E.
Hallo E,
danke für die Antwort. Die Sache mit dem promoten ist natürlich ein echt toller Trick. Aber die Sache hat den Haken, dass beim Heraufstufen zum DC die Workgroup Clients wiederum nicht mehr auf die Freigaben kommen. Und ehrlich gesagt möchte ich lieber "sauber" auf zwei 2012er DCs beginnen.
Bei dem Beispiel mit subinacl hab ich meinem Verständnis nach dasselbe Problem. Die Berechtigungen des lokalen Accounts werden auf den Domänenaccount übertragen. Also können Workgroup Clients wieder nicht zugreifen. Ich dachte, es gäbe irgendeine Möglichkeit nach dem Motto
subinacl /add=Server\user=domain\user
Genau das bräuchte ich
Das mit dem einzelnen Benutzer wird so beibehalten, die Rechner werden für eine Spezialanwendung benötigt, mit dem eigentlichen Betriebssystem wird nicht gearbeitet (Office etc)
danke für die Antwort. Die Sache mit dem promoten ist natürlich ein echt toller Trick. Aber die Sache hat den Haken, dass beim Heraufstufen zum DC die Workgroup Clients wiederum nicht mehr auf die Freigaben kommen. Und ehrlich gesagt möchte ich lieber "sauber" auf zwei 2012er DCs beginnen.
Bei dem Beispiel mit subinacl hab ich meinem Verständnis nach dasselbe Problem. Die Berechtigungen des lokalen Accounts werden auf den Domänenaccount übertragen. Also können Workgroup Clients wieder nicht zugreifen. Ich dachte, es gäbe irgendeine Möglichkeit nach dem Motto
subinacl /add=Server\user=domain\user
Genau das bräuchte ich
Das mit dem einzelnen Benutzer wird so beibehalten, die Rechner werden für eine Spezialanwendung benötigt, mit dem eigentlichen Betriebssystem wird nicht gearbeitet (Office etc)
Hi,
Es geht auch so: Alle Bäume, die vor dem Wald stehen, fällen.
Wenn der FS zum Member wird, dann gehen die lokalen Konten nicht verloren. Auch nicht die NTFS-Berechtigungen dieser Konten. Also könntet Ihr 1:1 weiterhin mit dem bisher genutzten Verfahren arbeiten auch wenn Server und Clients dann in der Domäne sind. Allerdings erschließt sich mir dann nicht ganz der Sinn der Aktion, die Du da vorhast.
E.
Aber die Sache hat den Haken, dass beim Heraufstufen zum DC die Workgroup Clients wiederum nicht mehr auf die Freigaben kommen.
Du hast geschrieben, dass die Clients auch in die Domäne sollen. Dann sind sie keine Workgroup Clients mehr und ich bin davon ausgegangen, dass dann dort mit Domänenkonten gearbeitet werden soll.Und ehrlich gesagt möchte ich lieber "sauber" auf zwei 2012er DCs beginnen.
Was bitte ist da nicht "sauber", wenn man einen vorhandenen Server promotet?Bei dem Beispiel mit subinacl hab ich meinem Verständnis nach dasselbe Problem. Die Berechtigungen des lokalen Accounts
werden auf den Domänenaccount übertragen. Also können Workgroup Clients wieder nicht zugreifen. Ich dachte, es
gäbe irgendeine Möglichkeit nach dem Motto
subinacl /add=Server\user=domain\user
Wenn Du beim Ersetzen eine Gruppe einträgst, dann "addest" Du hinterher zu der Gruppe!werden auf den Domänenaccount übertragen. Also können Workgroup Clients wieder nicht zugreifen. Ich dachte, es
gäbe irgendeine Möglichkeit nach dem Motto
subinacl /add=Server\user=domain\user
Das mit dem einzelnen Benutzer wird so beibehalten, die Rechner werden für eine Spezialanwendung benötigt, mit dem
eigentlichen Betriebssystem wird nicht gearbeitet (Office etc)
Na dann ist das wie von mir beschrieben ein Weg.eigentlichen Betriebssystem wird nicht gearbeitet (Office etc)
Es geht auch so: Alle Bäume, die vor dem Wald stehen, fällen.
Wenn der FS zum Member wird, dann gehen die lokalen Konten nicht verloren. Auch nicht die NTFS-Berechtigungen dieser Konten. Also könntet Ihr 1:1 weiterhin mit dem bisher genutzten Verfahren arbeiten auch wenn Server und Clients dann in der Domäne sind. Allerdings erschließt sich mir dann nicht ganz der Sinn der Aktion, die Du da vorhast.
E.
Hallo E,
ich habe das Ganze mal fix nachgebaut. Du hast Recht. Die Lösung mit dem Promoted des Fileservers wird wohl das beste sein. Ich war der Meinung, dass der lokale Benutzer aus der ACL rausfliegt und nur noch der Domänenbenutzer drin steht. Aber es stehen nach dem Promoten beide drin.
Danke für die Hilfe
ich habe das Ganze mal fix nachgebaut. Du hast Recht. Die Lösung mit dem Promoted des Fileservers wird wohl das beste sein. Ich war der Meinung, dass der lokale Benutzer aus der ACL rausfliegt und nur noch der Domänenbenutzer drin steht. Aber es stehen nach dem Promoten beide drin.
Danke für die Hilfe
Jetzt habe ich gleich das nächste Problem. Die lokalen Profile sollen in der Domäne weiterverwendet werden. Meiner Theorie nach muss man dem Domänenbenutzer Vollzugriff auf das lokale Profil geben und dann den "ProfileImagePath" auf das lokale Profil setzen. Ich habe dazu auch eine wunderschöne Anleitung bei Microsoft gefunden. (http://social.technet.microsoft.com/wiki/contents/articles/24026.step-b ..)
Melde ich mich nun mit dem Domänenebenutzer an, so erhalte ich zwar das alte Profil zurück, allerdings kann ich nicht arbeiten da ich auf "explorer.exe" keinen Zugriff habe. Wenn ich die Berechtigungen über den Admin Account checke, dann dürfen "Rechner\Benutzer" darauf zugreifen. In der Gruppe Benutzer sind Domänenbenutzer. In dieser Gruppe ist auch mein Domänenbenutzer mit dem ich teste.
Irgendwas läuft da schief
Melde ich mich nun mit dem Domänenebenutzer an, so erhalte ich zwar das alte Profil zurück, allerdings kann ich nicht arbeiten da ich auf "explorer.exe" keinen Zugriff habe. Wenn ich die Berechtigungen über den Admin Account checke, dann dürfen "Rechner\Benutzer" darauf zugreifen. In der Gruppe Benutzer sind Domänenbenutzer. In dieser Gruppe ist auch mein Domänenbenutzer mit dem ich teste.
Irgendwas läuft da schief
Welche Komponenten des lokalen Profils sind denn überhaupt interessant? Desktop, Eigene Dateien, Favoriten und sowas? Die üblichen Verdächtigen? Falls es nur das ist, dann kannst Du auch jeweils mit einem neuen Profil anfgangen und nur diese Inhalte wieder bereitstellen.
Die NTUSER.DAT musst Du nur dann übernehmen, wenn Du auch Einstellungen aus der Registry des Benutzers (HKCU) übernehmen willst. Obwohl Du auch das durch Export/Import übernehmen könntest.
Export:
Import
E.
Die NTUSER.DAT musst Du nur dann übernehmen, wenn Du auch Einstellungen aus der Registry des Benutzers (HKCU) übernehmen willst. Obwohl Du auch das durch Export/Import übernehmen könntest.
Export:
reg.exe export HKCU HKCU_Export.regImport
reg import HKCU_Export.regE.
Ich wollte das Profil schon gerne 1:1 übertragen, hätte auch nicht gedacht, dass das so ein Krampf wird. Das mit dem Export/Import der Registry ist auch nicht so leicht, weil mein Domänenbenutzer keine Admin-Rechte hat.
Ich habe jetzt einfach den Windows Easy Transfer Wizard benutzt. Damit funktioniert es wie gewünscht, wenn auch mit diversen Klicks.
Um HKCU zu erxportieren braucht man keine Admin-Rechte.
