Inhaltsverzeichnis > ObjektAttribute: Deep Inside > Active Directory Berechtigungen : Security Descriptors

Active Directory Berechtigungen : Security Descriptors

In diesem Artikel des SelfADSI Tutorial wird erkl?rt, wie man per Script Berechtigungen auf Active Directory Objekte ausliest oder setzt. Folgende Abschnitte stehen zur Verfügung:

Berechtigungen im Active Directory werden durch so genannte Security Descriptoren definiert, die als Eigenschaften bei den Objekten selbst abgespeichert werden. Zwei Active Directory Attribute sind intern als Security Descriptor aufgebaut:

Der grundlegende LDAP Attribut-Datentyp für derartige Attribute ist eine Microsoft-proprietäre LDAP Attribut Syntax, die String(NT-Sec-Desc) genannt wird - grundsätzlich handelt es sich dabei um binäre Daten, jedoch kann auf den Inhalt eines Security Descriptors von Scripts aus zum Glück durch die ADSI-Schnittstellezugegriffen werden. Die entsprechenden Objekte werden in der ADSI Referen genau beschrieben:

• ADSI Referenz : Security Interfaces

Doch bevor wir uns mit dem Auslesen und Setzen von Berechtigungen im Active Directory durch Scripting besch?ftigen, sollten wir einen Blick auf die internen Strukturen eines Security Descriptors werfen. Der genau allgemeine Aufbau eines Security Descriptor Wertes wird in diesen Microsoft Dokumenten beschrieben:

• Microsoft Data Type Reference [MSDTY]
• Technet : How Security Descriptors and Access Control Lists Work

Hinweis: Security Descriptor Strukturen findet man nicht nur bei den Berechtigungen f?r Verzeichnisobjekte, sondern auch bei Rechten im NTFS Filesystem, bei Registry-Rechten und ?berhaupt bei allen Berechtigungen auf Systemobjekte (Dienste, Drucker usw.). Dieser Artikel konzentriert sich jedoch auf die Besonderheiten der Rechte im Active Directory, dies betrifft vor allem den Aufbau von ACEs und von Access Masks.

Der interne Aufbau eines Security Descriptors (SD)

Die interne Struktur eines Security Descriptors ist ziemlich komplex, weil wir verschiedene Elemente beachten müssen, die ineinander verschachtelt sind: Der Security Descriptor als Ganzes besteht aus einem Header, den Owner-Informationen, und aus zwei verschiedenen Acces Lists (ACLs). Von diesen ACLs sind die eigentlichen Berechtigungen in der Discretionary ACL (DACL) enthalten, dieses wiederum besteht aus einzelnen Access Control Entries (ACEs). Von diesen ACEs gibt es viele verschiedene Typen, von denen für uns vier relevant sind.

Bei der Erstellung von Scripts bedeutet das Folgendes: Will ein Script die Rechte eines Active Directory Objektes auslesen, so muss es zuerst den Security Descirptor und die darin enthaltene DACL lesen, um an die Liste der ACEs zu kommen. In diesem ACEs stehen die konktreten Berechtigungen. Wenn man Rechte setzen will, so wird man selten einen Security Descriptor aus dem nichts heraus selbst aufbauen m?ssen - es gibt schlie?lich kein AD Objekt, dass nicht bereits mit Berechtigungen konfiguriert ist. Sofort nach der ergeben sich die Berechtigungen automatisch aus der Vererbung den den Voreinstellungen. Rechte zu vergeben oder wegzunehmen beruht also in Scripts stets auf der Ver?nderung der Liste der ACEs.

Betrachten wir zun?chst den Security Descriptor mit seinem Aufbau aus Header, Owner-Information und ACLs. Wie schon oben erw?hnt findet man eine genaue Beschreibung des technischen Aufbaus eines Security Descriptors im Microsoft Technet:

• Microsoft Data Type Reference [MSDTY] : Security Descriptor

