Einen Überblick über SetACL Studio findet ihr (noch aus der Betaphase) bei uns:

[faq-o-matic.net » SetACL Studio – Die Beta ist da]
http://www.faq-o-matic.net/2011/08/08/setacl-studio-die-beta-ist-da/

… und natürlich aktuell bei Helge selbst:

[SetACL Studio | Helge Klein | Home of SetACL]
http://helgeklein.com/setacl-studio/

Verwandte Beiträge:

1. SetACL Studio – Die Beta ist da
   SetACL Studio verwaltet (fast) alles rund um Windows-Berechtigungen. Es bearbeitet...
2. Ankündigung: SetACL Studio – Die Leistung von SetACL kombiniert mit einer supereinfachen Oberfläche
   SetACL ist bekannt als leistungsfähiges und vielseitiges Werkzeug zur Verwaltung...
3. Berechtigungen professionell verwalten mit SetACL
   Wenn heute in Foren darüber diskutiert wird, welche Tools am...

[Deployment von MSP-Updates über WSUS: Teil 1 (Konfiguration) | How the ESCde does IT]
http://infrablog.escde.net/2011/03/18/deployment-von-msp-updates-uber-wsus-teil-1-konfiguration/

[Deployment von MSP-Updates über WSUS: Teil 2 (Paketerstellung für Adobe Reader X) | How the ESCde does IT]
http://infrablog.escde.net/2011/03/31/deployment-von-msp-updates-uber-wsus-teil-2-paketerstellung-fur-adobe-reader-x/

Beim zweiten Artikel empfiehlt es sich, auch einen Blick auf den ersten Kommentar zu werfen, der einen zusätzlichen Trick mit Hilfe eines SQL-Kommandos hinzufügt.

Verwandte Beiträge:

1. SP1-Problem bei Windows 7 und 2008 R2: WSUS-Installation optimiert
   Ein Eintrag im WSUS-Teamblog weist darauf hin, dass das Service...
2. Get WSUS Content .NET: Updates flexibel
   Updates sind wichtig – oder wie installiert man möglichst bequem...
3. Microsoft-Updates ohne WSUS verteilen – Teil 1
   Achtung! Zu der hier vorgestellten Software gibt es eine völlig...

Wie kann ich Benutzer- oder Computerkonten in Active Directory identifizieren, die nicht mehr benötigt werden?

Auf diese naheliegende Frage gibt es eine einfache Antwort: OldCmp.

OldCmp identifiziert:

• veraltete Computerobjekte
• veraltete Userobjekte (obwohl der Name anderes verheißt)

anhand wählbarer Kriterien, z.B. dem letzten Anmeldedatum, der letzten Kennwortänderung, nur in einem bestimmten Ordner oder ähnlich. Mit den gefundenen Daten kann OldCmp:

• Berichte erzeugen in HTML (mit nützlichen Zusatzdaten)
• Listen erzeugen als CSV
• Objekte deaktivieren
• Objekte in einen Ordner verschieben
• Objekte löschen

Das Tool eignet sich also sowohl zur Analyse als auch für das Reporting ganz hervorragend.

[OldCmp]
http://www.joeware.net/freetools/tools/oldcmp/index.htm

Verwandte Beiträge:

1. Active-Directory-Massenoperationen mit AdMod und AdFind
   Windows Server 2003 enthält die so genannten "ds*-Tools": Eine Sammlung...
2. LUMAX: Schnelle Auswertung des Active Directory
   Ich habe schon häufig nach einem Tool gesucht, mit dem...
3. Wie deaktiviere ich Drag & Drop in "Active Directory-Benutzer und -Computer"?
   Seit dem Erscheinen von Windows Server 2003 ist es möglich,...

Steve Goodman hat ein PowerShell-Skript publiziert, das bei der Dokumentation einer Exchange-Umgebung (Exchange 2010 und 2007) gute Dienste leistet. Es liest die Exchange-Organisationskonfiguration sowie Details zu den Servern und Mailboxen aus und stellt diese in einem übersichtlichen HTML-Report dar.

Das kleine Werkzeug berücksichtigt auch Besonderheiten wie Database Availability Groups (DAG) sowie die Verteilung von Servern und Mailboxen über verschiedene Standorte.

