Hallo, hier ist Florian. Diesmal mit einem Gastbeitrag (*) zu fein-abgestuften Passwortrichtlinien bzw. Fine-Grained Password Policies (FGPP) ab Windows Server 2008.

Wer eine Domäne oder mehrere Domänen im Domänenfunktionsmodus ab „Windows Server 2008“ sein Eigen nennen kann, wird sicherlich bereits mit diesem Feature Freundschaft geschlossen, es zumindest (so hoffe ich) aber näher beäugt haben. Mit fein-abgestuften Passwortrichtlinien ist es nunmehr möglich, mehrere Passwortrichtlinien in einer einzigen Domäne zu definieren und anzuwenden. Bis jetzt konnte nur eine verpflichtende Passwortrichtlinie für die gesamte Domäne definiert werden, die per Gruppenrichtlinie auf Domänenebene verknüpft werden musste.

Der Mechanismus hat sich für FGPPs dahingehend geändert, dass nicht mehr Gruppenrichtlinien für die Erstellung der Passwortrichtlinien, sondern eigene Domänenobjekte verwendet werden. In sogenannten „Password Setting Objects“ (PSOs), die im Verzeichnis im Container CN=Password Settings Container,CN=System,DC=domaene,DC=tld abgelegt werden, sind alle Einstellungen als Objektattribute hinterlegt. Passwortobjekte werden dann mit Hilfe eines verknüpften Attributes (linked attribute, http://blogs.technet.com/deds/archive/2009/09/21/windows-server-2008-r2-recycle-bin-und-linked-attributes.aspx) ähnlich wie AD-Gruppenmitgliedschaften, an Benutzer, Gruppen und inetOrgPerson-Objekte geknüpft. Wenn nötig, wird dann für einen Benutzer anhand der direkt mit seinem Benutzerkonto und den an seinen Gruppen verknüpften PSOs die „gewinnende“ ausgewählt. Der Algorithmus und zusätzliche Informationen sind auf http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx dokumentiert.

Delegieren von PSOs

delegating PSO

Mit der Flexibilität dieses neuen Features kommt zugleich der bekannte Management-Overhead: je größer die Organisation, desto wahrscheinlicher, dass die Definition und Pflege der PSOs und deren Zuordnung nicht beim AD-Team bleibt, sondern vom Security-Team oder den Kollegen der Usererstellung und –pflege übernommen wird. Wie geht man also vor, wenn man anderen Teams im Verzeichnis die Erstellung und Pflege von PSOs delegieren möchte?

Prinzipiell gibt es da vier Ansätze, geordnet nach Zugriff, der anderen Teams gewährt wird:

(a) Vollen Zugriff auf den Container „Password Settings Container“ oder einzelne PSOs, um den Teams die Erstellung, Modifikation und das Löschen von PSOs zu ermöglichen – das bedeutet, die gesamte PSO-Administration aus der Hand zu geben und anderen Teams freie Hand bei der Erstellung, Definition und Verknüpfung von PSOs zu lassen.

(b) „Modifizieren“-Rechte delegieren, sodass vorhandene PSOs modifiziert werden können, neue allerdings nicht erstellt werden können. Das erlaubt es den anderen Teams, Einstellungen in den PSOs zu ändern und die Wirkungsweite der PSOs, also die Zielbenutzer und –gruppen, zu ändern. Das Erstellen von PSOs liegt immer noch in der Hand des AD-Teams, andere Teams sind jedoch in der Lage, bestehende PSOs zu ändern und sie anzupassen.

(c) Keine Rechte auf PSO-Ebene, dafür aber Berechtigungen, die Mitglieder in den mit den PSOs verknüpften Gruppen zu editieren. Die PSO sind in Stein gemeißelt und können, was die Einstellungen anbelangt, nicht editieren. Lediglich die Benutzer und Computer, auf die die PSO wirkt, können über Gruppenmitgliedschaften gesteuert werden.

(a) Das Ruder aus der Hand geben – anderen Teams Vollzugriff für die Erstellung von PSOs erteilen

Hierzu benötigt das neue PSO-Team, im Beispiel sind es die „psoManagers“, zum einen das Recht, den Password Settings Container zu durchsuchen und die Möglichkeit, dort Untergeordnete Objekte zu erstellen, editieren und löschen. Die Rechtevergabe kann beispielsweise mit ADSIEdit durchgeführt werden. Per Rechtsklick->Eigenschaften werden im Reiter „Sicherheit“ die folgenden Berechtigungen für den „Password Settings Container“ erteilt:

delegating PSO-a1

Berechtigungen erlauben: Lesen, Alle “Untergeordnete Objekte" (“Child Objects” im Englischen) erstellen, alle Untergeordnete Objekte löschen
Unter „Erweitert“ (“Advanced”) dann zusätzlich folgende Berechtigungen:

 delegating PSO-a2

Berechtigungen für psoManagers auf den PSO Container: untergeordneten msDS-PasswordSettings-Objekten, alle erlauben/Vollzugriff

(b) „Modifizieren“-Rechte für PSOs delegieren

Auch für „Modifizieren“-Rechte ist es notwendig, dass das PSO-Team in der Lage ist, den Password Settings Container zu lesen. Die notwendigen Rechte hierfür werden ihnen wie bereits in (a) erteilt:

delegating PSO-b1

Die beiden Berechtigungen „Alle Untergeordnete Objekte erstellen“ und „alle Untergeordnete Objekte löschen“ bleiben ihnen jedoch verwehrt. Als weitere Berechtigungen wird unter „Erweitert“ folgendes konfiguriert:

delegating PSO-b2

Das erlaubt den PSO-Managern, alle Attribute des PSO zu lesen und sie auch zu modifizieren. Wieder sollen die Berechtigungen nur für „untergenordnete msDS-PasswordSettings-Objekte“ gelten.

(c) Die Zielgruppenadministration von PSOs delegieren

Die Zielgruppenadministration kann mit zwei Methoden angegangen werden: Eine Möglichkeit ist, die PSO soweit fertig zu definieren und den Benutzern nur die Lese- und Schreibberechtigung für das Attribut „msDS-PSOAppliesTo“ zu erteilen. Bei „msDS-PSOAppliesTo“ handelt es sich um einen forwardLink eines verknüpften Attributes, das auf die Benutzer und Gruppen zeigt, mit denen die PSO verbandelt ist. Da nur forwardLinks schreibbar sind, muss den PSO-Admins das Recht erteilt werden, selbiges zu modifizieren.

Wie zuvor muss den PSO-Managern das Recht erteilt werden, Objekte im „Password Settings Container“ lesen zu können. Anschließend werden die erweiterten Berechtigungen auf Attributebene delegiert. Mit dem Tab „Eigenschaften“ wird den PSO-Managern für untergeordnete msDS-PasswordSettings-Objekte die Berechtigungen „msDS-PSOAppliesTo lesen“ und „msDS-PSOAppliesTo schreiben“ delegiert.

delegating PSO-c1

Müssen PSO-Manager den ADSIEdit-Eigenschaftendialog für die Änderung des Attributs nutzen, muss zusätzlich das Recht „Alle Attribute lesen“ für msDS-PasswordSettings-Objekte erteilt werden - ein Umstand, den man sich sparen kann, wenn Provisioningskripte oder entsprechende Tools eingesetzt werden:

delegating PSO-c2

Die zweite Methode involviert die Delegation von Gruppenmitgliedschaften vorhandener Gruppen. Anstatt den PSO-Managern die Berechtigung zu erteilen, das msDS-PSOAppliesTo-Attribut zu modifizieren, werden die Gruppen in msDS-PSOAppliesTo fest vom AD-Team vorgegeben. Den PSO-Managern wird das Recht erteilt, diese fest verdrahteten Gruppen zu modifizieren und dort weitere Benutzer und Gruppen als Mitglieder einzutragen. Hierzu wird ihnen die Schreib-Berechtigung für das Attribut „member“ erteilt. Der Vorteil dieser Lösung liegt darin, dass zum Einen der Delegierungsassistent von „Active Directory Benutzer und Computer“ verwendet werden kann, für den es schon ein fertige Aufgabe zur Auswahl gibt und zum Anderen, dass keine Delegation von Berechtigungen am „Password Settings Container“ stattfindet.
Sehr einfach funktioniert das, wenn für die PSO-Gruppen eine Sub-OU besteht, über die man die entsprechenden Berechtigungen erteilen kann:

delegating PSO-c3

Für welches Modell man sich letztlich entscheidet, hängt ganz davon ab, wie viel man den PSO-Managern zutrauen will und welche Kontrollmechanismen man behalten möchte. Ich persönlich möchte nur ungern eines Tages entsetzt feststellen, dass die Arbeitswut meiner Kollegen zu 138 gültigen PSOs in der Domäne geführt hat – aber das ist, wie so Vieles – Geschmackssache ;-)

Cheerio!

Florian

* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfasst wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.