Header: Eine Struktur, die eine allgemeine Revisionsnummer beinhaltet sowie verschiedene Control Bits. Diese Flags geben Auskunft dar?ber wie und aus welchen Bestandteilen der betreffende Security Descriptor zusammengesetzt ist - oder zusammengesetzt wird, falls man mit der Struktur gerade einen neuen Secruity Descriptor erzeugen will. Au?erdem bestimmen die Control Flags, ob die Berechtigungen und Audit-einstellungen von dar?ber liegenden Strukturen vererbt wurden, oder ob die Vererbung bei diesem Security Descriptor unterbrochen wird. Ansonsten sind im Header rein technisch noch Offset-Adressen enthalten, damit klar ist, an welcher Byte-Stelle die anderen Security Descriptor Bestandteile beginnen.

Owner: Der Objekt Owner - technisch in Form einer SID (Security Identifier). Der Owner ist derjenige Benutzer-Account, der das betreffende Objekt erzeugt hat. Der Owner darf stets die Berechtigungen auf das Objekt ?ndern. Eine Besonderheit: Erstellt ein Mitglied der vordefinierten Gruppe der Administratoren ein Objekt, so wird als Owner diese Gruppe eingetragen. Beim Setzen des Feldes im eigenen Script kann man übrigens auch direkt einen Windows-Anmeldenamen verwenden, z.B. "SELFADSI\pfoeckel".

Owner Group: Die Gruppe des Objekt Owners - technisch in Form einer SID (Security Identifier). Die Owner Group wird in der Praxis selten verwendet, meist spielt lediglich der Owner eine Rolle - Die Owner Group ist dann einfach die Prim?re Gruppe des Owners.

SACL - System Access Control List: Die SACL ist die Liste, in der die Auditing-Einstellungen des betreffenden Objektes gespeichert werden (Welche Zugriffe von wem werden wie ?berwacht?). Nur wer ?ber das Richtlinien-Privileg "Manage Auditing and Security Log" auf den Dom?nencontrollern verf?gt, kann die SACL  lesen oder schreiben. Bedenken Sie auch, dass es dar?ber hinaus immer noch globale Audit-Flags gibt, die f?r das Directory Service Auditing auf einem Dom?nencontroller aktiv sein m?ssen (wird ?ber GPO gesteuert).

DACL - Discretionary Access Control List: Die DACL enth?lt die Zugriffsberechtigungen auf ein Objekt (Wer darf was machen?). Dies ist die eigentlich Rechteliste. Ver?ndert werden darf sie stets vom Owner des Objektes und von allen, die die Berechtigung WRITE_DAC (siehe Liste der Access Masks Bits) auf das Objekt haben. Zum Auslesen der Discrentionary Access Control reicht die Berechtigung READ_CONTROL.

Access Control Lists (ACLs)

Eine Access List (egal ob System ACL f?r das Auditing oder eine Discretionary ACL f?r die Berechtigungen) besteht immer aus einem Header und beliebig vielen Acces Control Entries (ACEs). Der genaue technische Aufbau einer ACL wird hier beschrieben:

• Microsoft Data Type Reference [MSDTY] : ACL

Zu beachten ist, dass der Revisions-Wert bei einer Active Directory ACL stets 4 sein muss. Die ACEs sind dann sozusagen die einzelnen Berechtigungen, die wir in der normalen administrativen Verwaltung sehen:

Access Control Entries (ACEs)

Ein ACE ist die Festlegung einer einzelnen Berechtigung (oder Rechte-Verweigerung) f?r einen bestimmten Benutzer oder eine bestimmte Gruppe. Es gibt eine Menge unterschiedlicher Typen von ACEs, wobei f?r Active Directory Berechtigungen nur vier verschiedene Typen von Bedeutung sind, jeweils zwei f?r die Vergabe und die Verweigerung von Rechten. Der genaue technische Aufbau eines ACEs wird hier beschrieben:

• Microsoft Data Type Reference [MSDTY] : ACE

Es existiert hier eine einfache ACE-Form, bei der Rechte auf das gesamte Obekt vergeben/entzogen werden inklusive Standard-Vererbung. Es gibt dann noch die komplexere Form des so genannten Object ACEs. In folgenden F?llen reicht n?mlich die einfache Form eine ACEs nicht aus:

• Rechte gelten nicht f?r das gesamte Objekt, sondern nur f?r ein bestimmtes Attribut oder eine Gruppe von Attributen (z.B. Schreibrechte auf die Adress-Informationen eines Benutzerobjektes).
• Bei Berechtigung zum Erstellen / L?schen von Sub-Objekten betrifft dies nur ganz bestimmte Klassen (z.B. das Recht, untergeordnete Gruppen zu erstellen).
• Spezielle Berechtigungen m?ssen vergeben werden, die zum Teil auch spezifisch f?r andere Applikationen sind, z.B. das Recht, User-Passw?rter zur?ckzusetzen, oder das Recht, im Auftrag eines anderen Benutzers Mail zu senden, oder das Recht, eine AD-Datenreplikation herbeizuf?hren.
• Rechte m?ssen vergeben werden, die einen Selbstbezug zum Objekt herstellen, z.B. das Recht, sich selbst in eine Gruppe als Mitglied aufzunehmen.

Die vier f?r uns relevanten ACE-Typen im Detail:

Access Allowed ACE:

Bei diesem ACE ist der Typ immer auf 1 zu setzen. Er ist gedacht f?r einfache Rechtevergabe auf das gesamte Objekt. Die ACE Flags bestimmen, ob es sich hierbei um ein vererbtes Recht oder ein explizit vergebenes Recht handelt. Ein Berechtigung des ACE Types 0 wird stets auf untergeordnete Objekte weitervererbt.


Access Allowed Object ACE:

Bei diesem ACE ist der Typ immer auf 5 zu setzen. In diesem Object ACE k?nnen sowohl spezielle Rechte oder eingeschr?nkte Rechte z.B. nur f?r bestimmte Attribute vergeben werden (=> Object Type GUID) als auch eine spezielle Vererbung konfiguriert werden, so dass nur bestimmte Objektklassen diese Recht erben, oder dass das Recht nur auf das Objekt selbst gilt und nicht weiter vererbt wird (=> Interhited Type GUID). Das Flags-Feld gibt an, ob ein Object Type oder ein Inherited Type oder beides im ACE vorkommt.


Access Denied ACE:

Bei diesem ACE ist der Typ immer auf 1 zu setzen. Er ist gedacht f?r einfache Rechteverweigerungen auf das gesamte Objekt. Die ACE Flags bestimmen, ob es sich hierbei um einen vererbten Eintrag oder eine explizit vergebene Verweigerung handelt. Ein Verweigerung des ACE Typs 5 wird stets auf untergeordnete Objekte weitervererbt.

Access Denied Object ACE:

Bei diesem ACE ist der Typ immer auf 6 zu setzen. In diesem Object ACE k?nnen sowohl spezielle Rechte oder eingeschr?nkte Rechte z.B. nur f?r bestimmte Attribute verweigert werden (=> Object Type GUID) als auch eine spezielle Verweigerungen konfiguriert werden, so dass nur bestimmte Objektklassen diesen Eintrag erben, oder dass der Eintrag nur auf das Objekt selbst gilt und nicht weiter vererbt wird (=> Interhited Type GUID). Das Flags-Feld gibt an, ob ein Object Type oder ein Inherited Type oder beides im ACE vorkommt.

Control Flags im SD Header

Der Header eines Security Descriptors enthält die so genannten Control Flags. Viele der Flags spielen beim Umgang mit normalen Active Directory Berechtigungen keine Rolle. Der genaue Aufbau der Control Flags wird hier beschrieben:

• Microsoft Data Type Reference [MSDTY] : Security Descriptor

Wenn man einen Security Descriptor liest, dann spielen folgende Flags eine Rolle

Wenn man einen Security Descriptor schreibt oder neu erzeugt, dann spielen folgende Flags eine Rolle

Flags innerhalb von ACEs

Die hier beschriebenen Flags kommen je einmal pro Access Control Entry vor, es kann innerhalb des gesamten Security Descriptors also viele Vorkommnisse geben. Vorsicht, Verwechslungsgefahr: In ACEs kommen zwei Arten von Flags vor: Die "ACE Flags" und die "Flags". Sie steuern die Vererbungseinstellungen des betreffenden ACEs und aktivieren die im ACE evtl. vorhandenen Object Type Felder.