[Generate Exchange Environment Reports using Powershell]
http://www.stevieg.org/2011/06/exchange-environment-report/

Verwandte Beiträge:

1. Whitepaper: DAG-Cluster mit Exchange 2010
   Wenn man im Unternehmen Exchange 2010 einsetzt, dann ist man...
2. Exchange 2010: Getrennte Mailboxen auflisten
   Anders als in der Onlinehilfe beschrieben, tauchen getrennte Mailboxen oft...
3. Exchange-DAG in VM-Cluster jetzt voll supported
   Gestern hat Microsoft seine Supportrichtlinien für Exchange Server 2010 erweitert....

Zwei Dinge sind neu:

SetACL Studio bietet eine Undo-Funktion, kann also alle Änderungen rückgängig machen. Der simpelste Texteditor ist ohne Undo undenkbar, aber Systemverwaltungstools kennen eine solche Funktion praktisch gar nicht. Höchste Zeit, dass sich das ändert. Sie werden diese Funktion schnell in anderen Programmen vermissen.

SetACL Studio ist jetzt verfügbar. Es ist mir eine große Freude, mitteilen zu können, dass SetACL Studio den Beta-Status erreicht hat.

Download

Download über helgeklein.com

Preis

SetACL Studio ist kostengünstig. Es wird 9,95 Euro kosten.

Systemanforderungen

Windows XP / Server 2003 oder neuer mit dem .NET framework 4.0 Client Profile (einer etwas kleineren Version des Framework).

Unterstützte Sprachen

SetACL Studio funktioniert unter allen Windows-Sprachen. Das Programm selbst enthält deutsche und englische Texte und stellt sich automatisch auf die jeweilige Systemsprache ein.

Verwandte Beiträge:

1. SetACL Studio ist verfügbar
   Vor einigen Tagen hat Helge Klein, Autor des Berechtigungs-Werkzeugs SetACL,...
2. Ankündigung: SetACL Studio – Die Leistung von SetACL kombiniert mit einer supereinfachen Oberfläche
   SetACL ist bekannt als leistungsfähiges und vielseitiges Werkzeug zur Verwaltung...
3. Berechtigungen professionell verwalten mit SetACL
   Wenn heute in Foren darüber diskutiert wird, welche Tools am...

Im Einzelnen:

• Neue Funktionen:
  • Exchange-Schemaversion 2010 SP1
  • Anzahl Werte bei Multi-Value-Feldern (z.B. Gruppen – die Anzahl Gruppenmitglieder ist so leicht abzulesen)
  • alle DCs der aktuellen Domäne in Domänen-Info angegeben
  • OUs jetzt mit Angabe der Schachtelungstiefe (erleichtert die Orientierung bei langen Reports)
  • Optionale Angabe von Details, falls José Objekte nicht lesen kann
• Korrekturen:
  • Korrektur UAC-Flags
  • Korrektur der Objektzählung: Objekte im Domain-Root werden jetzt gezählt
  • "memberOf" jetzt korrekt übersetzt
  • OUs mit Schrägstrich im Namen erzeugen keinen Abbruch mehr

Hier ist der Download:

Hier allgemeine Informationen zu José:

[faq-o-matic.net » José: Version 3.0 ist da]
http://www.faq-o-matic.net/2010/05/26/jos-version-3-0-ist-da/

Verwandte Beiträge:

1. José 2.2: Fehlerkorrektur und kleine Ergänzung
   Soeben habe ich die Version 2.2 von José online gestellt....
2. Kleines Update für José
   Update 22. Oktober 2008: Es gibt eine neue Fassung von...
3. José 2.3: Kleine Korrektur
   Mein Dokumentationswerkzeug ”José” zur Dokumentation der logischen Active-Directory-Struktur liegt jetzt...

Falsch. Es ist zwar fast unmöglich, eine große Funktionsvielfalt in ein Kommandozeilenprogramm zu packen, ohne dass die Bedienung komplex wird, jedoch gilt das nicht für GUI-Anwendungen.

Daher hier ohne weitere Umschweife die ersten Bilder von SetACL Studio, meinem neuen Tool zur Verwaltung von Berechtigungen.

