ich bin gerade dabei diverse GPOs anzulegen (per RSAT-Tools von Win7 aus) - bis eben ging es auch noch. Ich habe einen Benutzer (Mitgliedschaft in “Domain Admins”) mit dem ich GPOs angelegt habe, zuletzt eine, die einen Registryeintrag setzt. Dann wollte ich die nächste GPO erstellen/anlegen und bekomme nun “aus heiterem Himmel” die Fehlermeldung “Zugriff verweigert”.
Für mich ist das gerade wenig erklärlich - in welcher Log-Datei kann ich nachschauen? Im Windows-Ereignislog ist auf den ersten Blick nichts Erhellendes zu sehen…
Hallo,
Der DC gegen den die GPOs editiert werden wird in der Regel per default per SRV-Record gefunden. Es kann hier also sein, dass gegen den Master verbunden alles läuft und sich dann versucht gegen einen vorhandenen DC Backup zu verbinden der ein Problem hat. Grundsätzlich ist bei Windows AD Problemen immer als Erstes eine asynchrone Uhrzeit zu verschuldigen ( ) - kann das auch hier der Fall sein?
Können Sie Screenshots der Eventlogs senden? Alternativ auf Serverseite am ehesten in die /var/log/samba/log.samba schauen.
vielen Dank für die Denkanstöße. Probleme zwischen Servern können hier ausgeschlossen werden - es gibt nur einen Master.
Und was die Sache für mich ganz unerklärlich macht: es funktioniert wieder. Ich habe keine Aktionen durchgeführt, die ich mit diesem Problem in Verbindung bringen würde - der Benutzer kann jetzt aber wieder GPOs anlegen…
Es wäre auch zu schön gewesen, jetzt geht es (wieder) nicht (mehr).
/var/log/samba/log.samba
[2015/06/09 15:45:35.066628, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_spnupdate: WARNING: No path in service IPC$ - making it unavailable!
[2015/06/09 15:45:35.067148, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_spnupdate: NOTE: Service IPC$ is flagged unavailable.
[2015/06/09 15:45:35.108481, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: WARNING: No path in service IPC$ - making it unavailable!
[2015/06/09 15:45:35.108541, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: NOTE: Service IPC$ is flagged unavailable.
[2015/06/09 15:55:35.195421, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_spnupdate: WARNING: No path in service IPC$ - making it unavailable!
[2015/06/09 15:55:35.195528, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_spnupdate: NOTE: Service IPC$ is flagged unavailable.
[2015/06/09 15:55:35.248881, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: WARNING: No path in service IPC$ - making it unavailable!
[2015/06/09 15:55:35.248965, 0, pid=3563] ../lib/util/util_runcmd.c:324(samba_runcmd_io_handler)
/usr/sbin/samba_dnsupdate: NOTE: Service IPC$ is flagged unavailable.
Das wiederholt sich alle 10 Minuten (glatt).
Ansonsten finde ich da gerade nichts - ich mache mal Screenshots von Windows.
ich habe weitergeforscht. Es gibt im Windows-Log nichts Passendes. Daraufhin habe ich mir mal die Dateirechte angeschaut und Interessantes gefunden.
So sieht es auf dem Server mit Problemen aus (praktischerweise ein Testserver):
Und so auf einem funktionierenden, produktiven System:
Es wäre nun hilfreich zu wissen, ob die Rechte in letzterem Bild “korrekt”, d.h. wie vorgesehen, gesetzt sind - dann würde ich das am Problemgerät entsprechend anpassen und mal weiterschauen.
Ich schätze mal das Problem ist, daß es beim Testsystem keinen Eintrag für die Gruppe Administrators gibt. Stattdessen gibt es ja die Einträge mit 3000*. Ist die Gruppe Administrators auf dem Testsystem vorhanden?
wenn ich per “chown -R :Administrators sysvol” die Gruppe ändere, scheint es zunächst zu funktionieren (so vorsichtig, da ich das noch nicht ausführlich getestet habe).
Ich hatte nun noch ein paar Testsysteme aufgesetzt - auf einem sieht es so aus:
[code]root@dc:/var/lib/samba# ls -al sysvol
insgesamt 20
drwxrwx—+ 3 Administrator Administrators 4096 Jun 15 14:38 .
drwxr-xr-x 11 root root 4096 Jun 17 10:44 …
drwxrwx—+ 4 Administrator Administrators 4096 Jun 15 14:38 test.intranet
root@dc:/var/lib/samba# getfacl sysvol
Das macht Samba intern selbst - die ACL’s von Sirtux sehen z.B. normal aus.
Es gibt Situationen in denen die Posix ID’s während der initialen Einrichtung von Samba noch nicht vollständig auflösbar sind - erfolgt dann die ACL-Vergabe sieht man die ID’s in getfacl (vergleiche auch: [bug]29712[/bug]).
Ein nachträglicher Sysvolreset wird die default ACL’s wiederherstellen:
Hallo,
das schaut für mich zunächst einmal nach einem tatsächlichen Fehler in der besagten ADMX aus. Wurde eine Aktualisierung aus “X:\Windows\PolicyDefinitions” vorgenommen? Manchmal gibt es Probleme mit den zugehörigen ADML, ist auch bei den Chrome ADMX nicht selten.
Eventuell mal die “inetres.admx” in notepad++ anschauen, ob “displayName” tatsächlich korrekt ausgewertet werden kann.
ich weiß nicht, ob ich wirklich verstanden habe, was Du mir versuchst zu erklären. Aber danke für den Versuch.
Hier mal der Auszug aus der admx-Datei, der angemeckert wird (Zeile 795):
<policy name="Advanced_EnableSSL3Fallback" class="Machine" displayName="$(string.Advanced_EnableSSL3Fallback)" explainText="$(string.Advanced_ExplainEnableSSL3Fallback)" presentation="$(presentation.Advanced_EnableSSL3Fallback)" key="Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings">
<parentCategory ref="SecurityFeatures" />
<supportedOn ref="SUPPORTED_IE7" />
<elements>
<!-- This item is a bitmask of protection modes where bits 1-2 are (respectively): Non protected, Protected-->
<enum id="Advanced_EnableSSL3FallbackOptions" valueName="EnableSSL3Fallback" required="false">
<item displayName="$(string.Advanced_FallbackNone)">
<value>
<decimal value="0" />
</value>
</item>
<item displayName="$(string.Advanced_FallbackNonProtected)">
<value>
<decimal value="1" />
</value>
</item>
<item displayName="$(string.Advanced_FallbackAll)">
<value>
<decimal value="3" />
</value>
</item>
</enum>
</elements>
</policy>
Ich habe den in der ersten Zeile des Ausschnitts genannten Registry-Zweig (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings) überprüft und dort gibt es keine Einträge (siehe Screenshot im Anhang). Wenn da keine Einträge sind, kann das ADMX-Template die Werte auch nicht auslesen, richtig?
Ich bekomme diese Meldung auf zwei Win7Pro-VM’s, die in die UCS-Domäne gejoined sind. Der W2k12R2-Server, der ebenfalls UCS-Domänenmitglied ist hat diese Einträge auch nicht und dort gibt es keine Fehlermeldung.
Muss ich diese Einträge jetzt von Hand anlegen? Aber wer will schon noch SSLv3 verwenden?
Was meinst Du mit
Sollte ich die ADMX-Datei aus der Windows-Installations-CD noch einmal kopieren?
beim Parsen der ADMX-Dateien moniert gpmc.msc des Öfteren irgendwelche Fehler. Meist passiert das, wenn man aktualisierte ADMX in sysvol ablegt, dabei alte überschreibt, und alte Verknüpfungen, auch in den dazugehörigen ADML-Sprachdateien nicht aufgelöst werden können.
Es passiert ja relativ häufig, dass man sich aktualisierte Gruppenrichtliniendateien erst vom Client aus z.B. “C:\Windows\PolicyDefinitions” holen muss, da der Server ältere hat, als der Client, oder für bestimmte Zwecke eben gar keine, wie bei Office, Chrome usw.
Das ADMX-Template liest eigentlich nichts aus, sondern schreibt nur in die Registry rein - von wo aus wird denn gpmc.msc gestartet?
Oder hab’ ich das falsch verstanden und der Fehler passiert nicht beim Bearbeiten, sondern beim Anwenden?
Was sagt denn gpresult oder rsop auf den betroffenen Clients?
Manchmal sind Einstellungen aus älteren oder neueren ADMX auch nicht anwendbar und müssen komplett neu aufgebaut werden, da der entsprechende Eintrag fehlt.
der Fehler passiert nachdem RSOP auf dem Win7 Client durchgelaufen ist und den lokalen Ergebnis-Richtlinien-Satz anzeigt. Beim Bearbeiten habe ich keine Fehler.
Ja. UCS ist Domain Master, W2k12R2 Std. ist Domain Member, Bearbeitung der GPO erfolgt per Gruppenrichtlinien-Verwaltung auf dem W2k12R2-Server.
Der Fehler tritt auf den Win7-Member-Workstations auf, wenn ich z.B. per RSOP einen Ergebnissatz mir erstellen lasse, um zu kontrollieren, ob alle Einstellungen korrekt ankommen. Ich hatte anfänglich Probleme mit englischen Gruppennamen auf dem UCS und deutschen Gruppennamen auf den Member-Rechnern.
sorry - ich habe keine Benachrichtigung über neue Posts mehr bekommen.
Ich kenne dieses Verhalten, wenn die ADMX aus verschiedenen Betriebssystemversionen im Central Store liegen. Manchmal werden dort Verweise verwendet, welche entweder inzwischen nicht mehr (veraltete ADMX) oder noch nicht (zu neue ADMX) verwendet werden.
Behoben habe ich dieses Problem immer durch das komplette Löschen der betroffenen Gruppenrichtlinie, das Einspielen der jeweils passenden ADMX sowie Neuerstellen der obigen Gruppenrichtlinie. Dabei bemerkt man oft auch, dass vormals ausgewählte Optionen entweder nicht mehr, oder in anderer Form vorkommen.
Das Verhalten der RSAT von Windows 7 ist normal und tritt auch in reinen Microsoft Umgebungen auf. Sobald einmal mit Server 2012 oder RSAT Windows 8 eine Richtlinie bearbeitet wurde und oder die neuen Vorlagen eingespielt wurden meckert RSAT von Windows 7 oder der Konsole von Server 2008R2 und älter.
Das liegt daran, das ab Server 2012 wieder mal die Richtlinien größer sein dürfen als bei den Vorgängerversionen
[quote=“garfield2008”]Das Verhalten der RSAT von Windows 7 ist normal und tritt auch in reinen Microsoft Umgebungen auf. Sobald einmal mit Server 2012 oder RSAT Windows 8 eine Richtlinie bearbeitet wurde und oder die neuen Vorlagen eingespielt wurden meckert RSAT von Windows 7 oder der Konsole von Server 2008R2 und älter.
Das liegt daran, das ab Server 2012 wieder mal die Richtlinien größer sein dürfen als bei den Vorgängerversionen[/quote]
Danke für die Erhellung - ich hatte es immer auf unterschiedliche Verweise und nicht auf die Größe der Richtlinien zurückgeführt. Tatsächlich hat ja auch z.B. Google mit seinen Vorlagen hier eine recht unrühmliche Bilanz vorzuweisen!
Kleine Konkretisierung. Mit Größe ist die Größe einzelner Felder in der XML der Vorlage gemeint, nicht die Dateigröße. Sobald einmal ein Gruppenrichtlinieneditor mit so einer Vorlage am AD dran war gibt es unter den “alten” Betriebssystemen den Fehler. Aber nicht alle neuen Vorlagen machen von den neuen Feldgrößen Gebrauch.
) - kann das auch hier der Fall sein?
