Woher kommt die Sicherheitsrichtlinie Ihres Kunden tatsächlich?

Wussten Sie, dass Ihre Clients möglicherweise domänenerzwungene Sicherheitseinstellungen erhalten können, die sich vollständig von den in Ihrer Domänenrichtlinie definierten Einstellungen unterscheiden?

Die Anwendung der Gruppenrichtlinien ist größtenteils recht einfach. Computereinstellungen gelten für Computer, und Benutzereinstellungen gelten für Benutzer, richtig? Tatsächlich erhalten Clients ihre Kontosicherheitsrichtlinie nicht direkt aus der Domänenrichtlinie. Es stammt aus der lokalen Richtlinie des Domänencontrollers. Ich habe nur wenige Administratoren gefunden, die dieses Prinzip verstehen. Es ist jedoch für die Gestaltung der Sicherheitsrichtlinien eines Unternehmens und für die Behebung von Sicherheitsproblemen wie Kennwortanforderungen und Kontosperrung von entscheidender Bedeutung.

Mal sehen, wie es funktioniert.

Grundlagen
Es gibt einige Grundprinzipien, an die wir uns erinnern müssen.

  1. Kontosicherheitseinstellungen werden nur von Richtlinien auf Domänenebene angewendet. Microsoft empfiehlt, diese Sicherheitseinstellungen in die Standarddomänenrichtlinie aufzunehmen. Es ist möglich, Kontosicherheitseinstellungen in mehrere Richtlinien auf Domänenebene einzufügen, und diese werden gemäß der normalen Gruppenrichtlinienobjekt-Priorität (Group Policy Object, GPO) unter Verwendung der Regel “Last Writer Wins” verarbeitet. Widersprüchliche Einstellungen in mehreren Richtlinien sind jedoch nicht sinnvoll und verursachen Probleme bei der Fehlerbehebung. Es ist daher eine gute Idee, die Sicherheit nur auf ein einzelnes Gruppenrichtlinienobjekt anzuwenden, unabhängig davon, ob es sich um die Standarddomänenrichtlinie oder ein spezielles Gruppenrichtlinienobjekt handelt, das als “Domänensicherheitsrichtlinie” bezeichnet wird.
  2. Es ist möglich, die Sicherheit in Gruppenrichtlinienobjekten zu definieren, die auf Organisationseinheiten (OUs) angewendet werden. Sie gelten jedoch nur für die lokalen Sicherheitsrichtlinien von Clients, die Mitglieder der Domäne sind. Wenn sich ein Benutzer bei der Domäne anmeldet, erhält er die Sicherheitseinstellungen aus der Domänenrichtlinie – nicht aus der lokalen Richtlinie (siehe Nr. 3).
  3. Domänencontroller stellen Domänenbenutzern bei der Anmeldung Sicherheitseinstellungen zur Verfügung. Dies ist ein kritisches (und verwirrendes) Konzept. Der Computer des Benutzers ruft die Sicherheitseinstellungen beim Start nicht wie bei anderen Computereinstellungen aus dem Gruppenrichtlinienobjekt ab. Der Client erhält die Sicherheitseinstellungen, wenn der Benutzer validiert wird.
  4. Die Sicherheitseinstellungen, die Domänencontroller bei erfolgreicher Benutzeranmeldung auf Clients anwenden, werden in der lokalen Sicherheitsdatenbank secedit.sdb des Domänencontrollers gespeichert.
  5. Der DC bekommt das Konto Sicherheit Einstellungen aus der Domänenrichtlinie und wendet sie auf die lokale SDB an. Beachten Sie, dass dies nur für die Kontosicherheitseinstellungen gilt, nicht für andere Richtlinieneinstellungen.
  6. DCs replizieren ihre lokale .sdb miteinander. (Ehrlich!)

Was bedeutet das alles?
Der einfachste Weg, dies zu demonstrieren, besteht darin, darauf hinzuweisen, was passiert, wenn Sie die Vererbung in der Organisationseinheit “Domänencontroller” blockieren, was einige Organisationen tun. Wenn Sie die Vererbung blockieren, gelangen Ihre Kontorichtlinieneinstellungen nicht in die secedit.sdb des Domänencontrollers (siehe Nr. 1 und Nr. 5 oben) und werden daher nicht auf den Client angewendet (siehe Nr. 3 oben).

Angenommen, Sie haben in der Standarddomänenrichtlinie vor dem Blockieren der Vererbung eine Kennwortlänge von 8 Zeichen definiert. Daher haben die DCs diesen Wert in ihrer lokalen secedit.sdb definiert. Anschließend legen Sie die Option Blockvererbung in der Organisationseinheit Domänencontroller fest. Später haben Sie ein Unternehmensmandat, um die Mindestlänge des Passworts auf 10 zu ändern.

