"Kein Zugriff" beim anlegen von GPOs

german

#1

Hallo,

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…

Danke!


Zusätzlichen Administrator anlegen
#2

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 ( :slight_smile: ) - 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.

Gruß,
Jens


#3

Hallo Jens,

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…

Danke trotzdem!

Viele Grüße
Andreas


#4

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.


#5

Hallo,

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.

Danke und Gruß
Andreas


#6

Bei mir siehts so aus:

# file: sysvol
# owner: Administrator
# group: Administrators
user::rwx
user:Administrator:rwx
group::rwx
group:Authenticated\040Users:r-x
group:System:rwx
group:Administrators:rwx
group:System\040Operators:r-x
mask::rwx
other::---
default:user::rwx
default:user:Administrator:rwx
default:group::---
default:group:Authenticated\040Users:r-x
default:group:System:rwx
default:group:Administrators:rwx
default:group:System\040Operators:r-x
default:mask::rwx
default:other::---

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?


#7

Hallo,

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

file: sysvol

owner: Administrator

group: Administrators

user::rwx
user:Administrator:rwx
user:5010:r-x
user:5035:rwx
user:3000001:r-x
group::rwx
group:Authenticated\040Users:r-x
group:System:rwx
group:Administrators:rwx
group:3000001:r-x
mask::rwx
other::—
default:user::rwx
default:user:Administrator:rwx
default:user:5010:r-x
default:user:5035:rwx
default:user:3000001:r-x
default:group::—
default:group:Authenticated\040Users:r-x
default:group:System:rwx
default:group:Administrators:rwx
default:group:3000001:r-x
default:mask::rwx
default:other::—[/code]

Auf einem anderen erhalte ich per RSAT diese Fehlermeldung:

Vielelicht könnte Univention einmal mitteilen, welche Rechte per Default verteilt sein sollten?

Danke und Gruß
Andreas


#8

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:

samba-tool ntacl sysvolreset

Viele Grüße,
Tim Petersen


#9

Klasse, danke, damit dürfte mir geholfen sein! :slight_smile:


#10

Hallo zusammen,

danke für den Hinweis mit den samba-tools. Der hat mir heute auch geholfen (Zusätzlichen Administrator anlegen).

Gibt es für den o.g. Fehler (Advanced_EnableSSL3Fallback) auch eine Lösung?

[code][Window Title]
Administrative Vorlagen

[Main Instruction]
Bei der Analyse ist ein Fehler ist aufgetreten.

[Content]
Die in der Eigenschaft “$(string.Advanced_EnableSSL3Fallback)” aufgeführte Ressource displayName konnte nicht gefunden werden.

Datei C:\Windows\PolicyDefinitions\inetres.admx, Zeile 795, Spalte 308

[OK][/code]

Danke
Ulf


#11

[quote=“ulf.kosack”]Hallo zusammen,

danke für den Hinweis mit den samba-tools. Der hat mir heute auch geholfen (Zusätzlichen Administrator anlegen).

Gibt es für den o.g. Fehler (Advanced_EnableSSL3Fallback) auch eine Lösung?

[code][Window Title]
Administrative Vorlagen

[Main Instruction]
Bei der Analyse ist ein Fehler ist aufgetreten.

[Content]
Die in der Eigenschaft “$(string.Advanced_EnableSSL3Fallback)” aufgeführte Ressource displayName konnte nicht gefunden werden.

Datei C:\Windows\PolicyDefinitions\inetres.admx, Zeile 795, Spalte 308

[OK][/code]

Danke
Ulf[/quote]

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.

MBG,
TP


#12

Hallo TP,

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?

Danke
Ulf



#13

Hallo,

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.

MBG
TP


#14

Hallo TP,

der Fehler passiert nachdem RSOP auf dem Win7 Client durchgelaufen ist und den lokalen Ergebnis-Richtlinien-Satz anzeigt. Beim Bearbeiten habe ich keine Fehler.

Danke
Ulf


#15

Aha! Bearbeitet werden sie aber auf dem 2012R2 Server?


#16

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.


#17

Hallo,

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.

MBG,
TP


#18

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


#19

[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!


#20

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.