In jedem ACE gibt es die "ACE Flags", die Teil des technischen ACE Headers sind. Sie bestimmen die Art der Vererbung bei neuen ACEs oder geben die Situation der Vererbung wieder, wenn man den betreffenden ACE ausliest.

Es gibt dar?ber hinaus noch weitere Flag-Werte, die jedoch entweder in Active Directory ACLs nicht vorkommen, oder nicht f?r Berechtigungen, sondern f?r die Audit-Einstellungen in der SACL wichtig sind. Eine komplette Dokumentation der Flags finden Sie hier:

• Microsoft Data Type Reference [MSDTY] : ACE Flags
• Microsoft ADSI Reference : ADS_ACEFLAG_ENUM

Das Weitergeben der Berechtigung an untergeordnete Objekte kann bei den komplexeren Object ACEs (ACE Typ 5 und 6) noch genauer angegeben werden. Es kann also festgelegt werden, dass ein Recht z.B. nur auf untergeordnete Benutzer-Objekte gelten soll, oder nur auf Gruppen. Dazu muss in den entsprechenden ACEs das Feld "Inherited Type" gesetzt sein. Ob dies der Fall ist, sieht man im so genannten "Flags" Feld:

Eine komplette Dokumentation der Flags finden Sie hier:

• Microsoft ADSI Reference : ADS_FLAGTYPE_ENUM

Liste der Berechtigungen - Access Mask Bits innerhalb von ACEs

Dies ist eine Liste der Berechtigungen auf Active Directory Verzeichnisobjekte, so wie sie in den oben beschriebenen Access Control Entries vorkommen oder gesetzt werden k?nnen. In manchen Access Masks k?nnen verschiedene Bits gleichzeitig gesetzt sein, z.B. kann in einem einzigen ACE festgelegt werden, dass jemand die Berechtigung hat, User-Objekte sowohl zu erstellen als auch zu l?schen (CC + DC). Es gibt jedoch auch offensichtliche Beschr?nkungen, denn in einem einzigen Objekt-ACE ist Platz f?r genau eine Object Type GUID, es ist also z.B. nicht m?glich das Recht zum L?schen von User-Objekten und zum Schreiben der Adresseigenschaften im gleichen ACE unterzubringen.

Die technische Beschreibung der Access Mask Bits bei Microsoft:

• Microsoft Data Type Reference [MSDTY] : Access Mask
• Microsoft ADSI Reference : ADS_RIGHTS_ENUM

Object Type GUIDs innerhalb von ACEs

In komplexen ACEs des Typs 5 und 6 gibt es das Feld "Object Type GUID". Es kann drei Fälle geben bei denen diese Feld verwendet wird. Dabei muss dann das Flag OBJECT_TYPE_PRESENT (1) im betreffenden Access Control Entry gesetzt sein. Die GUID wird hier ürbigens einfach als String ausgelesen und gesetzt.

• Bei CC / DC Berechtigungen (Create Child / Delete Child) kann hier die Objektart angegeben werden. Im Object Type Feld steht dann die GUID einer Objektklasse aus dem AD Schema (SchemaIDGuid in der Klassendefinition des Schemas). Wichtige GUIDs wären hier:
  
  

  Objektklasse	GUID
  Organizational Units	bf967aa5-0de6-11d0-a285-00aa003049e2
  Computer	bf967a86-0de6-11d0-a285-00aa003049e2
  User	bf967aba-0de6-11d0-a285-00aa003049e2
  Gruppen	bf967a9c-0de6-11d0-a285-00aa003049e2
  Kontakte	5cb41ed0-0e4c-11d0-a286-00aa003049e2

  
  
  