Folgendes passiert, wenn Sie die Option “Blockvererbung” in der Organisationseinheit “Domänencontroller” wie oben beschrieben festlegen:

Melden Sie sich zunächst bei einem Client mit einem Domänenkonto an und setzen Sie das Kennwort auf ein 8-stelliges Kennwort zurück. Es funktioniert, sollte es aber nicht, weil in der Richtlinie 10 steht – richtig? Führen Sie GPresult / v aus (vorausgesetzt, der Client ist XP) und die Kennwortlänge beträgt 10. Tabelle 1 zeigt dies grafisch, vorausgesetzt, der Benutzer ist mit einem Domänenkonto angemeldet, zusammen mit anderen Einstellungen für Kontorichtlinien.

RahmenDomänenrichtlinienwertDC secedit.sdb WertLokale RichtlinieneinstellungEffektive Einstellung für den Benutzer
Passwortlänge108108
Passwortverlauf245245

Tabelle 1. Dies sind die effektiven Einstellungen, wenn sich Benutzer mit einem Domänenkonto anmelden, wenn die Blockvererbung in der Organisationseinheit Domänencontroller aktiviert wurde.
Hinweis: In Windows 2000 Pro hatte die Benutzeroberfläche der lokalen Sicherheitsrichtlinie eine Spalte mit dem Namen “Effektive Einstellungen.“Dies wird in XP nicht angezeigt. Der hier verwendete Begriff” Effektive Einstellungen “bezieht sich auf die tatsächlichen Einstellungen, die sich auf den Benutzer auswirken, je nachdem, ob sich die Person als lokaler Benutzer oder als Domänenbenutzer anmeldet.

Aus dieser Tabelle können Sie ersehen, dass der Benutzer, wenn er sich mit einem Domänenkonto anmeldet, die Richtlinie von dem Domänencontroller erhält, der in der secedit.sdb des Domänencontrollers gespeichert ist.

Tabelle 2 zeigt, was Benutzer erleben, wenn sie sich bei einem lokalen Konto anmelden.

RahmenDomänenrichtlinienwertDC secedit.sdb WertLokale RichtlinieneinstellungEffektive Einstellung für den Benutzer
Passwortlänge1081010
Passwortverlauf2452424

Tabelle 2. Dies sind die effektiven Einstellungen, wenn sich Benutzer mit einem lokalen Konto anmelden, wenn die Blockvererbung in der Organisationseinheit Domänencontroller aktiviert wurde.
Sie können sehen, dass dies sehr verwirrend ist. In jeder Hinsicht scheint es, dass der Client die Domänenrichtlinienwerte erhält, die effektive Einstellung jedoch unterschiedlich ist. Wenn der Benutzer in einem lokalen Benutzerkonto angemeldet ist, erhält er die lokale Sicherheitsrichtlinie, die mit den dem Client auferlegten Domänenrichtlinieneinstellungen gefüllt ist. Wenn der Benutzer jedoch beim Domänenkonto angemeldet ist, erhält er die Einstellungen, die der Domänencontroller in seiner secedit.sdb hat. Die secedit.sdb des DC verfügt über die letzten Einstellungen, die er von der Domänenrichtlinie erhalten hat, bevor die Option Blockvererbung aktiviert wurde. Wenn Blockvererbung aktiviert ist, können die in der Domänenrichtlinie definierten neuen Einstellungen nicht in die Domänencontroller übernommen werden. Wenn der Client den DC kontaktiert, erhält er die dem DC bekannten Einstellungen, die sich von den Angaben in der tatsächlichen Richtlinie unterscheiden.

Warum?
Wenn das Blockieren der Vererbung in der Organisationseinheit “Domänencontroller” ein solches Chaos verursacht, warum dann? Viele Unternehmen stellen eine Reihe von Gruppenrichtlinienobjekten auf Domänenebene bereit, z. B. für die Sperrung von Desktops. Offensichtlich möchten Sie keine Sperrrichtlinien auf Domänencontroller anwenden. Durch Aktivieren der Blockvererbung in der Organisationseinheit Domänencontroller wird verhindert, dass verschiedene Einstellungen auf Domänencontroller angewendet werden. Es gibt bessere Designs, die dies verhindern würden, z. B. das Einfügen der Sperrrichtlinien in Organisationseinheiten. In einigen Fällen ist jedoch die Blockvererbung eine gute Option.