Sie werden bemerkt haben, dass SetACL Studio Teile des Systems zeigt, die Normalsterblichen üblicherweise verwehrt bleiben. Es kann auch mit sehr langen Dateisystempfaden umgehen und setzt Berechtigungen sowohl auf Dateien und Ordner als auch auf Registrierungsschlüssel, Drucker, Freigaben, Dienste und sogar WMI-Objekte. Aber das ist noch nicht einmal das Beste.

Das Beste daran ist, dass diese vielfältigen Funktionen … unter einer netten und extrem leicht zu bedienenden Oberfläche stecken. Man muss nicht fünf Mal klicken, nur um den Besitzer einer Datei zu sehen. Alles Wesentliche ist auf einer Seite und kann mit einem einzigen Klick verändert werden.

Eine Beta-Version wird bald verfügbar sein. Informationen dazu werden auf helgeklein.com/news veröffentlicht werden.

Informationen zu SetACL und den weiteren freien Tools des Autors finden sich auf helgeklein.com.

Verwandte Beiträge:

1. SetACL Studio – Die Beta ist da
   SetACL Studio verwaltet (fast) alles rund um Windows-Berechtigungen. Es bearbeitet...
2. SetACL Studio ist verfügbar
   Vor einigen Tagen hat Helge Klein, Autor des Berechtigungs-Werkzeugs SetACL,...
3. Berechtigungen professionell verwalten mit SetACL
   Wenn heute in Foren darüber diskutiert wird, welche Tools am...

• Kurzer Report:
  cscript //nologo cindy.vbs DC01>DC01.txt
• Langer Report:
  cscript //nologo cindy.vbs /mode:all DC01>DC01.txt

Hier der Original-Artikel mit der Beschreibung des Skripts:

faq-o-matic.net » Cindy: WMI-Dokuskript für Windows-Rechner]
http://www.faq-o-matic.net/2011/01/24/cindy-wmi-dokuskript-fr-windows-rechner/

Und hier der Download:

Verwandte Beiträge:

1. Cindy: WMI-Dokuskript für Windows-Rechner
   Das VBS-Skript Cindy liest per WMI zahlreiche Konfigurationsinformationen von einem...
2. Exchange-Dokumentation im HTML-Format
   Steve Goodman hat ein PowerShell-Skript publiziert, das bei der Dokumentation...
3. José Active-Directory-Dokumentation: Version 2.0 ist fertig
   Achtung, Update 28. Mai 2010: Version 3.0 ist aktuell! Nutzt...

Dieser Umstand war bekannt, und Microsoft hatte angekündigt, innerhalb von 30 Tagen nach dem Release des SP1 die erneuerten RSAT nachzuliefern. Das ist nun geschehen – erfreulicherweise etwas früher als erwartet.

[Download Remoteserver-Verwaltungstools für Windows 7 mit Service Pack 1 (SP1)]
http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d

Verwandte Beiträge:

1. RSAT für Windows 7 RC
   Es ist wie im Admin-Himmel: Mit Windows 7 denkt Microsoft...
2. Hinweise zu SP1 für Windows Server 2008 R2 und Hyper-V
   Das Service Pack 1 für WIndows Server 2008 R2 steht...
3. RSAT für Windows 7 RTM sind RTW
   Wow, welch eine Überschrift. Die Remote Server Administration Tools für...

In der Praxis stellt man aber immer wieder fest, dass viele Admins unsicher sind, wie sie Gruppen sinnvoll einsetzen können. Das liegt vor allem daran, dass das Gruppenkonzept im Detail erheblich komplexer ist als in der kurzen Darstellung oben. Dieser Artikel fasst daher einige Grundlagen und Empfehlungen zusammen.

So viele Arten von Gruppen!

Das größte Verständnisproblem entsteht durch die hohe Anzahl verschiedener Gruppentypen, die Windows bereithält. Diese Gruppen verhalten sich in bestimmten Zusammenhängen unterschiedlich, daher kommt nicht jeder Gruppentyp für jeden Zweck in Frage. Hier eine kurze Einordnung auf Basis der Technik seit Windows 2000 (als Active Directory eingeführt wurde).

Lokale Gruppen

