none
DC und AD durch GPO verhunzt - neues AD aufsetzen erforderlich? RRS feed

  • Frage

  • teils unbestätigte Infos vorab:
    - Domäne existiert seit NT4 und wurde im Laufe der Zeit über w2k und w2k3 nun auf w2k8 r2 aufgestuft
    - Default Domain Policy umfasste 200 Seiten, durch eine unbekannte Ursache wurden Ownership und Rechte auf unzählige Systemdateien gesetzt ala c:\windows\system32\mqsvc.exe

    Hallo zusammen.

    ich habe eine recht alte und unübersichtliche Domäne übernehmen 'dürfen'. Ich liste erstmal ein paar der auffälligsten Probleme bevor ich die oben genannte Frage aufgreife:

    • Wenn ich unter der alten Default Domain Policy Windows7 Rechner zur Domäne zufüge, können diese per DHCP keine IP übernehmen. Dies scheint ein Rechteproblem zu sein und führe ich auf den zweiten Punkt aus dem Vorwort - denn nach einiger Recherche brachte mir folgendes Abhilfe: auf dem betroffenen PC "NT-AUTORITÄT\LOKALER DIENST" und "NT-AUTORITÄT\NETZWERKDIENST" der Administratorengruppe zuzufügen. Nach einem Neustart kann der Client die ihm angebotene IP-Konfiguration per DHCP auch tatsächlich nutzen.
    • auf dem DC können diverse Eventlogs nicht genutzt werden (Anschauen, Pfade anpassen, reset, etc.) da der Zugriff verweigert wird. Betroffen sind unter anderem die Logs von: DNS Server, File Replication Service, Microsoft-Windows-DiskDiagnosticDataCollector/Operational.. Entsprechend sind die Einträge wie hier im technet behandelt. Ich werde das Gefühl nicht los, dass hier ebenfalls der zweite Punkt aus dem Vorwort greift, auch wenn das nur ein Bauchgefühl ist und bisher nicht bewiesen werden konnte.
    • Die Builtin Gruppe Remote Desktop Users heißt Remote Desktop Use~0 und verweigert den Mitgliedern leider ihre Funktion des Remote logon. Als Builtin Gruppe ist diese ja nicht änderbar, mögliche Ursachen sind wohl das Aufstufen der Domänenfunktionsebene und/oder das Vorhandensein der Gruppe vor dem dcpromo
    • WMI-Filter sind komplett aus den Gruppenrichtlinien verschwunden, der komplette Absatz dazu fehlt einfach.

    Es gibt weitere Punkte, die mir gerade nicht detailliert genug in den Sinn kommen (Terminalserver-Lizenzserver funktioniert trotz funktionaler Konfiguration und Aktivierung der CALs nicht, unzählige Karteileichen, etc). Unter anderem scheitert das ADMT (migration Tool) wegen mangelnder Rechte..

    Letztlich wäre mir eine Domäne ohne diese Vergangenheit am angenehmsten und damit zu den Fragen:

    • Nachdem die Migration nicht funktioniert: gibt es irgendeine Möglichkeit den neu angelegten Benutzern die Passwörter aus der alten Domäne zuzuweisen? Ich rede natürlich nicht von John etc. ich will die Passwörter ja nicht wissen, aber evtl. gibt es eine Datenbank ala /etc/shadow über die man eine Zuweisung machen könnte? Es handelt sich etwa um 100 Benutzerkonten.
    • Es existiert ein Dateiserver mit ausgiebiger Rechtevergabe. Die Idee bestünde darin sich über icacls ein Script zu schreiben in dem man die alten SID der Benutzer mit den neuen austauscht um den Zugriff auch in der neuen Domäne wieder zu ermöglichen. Machbar? Sinnvoll? Oder gibt es da eine ganz andere Lösung für?

    Danke vorab für Antworten, Anregungen, Anleitungen und dergleichen..



    Dienstag, 24. Juli 2012 06:48

