Directory Server Die Sicherheitsrichtlinie kann nicht propagiert werden.

[aHTo5Dh2LU1e69YcWwZg]

Hallo zusammen,

ich habe 2 NAS mit je einem Domaincontroller auf der VM. Nach einem gpupdate bekam ich die Meldung, dass auf eine Richtlinie im sysvol nicht zugegriffen werden kann und die Richtlinien bis zur Behebung des Fehlers nicht mehr angewendet werden können.

Daraufhin habe ich folgendes Richtlinienereignis im Gruppenrichtlinienmanager gefunden.
Die Sicherheitsrichtlinie kann nicht propagiert werden.
Auf die Vorlage kann nicht zugegriffen werden. Fehlercode = 2.
\\[Domäne]\sysvol\[Domäne]\Policies\{...}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf.
Oder auch Fehlercode = 3
Als Reaktion darauf habe ich so ziemlich alles ausprobiert was im Internet zu finden war. Dateien auf dem sysvol synchronisiert/gelöscht. Die Server mittels Schnappschuss zu (jeweils beide zum gleichen) verschiedenen Zeitpunkten wiederhergestellt, da es in den Protokollen zu den entsprechenden Zeitpunkten keine Fehlermeldungen gab. Backup der Richtlinien in der Gruppenrichtlinienverwaltung wiederhergestellt. Berechtigungen auf dem sysvol überprüft. Einen Server aus dem Verbund degradiert. Egal was ich gemacht hab, sobald die Server wieder online waren (bei gültigem Vertrauensverhältnis) gab es derartige Fehlermeldungen (auch durch/bei unterschiedlichen Clients). Allerdings war es nicht immer die gleiche Richtlinie.

Ich könnte entweder neue Ideen zur Behebung des Problems gebrauchen oder eine Anleitung wie man Benutzer aus den alten Domaincontrollern in eine neu aufgesetzte Domäne migrieren kann.

Besten Dank im Voraus!

Ergänzung: 20 Benutzer die jeweils auf 2 NAS-Geräte verteilt Ihre Benutzerprofile und Dateien gespeichert haben.

 

[maxblank]

Welches Betriebssystem und welche Domänenfunktionsebene läuft auf den VMs?
Welches Gerät ist für DNS zuständig?

 

[Adama]

Anleitung wie man Benutzer aus den alten Domaincontrollern in eine neu aufgesetzte Domäne migrieren kann.

Das ist normalerweise ganz einfach: Du joinst neue DCs und demotest die alten. Das ist die einzige vernünftige Methode...

Edit: Mal schnell gegoogelt, finde ich das:
https://help.univention.com/t/gruppenrichtlinien-werden-nicht-angewendet/7082

 

[maxblank]

Wohin die neuen DCs joinen? In die alte Domäne? Das bringt doch nichts…

Würde in meinen Augen nur bei einer gemeinsamen Vertrauensstellung etwas bringen, macht es aber unnötig komplex in diesem Fall.

 

[Adama]

Sein Problem scheint ja wohl eher mit einer fehlenden GPO zu tun zu haben, siehe meinen Link. Das ist exakt die Fehlermeldung, die er bekommt.

Wenn er eine neue Domäne aufsetzt, dann hat er neue Benutzer und alles, was daraus folgt. Das selbst bei nur 20 Benutzern kein Spaß...

 

[maxblank]

Ich gehe eher von einer nicht sauber laufenden Replication (u.a. von Sysvol) der DCs aus, basierend auf DNS-Fehlern. Allerdings kamen bisher vom TE keine weiteren Einzelheiten.

 

[Adama]

Wenn das DNS falsch konguriert wäre, dann müsste er aber schon länger Probleme haben. Das tritt ja nun eher nicht plötzlich auf.

Aber das ist alles Kaffeesatz-Lesen, solange unser Thread-Starter sich nicht äussert...

 

[maxblank]

Dies kann bei DCs, die aus dem Backup wiederhergestellt werden mussten, sehr schnell auftreten. Kann ich dir aus eigenen Erfahrungen sagen. Mir hat es dieses Jahr zweimal einen redundanten DC wegen Windows Updates zerrissen.

 

[Adama]