Jeder Windows-Rechner verfügt über lokale Gruppen, die teilweise bereits vordefiniert sind, die man aber auch selbst erzeugen kann. Solche lokalen Gruppen existieren und wirken ausschließlich auf dem jeweiligen Computer und haben keine Auswirkung auf andere Rechner. Auch ein Ex- und Import solcher Gruppen ist nicht möglich.

Welche Gruppen es lokal gibt, kann man in der Kommandozeile feststellen mit:

net localgroup

Die Mitglieder einer bestimmten Gruppe bekommt man angezeigt, wenn man deren Namen an das obige Kommando anhängt. Je nachdem, welche Software auf einem System installiert ist, kann es durchaus eine große Anzahl solcher lokalen Gruppen geben. Manuell legt man lokale Gruppen eher selten an, aber je nach Anforderung kann auch das bisweilen vorkommen.

Drei vordefinierte Gruppen verdienen nähere Erwähnung, weil es sie auf jedem Windows-System gibt und weil sie im gesamten Rechtesystem eine tragende Rolle spielen:

• Administratoren

  Wer dieser Gruppe angehört, verfügt über volle Verwaltungsrechte auf dem Rechner. Ein Mitglied der “Administratoren” kann jede Systemeinstellung verändern, Software jeder Art installieren und entfernen und sich Rechte und Berechtigungen an jedem Objekt und jeder Datei verschaffen. Zwar ist es durchaus möglich, in den Berechtigungseinstellungen etwa einer Datei den Administratoren den Zugriff zu verweigern, aber als Mitglied der “Administratoren” kann ein Benutzer das immer rückgängig machen.

  Höhere Rechte als “Administrator” kann man in einem Windows-System nicht haben. Auch eine Anmeldung als “Domänen-Administrator” oder als “Organisations-Administrator” verschafft einem lokal keine Zugriffe, die man als “Administrator” nicht hätte! (Zwar vermuten sehr viele Admins, dass dies so sei, aber das ist nur ein Mythos.)

• Benutzer

  Um einen Rechner überhaupt verwenden zu dürfen, muss man der Gruppe “Benutzer” angehören. Dafür sorgt Windows automatisch, wenn man lokale Benutzerkonten erzeugt, weil es diese gleich in die Gruppe “Benutzer” aufnimmt. In einer Windows-Domäne wird die Gruppe “Domänen-Benutzer” auf jedem Rechner in die jeweils lokalen “Benutzer”-Gruppen aufgenommen: Nur dadurch ist es möglich, dass man sich mit einem Domänen-Benutzerkonto (standardmäßig) an jeden Rechner der Domäne anmelden kann.

• Hauptbenutzer

  Diese Gruppe verfügt auf einem lokalen Computer bis einschließlich Windows XP über erweiterte Berechtigungen. Seit Windows Vista ist die Gruppe zwar noch vorhanden, aber sie verfügt nicht mehr über Sonderrechte.

  Mitglieder der “Hauptbenutzer” können bis Windows XP sehr viele Dinge im System verändern und haben weitgehende Schreibrechte. Dadurch entstehen erhebliche Sicherheitsprobleme, denn mit wenig Aufwand ist es einem Hauptbenutzer in der Praxis möglich, sich zum vollwertigen “Administrator” zu machen. Daher ist von der Nutzung dieser Gruppe erheblich abzuraten!

Domänenlokale Gruppen

Im englischen Original heißt dieser Gruppentyp “Domain Local Group”, in der deutschen Windows-Oberfläche ist üblicherweise von “Gruppe der lokalen Domäne” die Rede.

Es handelt sich dabei um Gruppen, die in Active Directory gespeichert sind und auf allen Rechnern derselben Domäne zur Erteilung von Berechtigungen genutzt werden können. Domänenlokale Gruppen können auch Mitglieder aus anderen Domänen aufnehmen, zu denen eine Vertrauensstellung besteht (Forest-interne Vertrauensstellung oder auch externe Vertrauensstellung); als Mitglieder lassen sich Benutzer- oder Gruppenkonten auswählen. Da dieser Gruppentyp nur in der eigenen Domäne sichtbar ist, eignet er sich zur Verwaltung von Zugriffen auf Ressourcen (z.B. Dateiserver, Druckserver, Datenbanken usw.) in der lokalen Domäne – daher der Name.

