Default Domain Policy und Default Domain Controllers Policy ändern oder nicht?
11.01.2017 |
Long story short: Macht was ihr wollt.
Damit könnte ich den Artikel auch beenden, denn es gibt keinen einzigen technischen Grund, der für die eine oder die andere Seite ein K.O. und absolutes No Go Kriterium liefert.
Es liegt komplett in der persönlichen Vorliebe des zuständigen Administrators. Normalerweise spielt sich folgender Dialog bei meinen Kunden ab, wenn die Frage aufkommt:
- F: "Wie machen es denn Andere?"
- A: "Sowohl, als auch"
- F: "Ja, aber was wäre besser?
- A: "Das hängt davon ab ..."
- F: "Von was?"
- A: "Persönlicher Präferenz desjenigen, der entscheiden durfte"
- F: "...und, wie würden Sie es machen?"
- A: "Wenn ich entscheiden darf, dann verwende ich die Default Richtlinien und passe sie an meine Bedürfnisse an, aber es gibt ein paar Gedanken, die man sich dazu machen sollte."
Etwas Hintergrund Information für die Entscheidungsfindung:
- Die beiden Default Richtlinien haben hardcodierte GUIDs
DefDomPol: {31B2F340-016D-11D2-945F-00C04FB984F9}
DefDomConPol: {6AC1786C-016F-11D2-945F-00C04fB984F9}
Es gibt Abhängigkeiten und Automatismen zu diesen Objekten, möchte ich diese erhalten und nutzen, muss ich die beiden Objekte verwenden. Das Gegenargument ist, ich nutze sie nicht, damit nichts automatisch passieren kann ... - Aufgrund der hardcodierten GUIDs sind die beiden Richtlinien immer leicht zu identifizieren und zu troubleshooten, im Falle eines Fehlers.
- Kennwort- und Kontosperrungsrichtlinien werden von der Default Domain Policy in entsprechende Attribute im Domain Head des ADs geschrieben (siehe adsiedit.msc - Std. Namenskontext - Eigenschaften auf dc=eure,dc=dom). Direkte Änderungen im Domain Head werden durch das SYSTEM in die Default Domain Policy zurückgeschrieben. Allerdings nur vom DC mit der PDC Emulator Rolle.
Diesen Rückweg gibt es nur für die {31B2 ...}. Es gibt Drittanbieter aus dem Bereich der Passwortverwaltung die das benutzen.
- Macht man aus einem Server einen DC, so ersetzt die Default Domain Controllers Policy die Lokale Sicherheitsrichtlinie des Systems. (Nicht grundsätzlich an jeder Stelle, aber das wäre ein anderer Artikel). Installaliert man eine Software, die sich im Bereich von "Zuweisen von Benutzerechten" eintragen möchte, dann findet das automatisch in der Default Domain Controllers Policy statt. Bei einer eigenen müsste man die Einträge manuell selber nachtragen, um die Funktionalität der Software zu gewährleisten.
Vorteil bei Verwendung der DefDomConPol: Man muss nichts weiteres tun.
Nachteil: Es gilt für alle Domänen Controller und nicht nur für den, auf dem die Software läuft. - Bei der Verwendung von eigenen Richtlinien Objekten muss man die Reihenfolge der Verlinkung im Auge behalten und die eigene immer "nach oben" sortieren, damit sie gewinnt.
- Die Angst vor dem Wiederherstellen des Urzustandes. Ich höre oft das Argument, man solle die Default Richtlinien nicht editieren, damit man das Original nicht kaputt macht. a) Da geht nichts kaputt, ich verwende eine eigene, das Original wird gar nicht verwendet und dessen Zustand ist mir total egal und b) naja, in 10 Minuten hat mein ein funkelnagelneues AD auf einer virtuellen Umgebung installiert. Das hat die Default Richtlinien. GPMC - Sicherung - GPMC - Import. Fertig, Oder einfach abgucken ...
Meine persönliche Vorliebe und Best Practise:
- Ich benutze die Default Richtlinien.
- Als pauschale Regel gilt: Ich ändere was drin ist, aber ich füge nichts hinzu.
- In der Default Domain Policy werden nur Kennwort-, Kontosperrungs- und Kerberos Richtlinien editiert. Ich passe die Werte an, die nicht gewünscht sind. Es kommen keine weiteren Einstellungen hinzu. Keine Administrativen Vorlagen, keine Preferences, keine Zertifikate, nichts.
- Ich nutzte die Default Domain Controllers Policy in kleinen Umgebungen. In dieser sind nur Werte zur Überwachungsrichtlinie, Zuweisen von Benutzerrechten und Sicherheitsoptionen enthalten. Sonst nichts.
- Bei mehreren/vielen DCs kann es Sinn machen pro DC oder pro DC-Gruppe eine Richtlinie zu integrieren, damit sich ein bestimmtes Benutzerkonto einer speziellen Software nur an diesem DC anmelden kann und dort Sonderrechte hat.
Die Frage ist: Muss diese Software überhaupt auf einem DC installiert werden und wenn das Konto DomainAdminRechte hat, dann ist es auch egal, ob es für alle in der Default Domain Controllers Policy gilt oder nur für einen DC. - Alle anderen Regeln, die man anwenden möchte definiere ich in einer eigenen Richtlinie.