• Bei RP / WP Berechtigung (Read Property / Write Property) kann hier das Attribut oder das Propertyset angegeben werden, auf das sich das Recht bezieht. Im Object Type Feld steht dann die GUID eines Attributes aus dem Schema oder ie GUID eines Protperty Sets aus der Config Partition (Container "Extended-Rights"). Einige Beispiele für Attribut-GUIDs:
  
  

  Attribut	GUID
  department	bf96794f-0de6-11d0-a285-00aa003049e2
  description	bf967950-0de6-11d0-a285-00aa003049e2
  displayName	bf967953-0de6-11d0-a285-00aa003049e2
  givenName	f0f8ff8e-1191-11d0-a060-00aa006c33ed
  mail	bf967961-0de6-11d0-a285-00aa003049e2
  member	bf9679c0-0de6-11d0-a285-00aa003049e2
  physicalDeliveryOfficeName	bf9679f7-0de6-11d0-a285-00aa003049e2
  proxyAddresses	bf967a06-0de6-11d0-a285-00aa003049e2
  sn	bf967a41-0de6-11d0-a285-00aa003049e2
  telephoneNumber	bf967a49-0de6-11d0-a285-00aa003049e2

  
  
  Einige Beispiele für Property Set GUIDs:
  
  

  Property Set	GUID
  General Information	59ba2f42-79a2-11d0-9020-00c04fc2d3cf
  Personal Information	77b5b886-944a-11d1-aebd-0000f80367c1
  Private Information	91e647de-d96f-4b70-9557-d63ff4f3ccd8
  Public Information	e48d0154-bcf8-11d1-8702-00c04fb96050

  
  
• Bei erweiterten CA Rechten (Control Access) kann hier das konkrete Recht festgelegt werden. Im Object Type Feld steht dann die GUID eines erweiterten Rechtes aus der Config Partition (Container "Extended-Rights"). Einige Beispiele für Extended Right GUIDs:
  
  

  Extended Right	GUID
  Administer Exchange information store	d74a8762-22b9-11d3-aa62-00c04f8eedd8
  Create Inbound Forest Trust	e2a36dc9-ae17-47c3-b58b-be34c55ba633
  Change Password	ab721a53-1e2f-11d0-9819-00aa0040529b
  Migrate SID History	ba33815a-4f93-4c76-87f3-57574bff8109
  Reanimate Tombstones	45ec5156-db7e-47bb-b53f-dbeb2d03c40f
  Receive As	ab721a56-1e2f-11d0-9819-00aa0040529b
  Replication Synchronization	1131f6ab-9c07-11d1-f79f-00c04fc2dcd2
  Reset Password	00299570-246d-11d0-a768-00aa006e0529
  Send As	ab721a54-1e2f-11d0-9819-00aa0040529b
  Unexpire Password	ccc2dc7d-a6ad-4a7a-8846-c04e3cc53501
  View Exchange information store status	d74a875e-22b9-11d3-aa62-00c04f8eedd8

Inherited Type GUIDs innerhalb von ACEs

In komplexen ACEs des Typs 5 und 6 gibt es ds Feld "Inherited Object Type GUID". Es kann benutzt werden, um die Berechtigung nur auf spezielle Objektklassen zu vererben (z.B. "Der Displayname darf verändert werden, aber nur bei Gruppen!"). Dabei muss dann das Flag INHERITED_OBJECT_TYPE_PRESENT (2) im betreffenden Access Control Entry gesetzt sein. Im Inherited Object Type Feld steht dann die GUID einer Objektklasse aus dem AD Schema (SchemaIDGuid in der Klassendefinition des Schemas). Die GUID wird hier ürbigens einfach als String ausgelesen und gesetzt. Wichtige GUIDs wären hier:

Trustees innerhalb von ACEs

In Access Control Entries (ACEs) ist stets auch der Trustee aufgeführt, das bedeutet der Account oder die Gruppe, für die Berechtigungen gewährt oder entzogen werden. Beim Setzen und Auslesen von Trustees können zwei Erscheinungsformen vorkommen:

• Wenn Sie ein Script zum Setzen oder Auslesen von Berechtigungen in der gleichen Active Directory Domäne ausführen, dann werden Trustees einfach in der NetBIOS-Schreibweise "DOMÄNE\Benutzername" oder "Domäne\Gruppenname" angegeben.
  
  
• Wenn Sie mit Ihrem Script nicht automatisch in der Domäne angemeldet sind, sondern explizite Credentials verwenden müssen, dann werden Trustees als technische Security Identifier (SIDs) angegeben, z.B. "S-1-5-21-1621763826-2590103247-2238570322-1113". Sie müssen dann natürlich wissen, wie man die SID z.B. für einen Benutzer oder eine Gruppe ermitteln kann.

Über den Aufbau von Microsoft SIDs und den Umgang damit handelt ein ausführlicher Tutorial-Artikel: "Microsoft Security Identifier (SID) Attribute".

Rechtevererbung

Bei der Vererbung der Berechtigungen für Active Directory Objekte gibt es verschiedene interessante Aspekte:

1. Man möchte vielleicht per Script herausfinden, ob für ein Objekt die Vererbung von oben herab grundsätzlich deaktiviert/blockiert wurde. Dazu muss man einfach prüfen, ob das DACL_PROTECTED Bit in den ControlFlags des gesamten Security Descriptors gesetzt ist.
   
   
2. Man möchte vielleicht per Script für eine einzelene bestehende Berechtigung herausfinden, ob diese von oben herab vererbt oder explizit gesetzt wurde. Dazu überprüfen Sie im betreffenden Access Control Entry, ob dort das INHERITED_ACE Flag in den ACEFlags gesetzt ist.
   
   
3. Wenn man selbst neue Berechtigungen per Script setzt, möchte man bestimmen, ob und wie diese Berechtigung auf untergeordnete Objekte vererbt wird. Eine große Rolle spielen hierbei die Flags innerhalb der von Ihnen erzeugten ACEs. Dazu können Sie diese Matrix verwenden:
   
   
   

Active Directory Berechtigungen auslesen im Script

Hier ein Beispiel wie man die Berechtigung für ein einzelnes Objekt im Active Directory ausliest. Dazu wird das LDAP-Attribut nTSecurityDesriptor gelesen und ausgewertet:

Download Script

Kompliziert wird das Ganze, wenn man eine genaue Auswertung der Berechtigungen und der Vererbung nach unten haben will. Das Script muss dafür nämlich die entprechenden GUIDs im Schema oder der Config Partition suchen und auswerten. Man beachte deswegen die beiden Functions decode_permission und decode_propagation.

Das Script muss auf einem Rechner der Domäne als Administrator ausgeführt werden.

Download Script

Active Directory Berechtigungen setzen im Script

Hier ein Beispiel wie man die Berechtigung für ein einzelnes Objekt im Active Directory vergibt. Man liest für diesen Zweck das Attribut nTSecurityDesriptor aus und verändert dann die drin enthaltene DAC, indem man neue Access Control Entries hinzufügt. Später wird das gesamte Attribut wieder zurückgeschrieben.

Ein Trustee (also ein Benutzer oder eine Gruppe des gleichen AD Forests) bekommt Berechtigungen auf eine OU:

• Löschen der OU (betrifft aber nur die OU selbst, diee müßte also leer sein...)
• Schreibrechte auf das Feld "Description" aller Objekte dieser OU
• Passwort zurücksetzen für Benutzer-Objekte der OU

Man beachte hierbei die entsprechenden ACE-Flags und Object GUIDs, die für diesen Zweck verwendet werden. Das Script muss auf einem Rechner der Domäne als Administrator ausgeführt werden:

Download Script

Active Directory Berechtigungen entfernen im Script

Hier ein Beispiel wie man die Berechtigung für ein einzelnes Objekt im Active Directory entfernt. Man liest für diesen Zweck das Attribut nTSecurityDesriptor aus. Man liest aus der darin enthaltenen Discretionary Access Control List (DACL) alle ACEs aus, die nicht von oben vererbt werden, und die nicht dem Trustee zugeordnet sind, den man aus der Rechteliste entfernen will. Aus diesen ACEs baut man dann eine neue DACL zusammen. Bei Zurückschreiben des gesamten Attributes kommen dann die von oben vererbten Berechtigungen wieder automatisch dazu.

Download Script