Das Windows-Gruppenkonzept sieht vor, dass man vorwiegend diesen Gruppentyp einsetzt, um in der eigenen Domäne Berechtigungen zu verwalten. Die Logik dahinter: Eine Domäne fasst üblicherweise die Ressourcen eines “Hoheitsbereichs” zusammen, und wer diesen Hoheitsbereich verwaltet, soll auch Kontrolle über die Zugriffsrechte haben. Gleichzeitig soll es aber möglich sein, auch Anwendern aus anderen, vertrauten Domänen die Nutzung einzelner Daten und Dienste zu gestatten, daher kann man in Gruppen dieser Art eben auch Konten der anderen Domänen aufnehmen. Das macht die Rechteverwaltung sehr effizient, weil man für ein bestimmtes Zugriffsrecht nur eine einzige Gruppe pflegen und berechtigen muss.

“Builtin”-Gruppen

Einen Sonderfall unter den Domänenlokalen Gruppen stellen die Gruppen im AD-Container “Builtin” dar. Hierbei handelt es sich um die Lokalen Gruppen der Domänencontroller – eigentlich sind es also gar keine Domänenlokalen Gruppen, sondern Lokale Gruppen, und daher sind sie auch nur direkt auf den Domänencontrollern sichtbar und nutzbar.

Die Builtin-Gruppen dienen dazu, Berechtigungen zu verwalten, die nur direkt auf den Domänencontrollern gelten. Wer etwa Mitglied der Gruppe “Builtin\Sicherungsoperatoren” ist, darf ein Backup aller Domänencontroller ausführen – aber kein Backup anderer Computer. Es ist dabei nicht möglich, diese Berechtigung auf einzelne Domänencontroller einzugrenzen, sondern sie gelten immer auf allen DCs.

Es ist wichtig zu wissen, dass die Builtin-Gruppen ausschließlich auf Domänencontrollern gelten. In allen alltäglichen Verwaltungsaufgaben kann man den ganzen Container “Builtin” daher praktisch ignorieren, weil die Berechtigungsverwaltung für DCs eher keine Standardaufgabe ist.

Globale Gruppen

Die Globalen Gruppen sind ebenfalls in Active Directory gespeichert. Im Unterschied zu den Domänenlokalen Gruppen können sie nur Mitglieder aus der eigenen Domäne enthalten, aber keine Konten aus anderen Domänen. Dafür sind diese Gruppen aber in anderen, vertrauten Domänen sichtbar und können dort Berechtigungen erhalten oder auch in Domänenlokale Gruppen dieser anderen Domäne aufgenommen werden.

Prinzipiell ist dieser Gruppentyp dazu gedacht, Benutzerkonten nach logischen Kriterien zusammenzufassen, also etwa nach Abteilung oder nach Funktion.

Vordefinierte Gruppen dieses Typs umfassen die Domänen-Admins und die Domänen-Benutzer. Üblicherweise legt man eine größere Menge dieser Gruppen manuell an, um organisatorische Anforderungen abzudecken.

Universalgruppen

In der deutschen Windows-Oberfläche nennt sich dieser Gruppentyp “Universell”. Gruppen dieser Art können Mitglieder aus allen Domänen des Forests aufnehmen (aber nicht aus externen vertrauten Domänen!) und sind in allen Domänen des Forests sichtbar.

Damit eignet sich dieser Gruppentyp in Multi-Domänen-Forests dazu, Benutzer domänenübergreifend zusammenzufassen und ihnen in beliebigen Domänen des Forests Berechtigungen zu erteilen. Nun könnte man meinen, dieser Gruppentyp sei damit ja auch der flexibelste und deshalb nur noch mit dieser Sorte arbeiten. Davon ist aber abzuraten: Einerseits erzeugen diese Gruppen einen gewissen Overhead, denn im Unterschied zu den anderen Typen speichert Active Directory sie nicht innerhalb der Domäne, sondern im Global Catalog. Andererseits ist dieser Gruppentyp in großen Umgebungen mit mehr als einer Domäne schwer abzugrenzen – eben deshalb, weil er Mitglieder aus allen Domänen enthalten und gleichzeitig in allen Domänen Berechtigungen haben kann. Eine solche Gruppe zu verändern, ist daher immer ein planungs- und analyseintensiver Schritt.