Alle Antworten

  • Am 24.07.2012 08:48, schrieb Jo Ja:
    > *- Default Domain Policy umfasste 200 Seiten, durch eine unbekannte
    > Ursache wurden Ownership und Rechte auf unzählige Systemdateien gesetzt
    > ala c:\windows\system32\mqsvc.exe*
     
    Stressfrei.
     
    a) dcgpofix setzt die DefDomPol und DefDomConPol auf orginal Zustand
    nach Installation zurück. Fertig.
     
    b) Versenkte Dateisystemrechte, naja, du willst ja nicht alle Clients
    neuaufsetzen, oder? Denn die sind ja auch betroffen.
     
    DCs gegen neue austauschen ist ja relativ einfach mit einer
    SwingMigration. Neuen DC hinzufügen -> alten DC demoten  -> alten DC
    neuinstallieren -> "alten" DC wieder promoten -> neuen DC demoten
     
    Es gibt für XP/203, leider nicht in Win7, die defltkwk.inf, bzw.
    defltsv.inf in c:\windows\inf die kannst du einmalig anwenden und dann
    sind die Rechte wieder wie nach der Installation für Dateisystem,
    Registry, Dienste,
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm
     
    • Als Antwort vorgeschlagen Meinolf Weber Dienstag, 24. Juli 2012 07:13
    Dienstag, 24. Juli 2012 07:05
  • Am 24.07.2012 09:05, schrieb Mark Heitbrink [MVP]:
    > Stressfrei.
     
    NEues AD? Da bleibt dir natürlich der Weg über ADMT, aber die Clients
    und Rechte auf den vorhandenen Rechnern sind immer noch im Ar***, die
    Benutzerkonten in ein anderes AD zu überführen rettet dich an keiner
    Stelle. Denn dein Problem ist ja nicht das AD und die Konten, sondern
    dein Problem ist LOKAL an JEDEM PC/Server.
     
    Die korrigieren sich ja nicht, nur weil sie in einem neuen AD stehen.
    Die Rechte snd gesetzt und bleiben. Ergo: Korrektur oder Neuinstallation
    des Ziels (Computer).
     
    Nebensatz: Setacl.exe kann mehr als icacls, falls du den Filer umziehen
    möchtest.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm
     
    • Als Antwort vorgeschlagen Meinolf Weber Dienstag, 24. Juli 2012 07:13
    Dienstag, 24. Juli 2012 07:09
  • Hallo,

    > *- Default Domain Policy umfasste 200 Seiten, durch eine unbekannte
    > Ursache wurden Ownership und Rechte auf unzählige Systemdateien gesetzt
    > ala c:\windows\system32\mqsvc.exe*
     
    Stressfrei.
     
    a) dcgpofix setzt die DefDomPol und DefDomConPol auf orginal Zustand

    nach Installation zurück. Fertig.

     
    b) Versenkte Dateisystemrechte, naja, du willst ja nicht alle Clients
    neuaufsetzen, oder? Denn die sind ja auch betroffen.

    das ist natürlich der größere Dorn im Auge, auch die weiter unten genannte defltwk.inf (iirc: secedit /configure /db Secedit.sdb /cfg C:\windows\inf\defltwk.inf /overwrite) ist ja wie gesagt für Win7 keine Lösung.

    Bleibt mir bei Windows7 nur die Neuinstallation, falls die Clients sich schon die "alte" DefDomPol geholt hatten? Korrektur geht nur für XP/2003?

    DCs gegen neue austauschen ist ja relativ einfach mit einer
    SwingMigration. Neuen DC hinzufügen -> alten DC demoten  -> alten DC
    neuinstallieren -> "alten" DC wieder promoten -> neuen DC demoten

    Das sollte ich wohl so machen. Allerdings ist mir nicht klar, ob ich durch Neuinstallation des DC auch die Problematik mit der Remote Desktop User Gruppe in den Griff bekomme, weswegen es auch Ärger mit den CALs/dem RD Session Host gibt (Gruppe angeblich leer, durch das Use~0 wohl).

    Und dass mir die WMI-Filter in den GPO abhanden gekommen sind, ist ebenso lästig - da sollten welche für die Sprachuntersscheidung im Softwaredeploy genutzt werden. Soweit ich das verstehe, ist das aber ein Problem im AD und nicht an einen DC gebunden? Ansonsten ist das wohl ein eigenes Kapitel für wmidiag.vbs?

    Vielen Dank auf jeden fall schonmal,
    auf weitere Erleuchtungen hoffend

    Schöne Grüße
    Jorma

    Dienstag, 24. Juli 2012 11:47
  • Am 24.07.2012 13:47, schrieb Jo Ja:
    > C:\windows\inf\defltwk.inf /overwrite) ist ja wie gesagt für Win7 keine
    > Lösung.
     
    naja, geben tut es sie schon, die Frage ist eben verbockt das System ist
    und wie gut es damit repariert wird.
    Die Win7 defltwk.inf ist wesentlich kürzer/kleiner in ihrer Definition,
    was aber auch daran liegt, daß nicht mehr JEDER Pfad integriert ist,
    sondern nur die Überordner.
     
    > Das sollte ich wohl so machen. Allerdings ist mir nicht klar, ob ich
    > durch Neuinstallation des DC auch die Problematik mit der Remote Desktop
    > User Gruppe in den Griff bekomme,
     
    Das ist ja nur die Berechtigungen auf dem RDP Protokoll. ICh arbeite nie
    mit der Remote Desktop User group, sondern immer mit einer eigenen
    selbsterstellten.
     
    > Und dass mir die WMI-Filter in den GPO abhanden gekommen sind, ist
    > ebenso lästig - da sollten welche für die Sprachuntersscheidung im
    > Softwaredeploy genutzt werden.
     
    Was hat denn WMI jetzt damit zu tun? WMI Filter neuerstellen ist ja mal
    simpel.
    -> WMICodeCreator
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm
     
    Dienstag, 24. Juli 2012 12:04
  • naja, geben tut es sie schon, die Frage ist eben verbockt das System ist
    und wie gut es damit repariert wird.
    Die Win7 defltwk.inf ist wesentlich kürzer/kleiner in ihrer Definition,
    was aber auch daran liegt, daß nicht mehr JEDER Pfad integriert ist,
    sondern nur die Überordner.


    Leider ist das für diesen Fall nicht ausreichend, die Clients nehmen dennoch keine DHCP-Adresse an, haben trotzdem Probleme mit der geschützten Ansicht aus MS Office Professional Pro 2010, mit der geschützten Ansicht des Adobe Reader.. dann bleibt für die wohl nur die Neuinstallation.

    > Das sollte ich wohl so machen. Allerdings ist mir nicht klar, ob ich
    > durch Neuinstallation des DC auch die Problematik mit der Remote Desktop
    > User Gruppe in den Griff bekomme,
     
    Das ist ja nur die Berechtigungen auf dem RDP Protokoll. ICh arbeite nie
    mit der Remote Desktop User group, sondern immer mit einer eigenen
    selbsterstellten.

    Hier ist eine Gruppe RPD_User erstellt, die wiederum Mitglied der Builtin-Gruppe ist. Zum Testen habe ich ausserdem noch einen Benutzer direkt zugefügt.

    Das Problem ist ja aber nicht (nur) das RDP Protokoll, sondern das Bemängeln des RD Session Host:

    "Issue:
    The Remote Desktop Users group on the Remote Desktop Session Host server does not contain any domain users or groups.

    Impact:
    If the Remote Desktop Users group on the RD Session Host server does not contain domain users or groups, users will not be able to connect to the RD Session Host server.

    Resolution:
    Use the Remote tab in the System Properties dialog box to add domain users or groups to the Remote Desktop Users group on the RD Session Host server."

    Als Folge dessen komme ich auf den DC auch nur per mstsc /admin obwohl mir zeitgleich eben die erfolgreiche Konfiguration und Aktivierung des Lizenzservers angezeigt wird.

    Was hat denn WMI jetzt damit zu tun? WMI Filter neuerstellen ist ja mal
    simpel.
    -> WMICodeCreator

    Das war missverständlich. Mir fehlt nicht ein ersteller Filter, sondern die Möglichkeit WMI-Filter überhaupt zu nutzen. Die zwei Bilder zeigen eine "normale" Domäne, die rot markierten Abschnitte existieren in dieser Domäne einfach nicht.

    -

    Zusammenfassend bleibt folgender Status bzw. Fragen:

    • Win7 Clients müssen neu installiert werden
    • Remote Desktop Services erkennt Benutzer nicht
    • WMI-Filter existieren nicht

    Lässt sich das beheben, überhaupt bzw. mit angemessenem Aufwand, oder wäre das Neuerstellen der Domäne sinnvoller? Damit käme vor allem die Frage, ob und wie man Passwörter der Benutzer erhalten kann.

    Danke abermals, schöne Grüße

    Mittwoch, 25. Juli 2012 12:35
  • Hi,
     
    Am 25.07.2012 14:35, schrieb Jo Ja:
    > [...] dann bleibt für die wohl nur die Neuinstallation.
     
    Sieht so aus.
     
    > Hier ist eine Gruppe RPD_User erstellt, die wiederum Mitglied der
    > Builtin-Gruppe ist.
     
    neneneneeee nicht Mitglied von, sondern einzig und allein.
    Und die darf dann wieder "Anmelden über RDS Dienste". Also rechte am
    Protokoll und "Anmelden über RDP"
     
    > The Remote Desktop Users group on the Remote Desktop Session Host
    > server does not contain any domain users or groups.
     
    Wahrscheinlich gibt es eine GPO, die das mit den "Eingeschränkte
    Gruppen" manipuliert hat. Lösch die Einträge.
     
    > Die zwei Bilder zeigen eine "normale" Domäne, die rot markierten
    > Abschnitte existieren in dieser Domäne einfach nicht.
     
    Mit welcher GPMC schaust du darauf? Das gibt es nicht.
    Es sei denn dir hat jemand im AD auf dem WMI Knoten das LESEN verboten.
     
    > Lässt sich das beheben, überhaupt bzw. mit angemessenem Aufwand, oder
    >  wäre das Neuerstellen der Domäne sinnvoller?
     
    Keine Ahnung.
     
    > Damit käme vor allem die Frage, ob und wie man Passwörter der
    > Benutzer erhalten kann.
     
    Ohne ADMT auf keinen Fall.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm
     
    Mittwoch, 25. Juli 2012 13:40
  • neneneneeee nicht Mitglied von, sondern einzig und allein.
    Und die darf dann wieder "Anmelden über RDS Dienste". Also rechte am
    Protokoll und "Anmelden über RDP"


    Da fehlen mir wohl die detaillierten Kenntnisse, wo finde ich die Möglichkeit diese Optionen zu setzen?

    > The Remote Desktop Users group on the Remote Desktop Session Host
    > server does not contain any domain users or groups.
     
    Wahrscheinlich gibt es eine GPO, die das mit den "Eingeschränkte
    Gruppen" manipuliert hat. Lösch die Einträge.


    Enabled ist dort aktuell eine leere Default Domain GPO, das kann ich also ausschließen. Der Server wird neu installiert, zumindest fallen damit noch die geänderten Dateireche als Ursache weg.

    > Die zwei Bilder zeigen eine "normale" Domäne, die rot markierten
    > Abschnitte existieren in dieser Domäne einfach nicht.
     
    Mit welcher GPMC schaust du darauf? Das gibt es nicht.
    Es sei denn dir hat jemand im AD auf dem WMI Knoten das LESEN verboten.

    Gibt es hier wohl leider schon. Mit welcher GPMC.. also v.6.0.0.1 vom Server 2008 R2. Aber auch von 2003 kommend und egal ob von einem der DC oder von einem anderen Server eingebunden. Und nachdem ja einiges an Zugriffs/Sicherheitsrechten verändert worden war - wo könnte ich das mit dem LESEN auf dem WMI Knoten prüfen? Jeder Ansatz ist mir hier recht ;)

    Schöne Grüße, danke abermals.

    Montag, 6. August 2012 10:51
  • Das Thema wurde ja schon recht weit gebracht, einige Dinge (gerade wegen der WMI Thematik) sind aber noch offen. Ich hatte die Frage nach der Aktualität übersehen, vielleicht kann sich aber doch noch jemand dazu äußern?
    Dienstag, 18. September 2012 08:18