Montag, 30. Januar 2012

The lies of GPOs! #5

#5

"Nur geänderte Gruppenrichtlinien werden erneut angewendet"

Jede Richtlinie speichert die aktuelle Version der Richtlinie an zwei Stellen.
Einmal im Active Directory und einmal in der gpt.ini.


Die gpt.ini liegt im Sysvol des Active Directory unter \\domain.intern\sysvol\domain.intern\Policies\{GUID}.

Es wird sowohl die Version der User- als auch Computerpolicy gespeichert.
Wie der gespeicherte Wert berechnet wird, lässt sich hier nachlesen:

http://blogs.technet.com/b/grouppolicy/archive/2007/12/14/understanding-the-gpo-version-number.aspx

Die allgemein verbreitete Meinung:
Policies werden nur dann erneut angewendet, wenn sich die Versionsnummer ändert.

Testumgebung:

OK, schauen wir uns das in einer Testumgebung einmal an.



In diesem Beispiel wurden drei GPOs angelegt.
In den Richtlinien wurde als Beispiel das Logging für GPOs aktiviert.

Beispiel gpo1:

In gpo2 wurde das Logging für "Datenquellenrichtlinien-Verarbeitung" aktiviert.
In gpo3 wurde das Logging für "Geräterichtlinienverarbeitung" aktiviert.

Wurden die Richtlinien bereits angewandt und wir führen ein "gpupdate" aus,
werden die Richtlinien nicht erneut angewendet.

Dies wird im gpsvc.log vermerkt:
GPSVC(3f0.1850) 12:46:19:400 ProcessGPOs: Processing extension Registrierung
GPSVC(3f0.1850) 12:46:19:400 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3f0.1850) 12:46:19:400 CompareGPOLists:  The lists are the same.
GPSVC(3f0.1850) 12:46:19:400 CheckGPOs:
No GPO changes and no security group membership change and extension Registrierung has NoGPOChanges set.


Änderung an gpo1:

Wenn wir nun also gpo1 ändern, so sollte diese erneut angewendet werden.
Die Richtlinien gpo2 und gpo3 jedoch nicht.

Um es zunächst ohne Logfile zu überprüfen, ändere ich manuell mittels regedit alle Werte ab, die von den Policies gesetzt werden.

Per Policy werden diese Werte gesetzt:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
    LogLevel    REG_DWORD    0x2 von gpo1

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
    LogLevel    REG_DWORD    0x2 von gpo2

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
    LogLevel    REG_DWORD    0x2 von gpo3


Diese Werte ändere ich manuell per regedit auf:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x3

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x3

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3


Wenn nun nur gpo1 erneut angewendet wird, sollte das Ergebnis wie folgt aussehen:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD
0x2 durch die änderte gpo1 gesetzt
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD
0x3 gleichbleibend, da gpo2 nicht verändert wurde
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3 gleichbleibend, da gpo3 nicht verändert wurde


Das Ergebnis ist jedoch:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x2

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x2


D.h. es werden alle Policies erneut angewendet, obwohl nur Policy "gpo1" geändert wurde.

Zu erkennen ist das auch im gpsvc.log:
GPSVC(3b0.444) 15:58:28:765 ProcessGPOs: Processing extension Registrierung
GPSVC(3b0.444) 15:58:28:765 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3b0.444) 15:58:28:765 CompareGPOLists:  Different version numbers found


...

GPSVC(3b0.444) 15:58:28:859 ParseRegistryFile: Entering with <\\domain.intern\sysvol\domain.intern\Policies\{A52DB6EF-C428-4FA6-AC0E-C614891A9CC1}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:859 SetRegistryValue: LogLevel => 2  [OK]
...

<\\domain.intern\sysvol\domain.intern\Policies\{A8CD3DB6-5A58-4437-82EB-DDD14A062AA6}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:875 SetRegistryValue: LogLevel => 2  [OK]
...

<\\domain.intern\SysVol\domain.intern\Policies\{4F685E24-6F86-4088-B45C-E9BA66B06B6C}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:906 SetRegistryValue: LogLevel => 2  [OK]
...


Fazit:

In diesem Beispiel wurden also auch Policies angewandt, deren Versionsnummer sich nicht geändert hat (gpo2 und gpo3).

Das Geheimnis - Ändert sich eine GPO innerhalb einer CSE (Client Side Extension), so werden alle Policies, welche Einstellungen dieser CSE besitzen, erneut angewendet.