Seit Exchange 2007 allerdings haben Universalgruppen eine besondere Funktion: Exchange akzeptiert nur Gruppen dieses Typs als Verteilergruppen (jedenfalls wenn man sie neu anlegt). Der Grund dafür liegt wiederum in Multi-Domänen-Forests, in denen nur die Mitglieder von Universalgruppen mit Sicherheit in jeder Teildomäne des Forests auflösbar sind.

Zu den vordefinierten Gruppen dieses Typs gehören die “Organisations-Admins” (englisch: “Enterprise Admins”) und die “Schema-Admins”.

Pseudo-Gruppen

Neben diesen “normalen” Gruppen, die man (zum größten Teil) manuell erzeugen kann und deren Mitgliedschaft durch die Administratoren ausdrücklich gepflegt wird, gibt es noch einen weiteren, völlig anderen Gruppentyp. Die Pseudo-Gruppen (oft auch als “Systemgruppen” bezeichnet) werden ausschließlich vom Betriebssystem verwaltet, eine manuelle Änderung der Mitgliedschaft ist nicht möglich. In den meisten Fällen entscheidet die Art, wie ein Anwender sich anmeldet, über die Mitgliedschaft. An solche Gruppen werden innerhalb des Betriebssystems, aber durchaus auch an anderen Stellen, Berechtigungen für spezielle Zwecke vergeben.

Einige Beispiele:

• Authentifizierte Benutzer: Diese Gruppe enthält immer die Anwender, die aktuell gültig an einem System angemeldet sind. Seit Windows XP, Service Pack 2, ist sie funktional identisch mit der Gruppe “Jeder”. Nicht enthalten sind anonyme Anwender, die ohne Anmeldung auf einen Dienst zugreifen, beispielsweise bei einem Webserver.
• Interaktiv: In dieser Gruppe sind alle Benutzer Mitglied, die sich direkt lokal (= “interaktiv”) an ein System angemeldet haben. Dadurch lassen sich die momentanen lokalen Benutzer eines Systems zur Berechtigungsvergabe identifizieren. Nicht enthalten sind Benutzer, die über das Netzwerk einen Dienst nutzen (z.B. beim Zugriff auf einen Dateiserver).
• Netzwerk: Zu dieser Gruppe zählen angemeldete Benutzer, die nur über das Netzwerk auf einen Dienst zugreifen. Nicht enthalten sind lokal angemeldete Anwender.
• Ersteller/Besitzer: Dies ist eigentlich keine Gruppe, sondern ein Platzhalter für Berechtigungen. Darüber lässt sich festlegen, dass der Benutzer, der ein Objekt (z.B. eine Datei) erzeugt hat, bestimmte Rechte an diesem Objekt erhalten soll.
• Selbst: Auch dies ist eigentlich keine Gruppe, sondern ebenfalls ein Platzhalter, der aber nur in Active-Directory-Berechtigungen auftaucht. Mit diesem Platzhalter lassen sich Berechtigungen für den Fall verwalten, dass ein Konto auf sein eigenes AD-Objekt zugreift. Öffnet also etwa die Benutzerin “Ute” im AD-Verwaltungsprogramm das Userobjekt “Ute”, dann greift für sie die Berechtigung “Selbst”, denn es ist ja ihr eigenes Objekt. Diesen Kniff nutzt Active Directory für ein paar Standardberechtigungen; so kann z.B. jeder Anwender standardmäßig seine eigene Telefonnummer in Active Directory bearbeiten.

An vielen Stellen erkennt man solche Gruppen an dem Präfix “NT-AUTORITÄT”.

Wie Berechtigungen funktionieren

Windows verwaltet alle Berechtigungen auf der Basis von Security Identifiers (SID). Jedes Sicherheitsobjekt – also jedes Benutzer-, Computer- oder Gruppenkonto – hat einen solchen eindeutigen SID, der sich niemals ändert. Auf diese Weise ist es möglich, ein Objekt umzubenennen, ohne dass es seine Berechtigungen verliert.

