Domänencontroller: die Gruppenrichtlinie für das Computerkonto wird nicht geladen.

  • Nach dem erstellen der Domäne auf dem NAS und dem darauffolgenden einbinden der Clients ins AD bekomme ich immer folgenden Fehler beim laden der Computerrichtlinie:



    Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\testgmbh.de\sysvol\testgmbh.de\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
    a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
    b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
    c) Der DFS-Client (Distributed File System) wurde deaktiviert.


    Die Benutzerrichtlinien werden problemlos geholt.
    Die Datei "\\testgmbh.de\sysvol\testgmbh.de\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini"
    kann aber vom Win7 SP1 Client geöffnet werden!


    Eine Neuinstallation des NAS / anderer Computername; Domänenname; das neuinstallieren des Clients brachten keine änderungen!
    Die Zeitsyncronisierung (w32tm) funktioniert!
    DNS scheint auch Ok.


    Bin mit meinen Ideen am ende :-/


    Grüsse Torsten


    TS-453Pro FW4.1.4

  • oh -- Dejavu
    wir hatten das gleiche Problem ...


    ich such mal, wie wir das damals gelöst haben ...
    es liegt auf jeden Fall an den Rechten -- soviel kann ich mit Sicherheit sagen ...

  • Hallo Cerberus hast du etwas rausfinden können?
    Ich steh hier auf dem Schlauch!!!
    Das Team von QNAP scheint beim Thema Samba als ADDC wohl mehr Mannstunden in die Werbung gesteckt zu haben als in die Implementation!
    Out of the Box + neu eingerichtet stehen im log.samba + log.smbd etliche Fehler wie bereits hier http://forum.qnapclub.de/viewt…hilit=dom%C3%A4ne#p196248 von dir beschrieben.


    Wie kann das passieren das solch ein Gerät / Firmware überhaupt in den Verkauf gelangt und dann noch als Unternehmenslösung verkauft wird!
    In der QNAP Werbung heißt es:

    Zitat

    IT-Administratoren profitieren von der zentralen Überprüfung von Zugriffsberechtigungen, wodurch sie kostbare Zeit für andere, wichtigere Aufgaben sparen.


    So schön könnte es sein!
    Ich habe mein NAS und den Testclienten bis jetzt ca. 3x neu Aufgesetzt, etliche Stunden mit Fehlersuche verbracht und nix läuft, außer das viel kostbare Zeit verbraten ist.
    Alles frich eingerichtet doch das Ergebniss bleibt: die Gruppenrichtlinie für das Computerkonto wird nicht geladen. Der Support hat auch schon eine Anfrage auf dem Tisch "Ticket ID: MIZ-174-44477" reagiert hat aber bisher keiner!


    Scheinbar wurde das Feature ADDC mit GPO nicht getestet, oder hat irgend jemand den QNAP Domänencontroler ohne Fehler am laufen???

  • HAbe leider noch keine Lösung gefunden. Sollte jamand das QNAP als Domänenkontroller am laufen haben wäre ich für eine Rückmeldung dankbar.
    Sonst werde ich das NAS noch eine weile in der Ecke stellen bis für SAMBA ein Upgrade verfügbar ist!


    Habe gerade gesehen das Synology in DSM5.2 Samba Upgraded to 4.1.18 for issue fixes and stability enhancements. Im QNAP läuft noch die 4.0.25! :(

  • Hi


    Das ist nicht "vergessen" ...
    Das Problem hat damals unser Samba-Spezi gelöst -- und der ist aktuell leider nicht da :(
    Soweit ich mich erinnere lag es an den Rechten des Verzeichnisses / der Policy-Datei
    Aus irgend einem Grund stimmten die Gruppen-Rechte auf das Verzeichnis nämlich nicht
    Ich bin aber dran ....


    Ansich läuft der Domain-Controller ja -- wenn wir auch ein wenig "Hand" angelegt haben ....
    Aber seit Wochen / Monaten nun stabil

  • Ich habe noch mal nachgeforscht ...


    Die "Probleme" kamen bei unserem Fall davon, das die LINUX-Dateirechte in der Struktur

    Code
    /share/CACHEDEV1_DATA/.samba_target/state/sysvol/XXXXXXX/scripts
    /share/CACHEDEV1_DATA/.samba_target/state/sysvol/XXXXXXX/Policies


    nicht korrekt gesetzt wurden. Der Zugriff übers Netzwerk war nicht gestatte.
    Die Rechte-Liste sollte in etwas so aussehen:


    Es sollten bei beiden Verzeichnissen identisch sein. Danach sollte der Zugriff auf die ini-Datei problemlos möglich sein.


    Des weiteren kann es überaus Hilfreich sein, Die Domäne danach vollständig einzurichten. Dafür bieten sich die Remoteserver-Verwaltungstools für Windows 7 mit Service Pack 1 (SP1) (https://www.microsoft.com/de-d…load/details.aspx?id=7887) an. Diese machen die komplette Konfiguration (genau wie im Windows-Server) mit allen Richtlinien zugänglich. Diese einfach auf einem entsprechenden PC installieren und es kann losgehen. Ich habe es anfänglich auch ohne diese Tools erledigen wollen -- das geht aber an unterschiedlichen Stellen "schief" :)


    Ich hoffe, ich konnte helfen:


    Das Problem mit dem USB werde ich mal prüfen (dort hängt eine USB-HDD fürs Backup dran) -- es sollte sich aber einrichten lassen :)

  • :D:D:D:D Danke das war es!!! Die Rechte für SYSVOL im Punkt "Freigabeordner" des QNAP so eingestellt und alles läuft ohne Fehler!


    Habe zunächst versucht die berechtigungen im Windows explorer einzustellen was auch scheinbar erfolgt ist! Zumindest sagt das getfacl sysvol unter Putty aber unter "Freigabeordner" werden die geänderten Berechtigungen nicht angezeigt und sie haben auch nicht gegriffen. Werde mal ACL aktivieren!


    THX für die Hilfe, der Support von QNAP hatte keine Lösung parat :x

  • Hallo zusammen,


    Ok vielleicht bin ich ja echt einfach zu Doof!!!!!


    Habs jetzt 1000mal versucht auf die verschiedensten Arten wie hier erklärt.


    Wir haben folgendes Test-Setup


    1 PDC (schreibbarer DC) testdc02
    1 RODC mit Qnap firmware 4.2.0 (samba4) mit dem Namen srv883601
    Der RODC ist in einer site Namens biberbruggsite1


    Folgendes funktioniert:


    - Passwort-Caching und login selbst wenn der testdc02 offline ist.
    - Zugriff auf die shares



    Zeitweise scheint der Zugriff auszufallen, nach einem killall smbd gehts dann wieder, hierzu auch noch folgende Fehlermeldungen


    Event-log error 1: Extern verlinkte Datei entfernt! Der Grund!

    Code
    The following directory service made a replication request to replicate attributes in filtered set that has been denied by the local directory service. The requesting directory service does not have access to replicate attributes in the filtered set. Requesting directory service:9a88c129-915b-4036-afa2-320d26699b62 (SRV883601.caritas.lab)Directory partition:DC=caritas,DC=lab User Action    If the requesting directory service should get attributes in filtered list, verify that the security descriptor on this directory partition has the correct configuration for the Replication Get Changes In Filtered Set access right.  You may also get this message when the attributes in filtered set are different between source and destination DCs because of recent schema change. This message will cease when the schema is in sync between the destination and source DCs.


    Event-log error 2: Extern verlinkte Datei entfernt! Der Grund!


    Folgendes funktioniert nicht:


    -Zugriff auf die GPO auf den RODC


    ein paar Screenshots im Anhang


    Ich hoffe jemand anders hatte mehr Erfolg!


    Lieber Gruss


    Mike

  • Also, bin nach hartem Kampf selbst auf die Lösung gekommen!
    Es scheint als ob sich Windows nicht damit zufrieden gibt sofern die Berechtigungen direkt den Usern auf das Sysvol mit der NTFS Berechtigung vergeben wird!


    Sofern man eine Gruppe definiert und dieser die Benutzer hinzufügt und dieser dann Zugriff auf das Sysvol gibt so funktioniert es!


    Funktioniert nicht:


    Code
    # file: .# owner: admin# group: administratorsuser::rwxuser:admin:rwxuser:3000009:r-xuser:3000012:rwxuser:CARITAS-LAB\tebe2:r-xuser:3000018:rwxuser:CARITAS-LAB\krbtgt:rwxuser:CARITAS-LAB\krbtgt_23658:rwxuser:CARITAS-LAB\tebe3:r-xgroup::r-xgroup:CARITAS-LAB\Domänencomputer:r-xgroup:CARITAS-LAB\Domänen-Admins:rwxgroup:3000017:r-xgroup:CARITAS-LAB\Domänencontroller:rwxgroup:3000019:rwxgroup:3000020:rwxgroup:3000022:r-xmask::rwxother::r-xdefault:user::rwxdefault:user:admin:rwxdefault:user:3000009:r-xdefault:user:3000012:rwxdefault:user:CARITAS-LAB\tebe2:r-xdefault:user:3000018:rwxdefault:user:CARITAS-LAB\krbtgt:rwxdefault:user:CARITAS-LAB\krbtgt_23658:rwxdefault:user:CARITAS-LAB\tebe3:r-xdefault:group::r-xdefault:group:CARITAS-LAB\Domänencomputer:r-xdefault:group:CARITAS-LAB\Domänen-Admins:rwxdefault:group:3000017:r-xdefault:group:CARITAS-LAB\Domänencontroller:rwxdefault:group:3000019:rwxdefault:group:3000020:rwxdefault:group:3000022:r-xdefault:mask::rwxdefault:other::r-x


    Funktioniert:

  • Es kommt noch dazu, beim rodc setup mit GPO muss wohl ein samba-tool preload clientpcname$ --server=testdc02.xyz durchgeführt werden ansonsten schlägt die Verbindung ebenfalls fehl!


    Gruss


    Mike

  • Gleiches Problem (Firmwareversion:4.2 und 4.2.1) - Beim Versuch die Gruppenrichtlinien zu updaten per "gpupdate.exe /force" kommt folgender Fehler (z.T. nur für das Computerkonto, z.T. nur für das Benutzerkonto, meistens für beides): :x


    >>Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\net.local\sysvol\net.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich.<<


    Das Problem sind die von QNAP falsch gesetzten Rechte für "netlog" und "sysvol" in der Grundkonfiguration. :cursing:
    Diese lassen sich aber recht einfach und schnell folgendermaßen richtig setzen:



    :arrow: Rechte für "netlog" und "sysvol" werden gleich gesetzt.


    Jetzt unter Erweiterte Berechtigung beide Punkte aktivieren und übernehmen. :!:


    :arrow: Danach gleich wieder beide Punkte deaktivieren und damit stimmen dann die Berechtigungen.



    Jetzt werden die GPOs ohne Probleme aktualisiert:



    :!: Der Benutzer "Administrator" ist unter Windows 7 eigentlich deaktiviert und funktioniert so einfach nicht mit GPOs.


    :?: Ein echter Bug in der QNAP-Firmware ist die Domain-User zu Domain-Gruppen-Zuordnung, denn diese ist funktioniert schlicht nicht. Also wenn man für einen User die Zuordnung öffnet, welchen Gruppen er zugeordnet werden soll (auch beim Anlegen eines Users), dann werden einige Gruppen einfach nicht übernommen oder z.B. beim Administrator sogar auch gelöscht. :shock:
    Abhilfe gibt es über die Domain-Gruppen selber: Die Zuordnung dort in der einzelnen Gruppe, wenn man dort Benutzer als Mitglieder der Gruppe markiert, wird übernommen... :thumb:

  • Bei mir sieht das Problem von der Client (Windows 8.1. pro) Seite identisch aus. Eine 'gpt.ini' Datei wird lt. Windows-Log nicht gefunden. Und tatsächlich, auf dem NAS findet sich keine solche Datei. Das Verzeichnis '/share/CACHEDEV1_DATA/.samba_target/state/sysvol/' ist auf meinem NAS komplett leer.


    Der QNAP-Support hat mir mit dem Update auf 4.2.2 versucht zu helfen (es wurde sogar beteuert, dass die Entwicklungsabteilung den Fix in dieser Version bestätigt hat), leider ohne Erfolg. Auf dem NAS befindet sich nach wie vor keine gpt.ini.


    Mein NAS läuft nun schon seit mehreren Wochen nicht mehr wie gewünscht, da die Benutzer nicht mehr an die Freigaben kommen.


    Über jede Art von Hilfe würde ich mich sehr freuen


    Gruß


    R.

  • Das Problem, das die Gruppenrichtlinienberechtigungen falsch gesetzt werden, existiert immer noch.
    gpupdate /force gibt Fehlermeldung


    Der gepostete Fix von cuinthesnow ( weiter oben ) funktioniert ebenfalls noch.


    Getestet unter QTS4.3.3 20170901 auf TS-231P


    Ansonsten läuft das TS-231P mit AD ( trotz Warnmeldung bzgl. 2GB RAM ) und Netzwerkfreigaben hervorragend :D

  • Wenn jemand noch einmal den Fehler hat... da der Fehler noch immer auftaucht bei einer Neuinstallation...

    Bei mir ging es, da ich die ACL aktiviert habe, dass ich einfach auf die Freigabe des DCs bin (\\<qnapname>\) und dort dann in das sysvol Verzeichnis und dort dann Rechtsklick -> Sicherheit -> Erweitert -> Hinzufügen von der Domänen-Gruppe "Domänen-Computer" (Einfach nach "Dom" suchen und er findet es) und denen Leserechte gegeben (Standard-Auswahl die dann nach dem Auswählen der Gruppe aktiv wird) -> Haken bei der Vererbung der Rechte in die Unterordner angehakt und bestätigt. Zack und es geht.

    Vorher hatte ich noch in den Freigabeordnern der QNAP für Sysvol das gleiche gemacht - auch die Domänen Gruppe "Domänen Computers" mit reinem Lesezugriff hinzugefügt. Das alleine half jedoch nicht. Allerdings ist das glaube ich die generelle Freigabe, dass die überhaupt drauf dürfen. (Äquivalent einer Windows Freigabe) auf die Freigabe.

  • Ich hatte gerade auch mit diesem Rechteproblem zu kämpfen. Aber funktioniert.

    Das Hinzufügen von "xx\Domain Controlers" (R/W) und "xx\Domain Computers" (RO) auf der Linux Dateiebene sorgt für das Bereitstellen und Ausliefern der GPOs.


    Ich hatte aber zusätzlich noch ein weiteres Problem. Aus irgendeinem Grund war unter dem Punkt "Freigabeordner" -> "Ordner-Aggregation" der Haken deaktiviert.

    Das sorgt leider dafür, dass in der Qnap "smb.conf"-Datei das Flag: "host msdfs = no" gesetzt wird.


    Damit funktioniert das DFS nicht und der Zugriff auf "\\domäne.local\sysvol\..." klappt nicht.


    Daher sollte dieser Haken dringen gesetzt sein.

    Einmal editiert, zuletzt von golgorod ()

  • das wüsste ich auch gerne. Hat jemand ne Lösung? Über das Control Panel des QNAP hab ich m.E. die Rechte korrekt gesetzt. Ordner-Aggregation ist ebenfalls aktiviert. Trotzdem funktioniert der GPO Zugriff mit beschriebener Fehlermeldung nicht.

  • Da ich ganz aktuell für einen Test eine NAS als BDC in eine Domäne aufgenommen habe, kann ich sagen, dass zum einen, völlig korrekt beschrieben, die Rechte nach der Einrichtung nicht richtig gesetzt sind. Nachdem ich aber den Domänen-Benutzern über die QNAP-Oberfläche Leserechte auf die entsprechenden Verzeichnisse gegeben habe, funktionierte der Zugriff auf die GPO völlig einwandfrei. Zum Test habe ich den PDC abgeschaltet damit die GPO definitiv von der QNAP gelesen werden und das hat funktioniert. Von daher kann ich nicht bestätigen, dass die Rechte zwingend über das CLI gesetzt werden müssen.

    Wichtig: Wenn ihr die Verzeichnisse auf ACL umstellt, dann müsst ihr natürlich ZWINGEND die entsprechenden Rechte nicht mehr über die QNAP-Oberfläche (oder die CLI) setzen sondern unter Windows über die Sicherheitseinstellungen der Verzeichnisse. Das ist aber auch so in den jeweiligen Dokus beschrieben und kein Fehler seitens QNAP/Samba sondern schlicht der Rechteverwaltung von Windows-AD geschuldet. Das grundsätzliche Problem nach der Einrichtung (nicht nur von ACL) ist hierbei die Sysvol-Replication zwischen Windows und Samba - dass es hier Probleme gibt (und wie man die lösen kann) ist in den Wiki-Seiten von Samba beschrieben (und hat in dem Fall wirklich nichts mit QNAP zu tun).


    Nachtrag (weil mir das wirklich wichtig ist):

    Grundsätzlich stellt QNAP (so wie jeder Anbieter) die Windows-Freigaben über Samba zur Verfügung. Bei tiefergehenden Themen ist hier entsprechend dann auch nicht QNAP sondern tatsächlich Samba der richtige Ansatz um seine Probleme zu lösen. Daher kann ich jedem nur ans Herz legen, sich die dortigen Wiki-Seiten (und im Zweifel die Mailingliste) anzusehen - hier wird eigentlich auf so gut wie jedes Problem eingegangen. Gerade auch die Mailinglist ist hilfreich bei Problemen, da hier die Entwickler auf Fragen antworten. Von daher bitte nicht immer gleich auf QNAP schiessen - gerade im Fall von Samba ist der Ansprechpartner tatsächlich jemand anders. Ihr geht ja auch nicht auf M$ los, wenn ihr z.B. ein Problem mit Putty habt...

    Man sollte in dem Zusammenhang nicht vergessen, dass ein AD unterm Strich kein Spielzeug ist. Sich entsprechend Hintergrundwissen dazu anzueignen ist daher auch nicht Aufgabe des Hardwareherstellers sondern des Anwenders/Administrators. Samba ist, anders als die Einrichtung/Konfiguration eines Windows-AD, nunmal kein "Klicki-Bunti" Dialog. Es erfordert Hintergrundwissen und die Bereitschaft, sich entsprechend einzulesen.



    Gruß,


    Lauri

    2 Mal editiert, zuletzt von Laurenzis ()

  • Danke für die schnelle Rückmeldung. Klappt bei mir nach wie vor nicht.

    PDC ist ein QNAP NAS

    BDC ist ein zweites QNAP NAS.

    Die Rechte verwalte ich über QNAP, nicht ACL.

    Auf syslog und netlogon sind (ausschließlich) folgende Rechte gesetzt:

    Domain Users: R/O

    Domain Computer: R/O

    Domain Admins: R/W

    Domain Controllers: R/W

    (wie auf den Bildern früherer Posts)


    Nun melde ich mich über eine virtuelle Windows 10 Maschine mit "<meine domain>\Administrator" (ist Mitglied von Domain Admins) an. Das testweise Anlegen und Löschen von Dateien in den beiden Verzeichnissen funktioniert. Nun rufe die GPO auf. Fehler:

    Code
    "Verarbeitungsfehler beim Sammeln von Daten mit diesem Basisdomänencontroller..."