Habe ich also zum Beispiel 100 GPOs verlinkt, die Einstellungen innerhalb der "Administrative Vorlagen" beinhalten und ich ändere nur eine GPO von diesen, so werden die "Administrativen Vorlagen" von allen 100 Policies erneut angewendet!

Zusätzlich zu diesem Verhalten, lässt sich pro CSE einstellen, ob Einstellungen auch ohne Änderungen übernommen werden sollen.
Dieses Thema werde ich jedoch erst im nächsten Post behandeln.



Sonntag, 8. Januar 2012

The IP Address is not a valid DNS address ...

Diesmal ein Phänomen aus dem Bereich DHCP/DNS.
Beim Hinzufügen eines DNS Servers in den Bereichsoptionen des DHCP Servers erscheint folgende Fehlermeldung:

"The IP Address x.x.x.x is not a valid DNS address, do you still want to add it ?"





Bei dieser Fehlermeldung kommen einem erst einmal folgende Gedanken in den Sinn:

  • Wurde eine falsche IP-Adresse angegeben?
  • Ist der DNS Server vom DHCP Server aus erreichbar?
  • Lassen sich Adressen per nslookup auflösen?
  • Liegt eine Fehlkonfiguration am DNS Server vor?
  • Blockiert eine Firewall ggf. den Netzwerkverkehr?
Nachdem alle diese Fragen geklärt sind und der Server aber sich dennoch nicht ohne Fehlermeldung hinzufügen lässt, stellt sich letztendlich noch die Frage:
  • Wie ermittelt der DHCP Server ob es sich um einen gültigen DNS Server handelt? 
Gute Frage. Innerhalb der Technet-Pages finden sich keine relevanten Informationen. Auch sonst nur wenige Suchergebnisse die sich mit diesem Thema befassen.

Deshalb, schauen wir doch einmal was hier passiert.
Dazu hier ein Mitschnitt mittels WireShark:




Nach einer kurzen Analyse lässt sich feststellen, es wird folgende Abfrage ausgeführt: "Standard Query SOA".
Vermeintlich wird also der "Start of Authority" Eintrag abgefragt.
Ok, vielleicht fehlt dieser DNS Eintrag auf dem betreffenden Server.
Dies lässt sich per DNS SnapIn ermitteln oder per nslookup:

nslookup -type=soa domain.local dnsserver.domain.local

Auch das scheint nicht der Fehler zu sein.
Der SOA Record ist vorhanden.
Fehlen ggf. noch andere DNS Einträge?
Die benötigten DNS-Records für das Active Directory lassen sich mittels
dnslint /ad prüfen:

http://support.microsoft.com/kb/321045/de

Auch hier, soweit keine Fehler ersichtlich.
Ok, nun also noch einmal ein Blick auf den WireShark Mitschnitt.

Recursion desired: Do query recursively.
Recursion available: Server can do recursive queries.


In einigen Mitschnitten erscheint auch:

Recursion available: Server can't do recursive queries.


Es scheint also eine Prüfung stattzufinden, ob der angegebene DNS Server
"recursion queries" durchführen kann.


Als "recursion query" bezeichnet man den Vorgang, wenn ein Client Anfragen an den DNS Server stellt, dieser die Anfragen aber nicht beantworten kann und deshalb die Anfragen an einen weiteren DNS Server weiterreicht.
Ok, nun sind wir also wieder einen Schritt weiter.

Üblicherweise werden die recursion queries and die "Root Hints" weitergegeben.
Zumindest dann, wenn keine Forwarder eingerichtet wurden.

Hier die Liste der default Root Hints:



Die recursion lässt sich auch direkt am DNS Server testen:



In diesem Falle schlägt diese, wie erwartet, fehl.
Ein Blick in die Firewall des Unternehmens verrät, dass diese Anfrage dort geblockt wird. Nachdem eine Ausnahmeregel definiert wurde, lässt sich der DNS Server ohne Fehler im DHCP Server hinzufügen.
Der recursion test ist ebenfalls erfolgreich.

Fazit:
Beim Hinzufügen eines DNS Servers prüft der DHCP Server (besser gesagt das DHCP Snap-In) ob der DNS Server "recursion queries" ausführen kann.
Hat der DNS Server keine Verbindung zu den Root Hints bzw. die Verbindung ist vorhanden aber die vorhandenen Firewall Richtlinien verhindern die Kommunikation, lässt sich der DNS Server nicht hinzufügen.