Bei der Anmeldung ans System erhält jeder Benutzer ein “Access Token”, das u.a. seinen eigenen SID und die SIDs aller Gruppen enthält, in denen er Mitglied ist. Dieses Access Token bildet dann seinen Berechtigungsausweis für alle Zugriffe. Da es nur bei der Anmeldung erzeugt wird, sind alle Änderungen an Gruppenmitgliedschaften, die während der laufenden Arbeitssitzung erfolgen, wirkungslos. Erst bei der nächsten Anmeldung wird ein neues Access Token erzeugt, das die dann gültigen Mitgliedschaften umfasst.

Versucht der Anwender, auf bestimmte Daten zuzugreifen, so überträgt Windows im Hintergrund die genaue Zugriffs-Anforderung und das Access Token an den jeweiligen Dienst. Der Dienst prüft dann die Berechtigungen des Objekts (niedergelegt in der “Access Control List”, ACL), ob für eine oder mehrere SIDs im Access Token des Benutzers die passenden Rechte hinterlegt sind. Nur wenn die Zugriffs-Anforderung durch die vorhandenen Berechtigungen genau erfüllt werden kann, gibt der Dienst den Zugriff frei, anderenfalls verweigert er ihn (Alles-oder-nichts-Prinzip). Fordert ein Anwender also etwa einen Schreib- und Lesezugriff an, aber seine Berechtigungen erlauben nur den Lesezugriff, dann kann er gar nicht auf das Objekt zugreifen. (In der Praxis merkt man das manchmal nicht, weil eine Applikation in diesem Fall einen erneuten Zugriff nur zum Lesen versuchen könnte.)

Um sich das Access Token anzusehen, kann man das Kommandozeilentoll “whoami” nutzen, das seit Windows Vista immer installiert ist (in früheren Versionen kann man es aus den Support Tools nachinstallieren). Die effektiven Gruppenmitgliedschaften sieht man etwa mit:

whoami /groups

Alle Einträge des Tokens (einschließlich des Benutzer-SID und der Privilegien auf dem eigenen System) zeigt:

whoami /all

Das A-G-DL-P-Prinzip

Das Gruppenkonzept von Windows und Active Directory wurde nach einem bestimmten Prinzip entworfen, das es Administratoren auch in komplexen Umgebungen erlauben soll, Berechtigungen auf Ressourcen strukturiert und effizient zu verwalten. Dabei orientiert sich Windows an einem rollenbasierten Zugriffsmodell (und zwar schon seit 1993 – viele andere Hersteller haben dieses Modell erst vor Kurzem für sich entdeckt).

Das Prinzip ist bekannt als das “A-G-DL-P-Prinzip”:

• Accounts (Benutzerkonten)
• go in Global Groups (Globale Gruppen)
• nested in Domain Local Groups (Domänenlokale Gruppen)
• that are granted Permissions (Berechtigungen)

Das Konzept wird oft missverstanden, daher soll ein Beispiel helfen.

Das A-G-DL-P-Prinzip der Gruppen- und Rechteverwaltung

• Links finden sich die Accounts der Anwender. Diese sind nach logischen Kriterien in Globalen Gruppen zusammengefasst, die hier die Zugehörigkeit zu einer Abteilung, aber auch die Funktion in einem bestimmten Projekt widerspiegeln.
• Ganz rechts finden sich die Ressourcen, für die die Zugriffsrechte verwaltet werden sollen: Die CRM-Datenbank (Zugriff erforderlich für den Vertrieb), ein Drucker (Zugriff für alle möglich) und eine bestimmte Projekt-Datei (Leserechte für die Technik und voller Zugriff für die Projektleitung).
• Der Kniff ist nun: Die DL-Gruppen erzeugt man passend zu den jeweiligen Zugriffsrechten, idealerweise mit sprechenden Namen. Da es für die CRM-Datenbank und den Drucker in diesem Fall nur jeweils ein unterschiedenes Recht gibt, reicht jeweils eine Gruppe aus. Für die Projektdatei sind aber zwei Zugriffsarten zu unterscheiden, daher gibt es für jedes Recht eine eigene Gruppe.
• Nur diese DL-Gruppen erhalten nun die passenden Berechtigungen. Die Berechtigungsliste (ACL) bleibt dadurch sehr kurz und muss nach diesem Konzept nie wieder verändert werden.
• Als Letztes erfolgt die Zuweisung der Globalen Gruppen zu den jeweiligen Domänenlokalen Gruppen, und zwar abhängig davon, welches Zugriffsrecht die Gruppe haben soll.

