Windows Server 2012: Verwendung granularer Passwörter

2008 stellte Microsoft für das Betriebssystem eine Alternativlösung für die Problematik bezüglich unterschiedlicher Passwortanforderungen für verschiedene Benutzergruppen bereit. Diese Lösung war allerdings, um es gelinde auszudrücken, komplex und verworren. Es schien fast so, als wäre sie nur widerwillig entwickelt worden, jedoch so schwer zu implementieren, dass Sie sowieso niemand ausprobieren wollte.

Die Veröffentlichung von R2 brachte eine etwas benutzerfreundliche Funktionalität mit sich, jedoch wird Microsoft erst mit der Veröffentlichung von Server 2012 den alltäglichen Administrationsanforderungen gerecht.

Was ist der Nutzen granularer Passwörter?

Für eine große Organisation mit vielen Benutzer- und Sicherheitsleveln ist es oftmals nötig, verschiedene Anforderungen für die Passwortkomplexität und die Lockout-Richtlinien zu bestimmen. Als Beispiel wird der Büroadministrator nicht die gleichen Levels wie die Forschungs- und Entwicklungsabteilung benötigen.

Die von Windows Server 2012 bereitgestellte Lösung ist vollständig durch das Active Directory Administrative Center (ADAC) implementiert. ADAC war bereits in Server 2008 R2 verfügbar, wurde jedoch von den ‚wahren Administratoren‘ ignoriert. Eigentlich ist ADAC eine grafische Benutzeroberfläche für PowerShell Cmdlets, die die Erstellung, Editierung und Löschung jeglicher Active Directory Objekten in der ntds.dit-Datenbank ermöglicht.

ADAC ist nun wieder da und dürfte deutlich populärer werden. Das Werkzeug bietet jetzt einzigartige und wichtige administrative Funktionen (abgesehen von PowerShell Version 3.0, womit Sie fast alles verwalten können, was mit der Serververwaltung und –administration zu tun hat).

Wie verwendet man granulare Passwörter?

Um granulare Passwörter zu implementieren, muss man einen Windows Server 2012 Domain Controller mit einer eingestellten Domainfunktionsebene in Windows Server 2008 oder höher verwenden. Jetzt können Sie diese Aufgabe im ADAC lösen (vorausgesetzt, sie verwenden ‚Als Administrator ausführen‘).

Es gilt als ‘Best Practice’, einige Testgruppen und –nutzer zu erstellen, um die eigenen Fähigkeiten in diesem Bereich weiterzuentwickeln, damit von Ihnen durchgeführte Änderungen nicht den normalen Tagesablauf stören. Idealerweise führen Sie Ihre Tests auf einem ‚Sandbox Setup‘ durch. Sollte keine geeignete Testumgebung zur Verfügung stehen, verwenden sie Test-Accounts, -gruppen und -OUs um Schäden am Livesystem vorzubeugen.

In nachfolgenden Szenarien habe ich FGP_User1, FGP_User2, FGP_GP1 und FGP_GP2 eingerichtet. Benennen Sie Ihre Benutzer und Gruppen nach Ihrem Belieben. Dies kann im ‚AD Users and Computers‘-Fenster, im ADAC oder in PowerShell 3.0 erfolgen.

Jetzt die Server Manager Anwendung starten

Wählen Sie ‘Tools’ und ‘ADAC’ in der Anwendung. Im ADAC-Fenster wählen Sie die Baumansicht aus (wichtige Elemente sind so leichter sichtbar). Anschließend wählen Sie die Domäne, mit der Sie arbeiten möchten. Klappen Sie den Baum aus bis Sie die ‚System Container‘ sehen. Klappen Sie diese aus und wählen Sie den ‚Password Settings Container‘ aus.

Rechtsklick, dann ‘New’ und ‘Password Settings’ auswählen.

