In einer Domain habe ich Gruppenrichtlinien (GPOs) für Kennwortkomplexität und Kennwortlänge definiert, was auch wunderbar funktioniert.

Auf einem Memberserver läuft eine SQL-Datenbank, die mit der Anforderung nach komplexen Kennwörtern nicht zurechtkommt. Da das Problem bei der Installation von Zertifikaten im Rahmen einer Lizenzverlängerung aufgetreten ist, war die Verwendung von „SQL server login accounts“ mit dem Argument „CHECK_POLICY=OFF“ bei deren Definition leider keine Option.

In einigen Forumsbeiträgen habe ich gelesen, dass man Kennwortrichtlinien direkt in der „Default Domain Policy“ festlegen soll. Auf allen Microsoft-Seiten die ich zu diesem Thema gefunden habe, steht aber der übliche Hinweis die Default GPOs möglichst nicht zu verändern und auch für Kennwortrichtlinien ein neues GPO anzulegen. Es ist für mich auch kein Grund ersichtlich, warum man das nicht machen sollte. Beim Small Business Server (SBS) z.B. wird bei der Installation automatisch ein Kennwort-GPO angelegt.

Kennwort GPOs müssen zwingend auf Domain-Level verlinkt werden. Sie dürfen nicht auf OU-Level (Organisationseinheit) verlinkt werden, denn dann gelten sie nur für lokale Accounts! Damit kann man also keine Ausnahmen definieren, indem man Computer einfach in eine nicht mit der GPO verlinkten OU verschiebt.

Lösen läßt sich diese Anforderung über Berechtigungen, wie in dem sehr interessanten Artikel Best Practice: Group Policy Design Guidelines – Part 2 beschrieben ist. Dazu erzeugt man in einem ersten Schritt in „Active Directory Users and Computers“ eine globale Security Group und fügt den Computer auf dem die GPO nicht gelten soll als Mitglied hinzu (Der Computer muß neu gestartet werden, nachdem man ihn zu der Gruppe hinzugefügt hat!).

Dann klickt man im „Group Policy Management“ im Ordner „Group Policy Objects“ auf die Kennwort-GPO und aktiviert dann im rechten Fenster den Reiter „Delegation“. Dort auf „Advanced“ klicken und über „Add…“ die oben erzeugte Security Group hinzufügen. Dann die Gruppe anklicken und unten in der Liste der Berechtigungen beim Punkt „Apply Group Policy“ die Option „Deny“ aktivieren.

Jetzt kann man (wenn man die Replikation abgewartet oder mit „gpupdate“ nachgeholfen hat) im „Group Policy Management“ im Ordner „Group Policy Results“ überprüfen lassen ob die Kennwort-GPO auf dem Computer angewendet oder wie gewünscht wegen der Gruppenmitgliedschaft abgelehnt wird. Als Grund wird in diesem Fall „Access Denied (Security Filtering)“ angegeben.

Im Rahmen der Lösung dieses Problems war die „gpotool.exe“ aus den Windows Server 2003 Resource Kit Tools sehr hilfreich. Es gibt keine neuere, an Server 2008 angepaßte Version dieses Tools.