Ein noch deutlicheres Beispiel aus der Praxis: Eine komplexere Applikation (nennen wir sie “App-L”) soll für den Zugriff auf einem Terminalserver mit Berechtigungen versehen werden. Zu der Applikation gehören die Programmdateien, eine Datenbank und eine Freigabe auf einem Dateiserver. Die Mitglieder des Vetriebs und des Vorstands sollen diese Applikation nutzen können.

• Zunächst richtet man eine Domänenlokale Gruppe für die Zugriffsberechtigungen ein. Nennen wir sie “DL-App-L-Benutzer”.
• Diese Gruppe (und nur diese!) erhält die Lese- und Ausführungsberechtigung für die Programmdateien auf dem Terminalserver. Ebenso erhält diese Gruppe Zugriffsrechte für die Datenbank und für die Dateifreigabe.
  
  Mit diesem Schritt sind alle Berechtigungen vollständig und endgültig bearbeitet!
• In die Gruppe “DL-App-L-Benutzer” nimmt man nun die beiden Globalen Gruppen “G-Vertrieb” und “G-Vorstand” auf.

Aufgrund dieses Modells haben künftig alle Mitglieder der Gruppen “G-Vertrieb” oder “G-Vorstand” die nötigen Rechte, um mit der Applikation “App-L” zu arbeiten. Die Berechtigungen muss man nun nie wieder anpassen, auch wenn neue Vertriebsmitarbeiter hinzukommen oder Vorstandsmitglieder das Unternehmen verlassen: Es reicht aus, die Mitgliedschaft in den beiden Globalen Gruppen zu pflegen.

Best Practice und Grenzen

Die Gruppen- und Berechtigungsverwaltung nach dem A-G-DL-P-Prinzip erfordert umfangreiche Analyse und Planung. Wer sie aber beherzigt, wird mit einem sehr gut wartbaren Berechtigungskonzept belohnt, das darüber hinaus sehr einfach zu dokumentieren ist. Zumindest für zentrale und komplexe Ressourcen ist die Anwendung dieses Modells sehr zu empfehlen. Auch in Migrationen hat sich das Prinzip sehr bewährt, weil es nur wenige Änderungen erfordert, wenn sich Systeme oder Domänen mal ändern.

In der Alltagsadministration gibt es oft “sofortige” Zugriffs-Anforderungen, die sich nach dem Konzept nicht schnell umsetzen lassen. Wo man hier die Grenze zieht, muss man selbst entscheiden. Die Erfahrung zeigt aber, dass die Ad-hoc-Verwaltung sehr schnell zu einem ausufernden Geflecht von Berechtigungen führt, das kaum noch nachvollziehbar ist.

Ein Nachteil des Konzepts tritt in sehr großen Umgebungen zutage, denn dort führt es schnell zu einer sehr großen Zahl von Gruppen und von Gruppenmitgliedschaften. Da das Access Token in seiner Größe begrenzt ist, kann ein Benutzer nicht gleichzeitig in mehr als ca. 1015 Gruppen Mitglied sein (vgl. Knowledge-Base-Artikel 328889). Hier können Variationen des Konzepts evtl. helfen. Eine andere Methode in solchen Umgebungen besteht darin, eigene Domänen für Anwender- und Ressourcenobjekte zu erzeugen. In diesem Fall “leben” die Domänenlokalen Gruppen in der Ressourcen-Domäne und blähen das Access Token innerhalb der Anwenderdomäne nicht über Gebühr auf.

Verwandte Beiträge:

1. In welchen AD-Gruppen ist ein Benutzer Mitglied?
   Unsere FAQ bietet ein paar Artikel, die die Mitglieder von...
2. Was man über E-Mail-aktivierte Gruppen wissen sollte
   E-Mail-aktivierte Gruppen könnten unter Exchange sowohl von intern als auch...
3. NTFS-Platten mit NT4 und Windows 2003 nutzen
   Aus einer aktuellen Situation in einem Migrationsprojekt habe ich getestet,...