DCs aus dem Backup wiederherstellen ist immer ein Risiko. Deswegen ist es ja besser, den beschädigten zu demoten und einen neuen zu joinen, solange man noch einen funktionfähigen in der Domäne hat....

 

[maxblank]

Wenn du aber vom Schema Master die FSMO-Rollen nicht mehr weg bekommst, da er defekt ist...dann wird es mehr als eklig. Denn damit hat sich trotz eines weiteren funktionierenden DC Members das Demoten zuerst mal erledigt.

 

[Adama]

Die Übertragung der FSMO kann man auch auf einem anderen DC erwzingen.

 

[maxblank]

Jepp, und wenn das schiefgeht, war es das mit der Domäne. Aber wir sind da auf einem Stand und es geht etwas an diesem Thema vorbei.

 

[Adama]

Das stimmt wohl, aber irgendwie müssen wir ja die Stille überbrücken...

 

[aHTo5Dh2LU1e69YcWwZg]

Danke für die Anstöße!

@maxblank:
- DSM 7.2.2 bis 7.2.1 je nach Backup
- ab 7.2. ist das Domänenfunktionsebene von Windows Server 2008 R2
- lässt sich ohne DNS-Server nicht auf DSM installieren - also DNS auf der gleichen VM wie Directory Server

- DNS-Fehler hört sich interessant an, zumal einer der DNS-VMs irgendwie immer schon eine Krücke war (2 Monate mit dem Synology-Support, alle Protokolle geschickt, kein Ergebnis).
Daher war auch der Gedanke da, diese VM im nach/bei der Problemlösung auszutauschen. Was wäre dann die vorgeschlagene Vorgehensweise um das Problem zu lösen?

@Adama
Im Verlauf war das auch ein Versuch - beide Server zu einem führeren Zeitpunk wiederherstellen - unjoin - Fehler beheben - neu installierte Instanz verbinden
Hat nicht funktioniert.

Ich hab mir parallel mal eine de-Domain zugelegt die ich potentiell als neue Domäne nutzen möchte und auch schon Skripte zum aktualisiern des Zertifikats getestet.
Irgendwann wollte ich dann mal eine neue Domäne aufsetzten. Das irgendwann könnte dann auch jetzt sein.
Aber ich erinnere mich an das Gefrickel bis ich alle lokalen Benutzer + Daten + Berechtigungen auf die Domänen-Benutzer übertragen hatte.
Das wäre der Punkt an dem ich mich frage, lässt sich das Bisherige noch irgendwie verwerten oder muss ich wieder bei 0 anfangen.

Siehe Oben - es gab mal Probleme mit dem DNS, die mit einem Update dann scheinbar behoben waren. - Der Dienst lief jetzt ca. 4 Jahre,
das erste Jahr war ruckelig, aber dann gabe es nur ab und zu Kleinigkeiten zu lösen die oft durch einen Neustart oder durch Wiederherstellung
eines aktuelle Backups behoben werden konnten.

Ein weiteres Problem ist, dass die Default Grupperichtlinien im Gruppenrichtlinieneditor nicht gelöscht werden können. "Server kann diese Aktion nicht durchführen" oder so ähnlich.
Es sind aber auch die GPOs Default Domain Controllers Policy und Default Domain Policy betroffen.
Auch die Pfadangabe in den Fehlermeldungen wechselt zwischen einelner DC-, Domäne- und Client-Pfad.

Der laufende Stand ist primärer DC läuft, Authentisierung funktioniert, aber Gruppenrichtlinien funktionieren nicht.
Sekundärer Server neu aufgesetzt aber noch nicht mit DC1 verbunden.

 

[Adama]

Ich bin jetzt verwirrt; Betreibst du DCs als VMs oder benutzt du den Directory Server von Synology?

Nach deinem ersten Post hätte ich ersteres vermutet...

But either way... In deiner Domäne scheint ziemlich Wurm drin zu sein...

 

[aHTo5Dh2LU1e69YcWwZg]

Ich nenne die VM mit installiertem Synology Directory Server (und DNS Server) "Domain Controller" - ich dachte so spricht Microsoft von den Servern als unterschiedliche Instanzen, insb. wenn man die Speicherorte des "Central Storage" unterscheidet, z.B. um Berechtigungen und eben Ordner/Gruppenrichtlinien zu vergleichen.