Wie es funktioniert
Sie müssen die Vererbung in der Organisationseinheit Domänencontroller blockieren, aber das bringt die Sicherheitsrichtlinie durcheinander. Wie schaffen wir es also, dass alles zusammenarbeitet? Hier sind Ihre Optionen:

  • Stellen Sie im Gruppenrichtlinienobjekt, in dem die Sicherheitseinstellungen definiert sind, die Option Keine Überschreibung ein. Dadurch werden die Kontoeinstellungen trotz der Einstellung “Blockvererbung” in die Organisationseinheit “Domänencontroller” verschoben.
    ODER
  • Definieren Sie auf einem Domänencontroller die lokalen Sicherheitseinstellungen so, dass die Kontorichtlinien den Anforderungen für die Domäne entsprechen. Es scheint, dass die DCs dies untereinander replizieren werden. Ich weiß nicht, ob es sicher ist anzunehmen, dass dies immer passiert. Deshalb überprüfe ich immer die secedit.sdb des anderen DC, um sicherzustellen, dass die Änderung vorgenommen wird.
    ODER
  • Verwenden Sie die Sicherheitsfilterung, damit Sperrrichtlinien nicht für Domänencontroller gelten.

Für mein Geld ist das Festlegen der Option “Keine Überschreibung” am einfachsten. Beachten Sie jedoch, dass dadurch auch andere in diesem Gruppenrichtlinienobjekt definierte Richtlinieneinstellungen erzwungen werden. Daher würde ich folgendes empfehlen:

  • Definieren Sie ein Gruppenrichtlinienobjekt für einen Zweck namens Kontosicherheitsrichtlinie.
  • Konfigurieren Sie die Einstellungen für die Kontosicherheit (Kennwort, Kontosperrung, Kerberos) wie gewünscht.
  • Aktivieren Sie die Option Keine Überschreibung im Gruppenrichtlinienobjekt für Kontosicherheitsrichtlinien.

Was ist mit den Kerberos-Einstellungen?
Genau wie die Kennwortlänge festgelegt wurde (aus einem tatsächlichen Client-Fall, an dem ich gearbeitet habe), gilt das gleiche Prinzip für alle Kontorichtlinieneinstellungen – Kennwort, Kontosperrung und Kerberos. In einem anderen Fall hatte der Administrator beispielsweise die Kerberos-Einstellung “Maximale Toleranz für die Synchronisierung der Computertaktung” auf “Nicht definiert” gesetzt (Standard ist 5 Minuten), wodurch sie auf den Domänencontroller angewendet wurde. Dann blockierten sie die Vererbung in der Organisationseinheit Domänencontroller. Diese Einstellung definiert den Zeitversatz, der zwischen den Clients für die erfolgreiche Authentifizierung von Kerberos zulässig ist (der Standardwert beträgt 5 Minuten). Ich weiß nicht, warum sie es auf “Nicht definiert” gesetzt haben. Bei Einstellung auf Nicht definiert ist der Versatz Null (0), sodass die Authentifizierung immer fehlschlägt, da die Uhren zwischen Client und DC niemals perfekt übereinstimmen würden. Zusätzlich zu fehlgeschlagenen Clientanmeldungen ist auch die Replikation fehlgeschlagen. Das Unternehmen entschied sich dafür, die secedit.sdb des Domänencontrollers zu ändern und den Zeitversatz auf fünf Minuten festzulegen, anstatt in der Domänensicherheitsrichtlinie No Override festzulegen, und das Problem wurde behoben.

Beachten Sie, dass Kerberos-Einstellungen nur auf Domänenebene definiert werden können. Schauen Sie in die Standardrichtlinie für Domänencontroller, und Sie werden die Einstellungen nicht sehen.

Fazit
Wenn Sie die Vererbung in der Organisationseinheit “Domänencontroller” niemals blockieren, wird dieses Problem nie auftreten. Trotzdem ist es gut, diese Situation zu verstehen, damit Sie wissen, wie die Sicherheitsrichtlinie angewendet wird, und bereit für eine solche Situation sind. Wenn Sie jemals ein Edikt von “oben” erhalten, um die Vererbung in dieser Organisationseinheit zu blockieren, sind Sie bereit, die Auswirkungen zu erläutern, anstatt den Support anzurufen, wenn Benutzer sich beschweren, dass sie sich nicht anmelden können.

Gary Olsen ist Systemsoftware-Ingenieur bei Hewlett-Packard im Bereich Global Solutions Engineering. Er hat geschrieben Windows 2000: Active Directory-Entwurf und -Bereitstellung und Co-Autor Windows Server 2003 auf HP ProLiant Servern.

Similar Posts

Leave a Reply