Das ’Create Password Settings’-Fenster öffnet sich. Hier verbergen sich mehrere vorgeschriebene Auswahlfelder, wovon die meisten vorausgewählt sind. Bestimmen Sie lediglich den Namen und die Rangordnung. (Achtung: Je niedriger die Rangnummer, desto höher die Rangordnung)

Hier lassen sich alle Einstellungen für das Objekt Passwort abändern (Länge, Lockout etc. – siehe unten). Üblicherweise sollten Sie eine Beschreibung für die Richtlinie eingeben und anschließend auf ‚Add‘ im ‚Directly Applies To‘-Bereich klicken. Wählen Sie Ihre zuvor erstellte Gruppe aus der AD aus und stellen Sie sicher, dass Ihre Richtlinie die richtigen Einstellungen zu Passwörtern und Lockouts hat.

Hier habe ich meinen Benutzer zu einer Gruppe mit zwei FGP-Richtlinien mit unterschiedlichen Rangordnungseinstellungen hinzugefügt.

Um die gültige Kennwortrichtlinie zu finden, wählen Sie den betreffenden Benutzer mit einem Rechtsklick aus:

Klicken Sie auf ‘View resultant password settings…’ und es öffnet sich die aktive Richtlinie. Für diejenigen unter uns, die bisher die alte Variante benutzt haben, können sich über einen großen Fortschritt in der Benutzerfreundlichkeit freuen.

Richtlinien ändern und löschen

Eine Richtlinie zu ändern ist sehr einfach. Klappen Sie dazu den AD-Baum aus und wählen die zutreffende Richtlinie innerhalb des ‚Password Settings container‘ aus. Machen Sie einen Rechtsklick auf ‚Properties‘ oder einen Doppelklick, um die Richtlinie zu ändern.

Um eine Richtlinie zu löschen, entfernen Sie das Häkchen im ‚Protect From Accidental Deletion‘-Kästchen (normalerweise sind Richtlinien standardmäßig gegen ausversehendes Löschen geschützt). Speichern Sie die Richtlinie und wählen Sie dann ‚Delete‘ im Rechtsklickmenü.

Im Unterschied zu Benutzern ist es nicht möglich, Richtlinien an- oder abzuschalten. Bei Existenz einer solchen ist sie aktiv für jedes Objekt, das ihr direkt zugeordnet ist. Es lassen sich Richtlinien zu Benutzern und Gruppen zuordnen, wie man im folgenden Screenshot erkennen kann. Dadurch können Sie auch die Auswirkung einer Löschung der Richtlinie sehen.

Ein Teil der ‘Big Five’

Diese Funktionalität ist einer der Windows Server 2012 ‘Big Five’-Funktionalitätsbereiche. Die Möglichkeit, granulare Passwörter nach Belieben hinzuzufügen oder zu löschen – wenn auch mit ein paar Schwierigkeiten oder tiefergehendem AD-Wissen – ist ein großer Fortschritt für diejenigen, die Jahr für Jahr nach dieser Funktion gefragt haben.

Zur Erinnerung: Als diese Funktion erstmalig in Windows Server 2008 implementiert wurde, musste man mit ADSIEDIT die neue Kennwortrichtlinie und alle Attribute (hier: Passwortlänge, Lockout-Details et cetera) erstellen. Außerdem mussten die ‚Applies to‘-Objekte in ADSIEDIT eingestellt werden. Dies war sicher nicht das benutzerfreundlichste Werkzeug aller Zeiten.

Microsoft hat nun reagiert und ein lang erwartetes Tool mit deutlich mehr Bedienerfreundlichkeit als bei vorherigen Varianten entwickelt. Nochmal zur Erinnerung: Alle Schritte können relativ leicht mit PowerShell 3.0 ausgeführt werden.

Über den Autor: Ed Baker ist Windows Server Instructor bei Firebrand Training. Er schreibt für ZDNet.de aktuell an einer Serie von „How To“-Artikeln zum Thema Windows Server 2012.