Es sind aktuell auf jeden Fall 2 VMs mit Synology Directory Server 4.15.13-0615, DNS Server 9.16.34-6205 und DSM 7.2.2-72806 Update 2

Was ich auch noch festgestellt habe ist, dass ich den aktuell bemängelten Ordner/Datei (\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf) ab "Microsoft" noch auf keiner Wiederherstellung gefunden habe, d. h. ich habe den Ordner Microsoft noch nirgends gefunden.

Gibt es evtl. eine Möglichkeit die Gruppenrichtlinien von Hand als root über SSH auf der VM zu entfernen oder die Gruppenrichtlinien auf Default zurückzusetzen (natürlich ohne die Benutzer und OAs zu zerstören)?!

 

[Adama]

D.h. du hast den Directory Server nicht direkt auf der Syno installiert, sondern in einem VM DSM?

Der Directory Server ist dann der DC...

Deine Struktur auf sysvol müsste ja in etwa so aussehen:

./service.mydomain.de/Policies/{FBD98A1D-CA96-49CA-BDBB-BBDC858E4179}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf
./service.mydomain.de/Policies/{F75B161A-8223-486E-9E43-DF6A9F751AF6}/Machine/microsoft/windows nt/SecEdit/GptTmpl.inf
./service.mydomain.de/Policies/{28C21AAC-A368-4EF4-A1AA-242A6308A862}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf

D.h. die problematische GPO wird ja durch die ID in den geschweiften Klammern festgelegt. Die Struktur ist eigentlich bei allen GPOs gleich.

Geh doch mal im Group Policy Editor alle GPOs durch, um zu sehen, ob sie sich alle lesen lassen.

 

[aHTo5Dh2LU1e69YcWwZg]

Ja genau, so sieht das aus. Ich kann auf die Richtlinie im Editor (Gruppenrichtlinienverwaltung => Gruppenrichtlinienobjekt bearbeiten) zugreifen und auch auf die Verzeichnisse und Dateien. Es fehlt aber eben besagter Microsoft-Ordner mit Unterstruktur.

Alle Meldungen meckern wegen der gleichen Richtlinie:

In der Richtlinie selbst steht nicht viel drin - ursprünglich wollte ich das Desktop-Verzeichnis in ein Netzlaufwerk legen, war aber störanfällig (wie ja überall zu lesen ist - deshalb steht der Wert in der Richtlinie auf "nicht konfiguriert".

Mittlerweile habe ich die Verknüpfung gelöscht und die Richtlinie deaktiviert und siehe da - keine Fehlermeldung mehr.
Trotzdem stört es mich, dass ich ein dysfunktionales GPO (Default Domain Controllers Policy) habe welches ich nicht löschen oder reparieren kann.

 

[aHTo5Dh2LU1e69YcWwZg]

Hatte noch eine zweite "unberührte" vorinstallierte VM mit anderer Domäne und dort nachgesehen wie die Richtlinie aussieht: in der Richtlinie ist nix drin, nur die Ordner "Machine" und "User".

Hab mir eine Sicherung Richtlinie aus der anderen Domain gemacht und dann eine Sicherung der Fehlerhaften Richtlinie.
Anschließend die backup.xml und die gpreport.xml miteinander verglichen und die Daten die "zuviel" waren rausgelöscht.
Gespeichert und das veränderte Backup der defekten Richtlinie wieder importiert. Daraufhin wurden die Unterordner unterhalb von Machine und User gelöscht.

ABER auch nach "Aktualisieren" zeigt die Gruppenrichtlinienverwaltung immer noch die vormals gesetzte und wieder zurückgenommene Ordnerumleitung an. WARUM?

Richtlinie wieder Verknüpft und aktiviert - viola, der Fehler mit dem Microsoft-Ordner ist wieder da. Wo bleiben die fehlerhaften Informationen hängen? Auf dem Client oder im Gruppenrichtlinienmanager? Oder...?

 

[aHTo5Dh2LU1e69YcWwZg]

dcgpofix.exe wäre vielleicht die Lösung. Aber die gibt es nur auf einem Windows Server - kein separater Download!