Langsam aber sicher werden nun die letzten NT-Domänen in den Unternehmen zu einer Active Directory Umgebung migriert.
Die Administratoren die bereits seit längerem eine Active Directory Umgebung betreuen, haben sich bereits einiges an Wissen
die sie für eine Administration einer Active Directory-Domäne benötigen aufgebaut und andere wiederum, werden es noch tun.
In den Unternehmen die bereits seit längerem eine Active Directory Umgebung besitzen, wird langsam aber sicher der Ruf nach
gezielter Vergabe von Berechtigungen im Active Directory lauter und stärker. Gerade wenn Unternehmen fusionieren bzw. seit Jahren
stetig gewachsen sind, ist es zwingend notwendig gezielte Berechtigungen den Benutzern zu vergeben.
Im täglichen Leben des Administrators fallen viele Aufgaben an, die er möglichst zeitnah und zielgerecht auszuführen hat. Dabei hat er
bei der Ausführung seiner Aufgaben stets darauf zu achten, dass die Benutzer oder die IT-Support-Einheiten nur die Rechte in einem
Netzwerk erhalten, die sie für ihre Arbeit benötigen. Denn wenn Personen zu viele Rechte besitzen, kann das durchaus bedeuten das
im Endeffekt der Administrator dadurch einen unnötigen Mehraufwand hat. Daher lautet die Devise für den Administrator, nur soviel Rechte
zu vergeben wie sie auch tatsächlich benötigt werden, auch wenn das im ersten Moment mehr Arbeit für den Administrator bedeutet,
anstelle den Benutzer einfach in eine administrative Gruppe zu stecken und somit ggf. zuviele Rechte zu vergeben.
Eine weitere Grundregel wäre dabei, alle Benutzer die eine gleiche Anforderung haben (z.B. den Zugriff auf eine Ressource),
zu einer Sicherheitsgruppe hinzuzufügen und dieser Gruppe den Zugriff auf die Ressource zu gewähren, anstatt jedem einzelnen Benutzer
die Rechte auf die Ressource zu erteilen. Dabei hat sich das A-G-DL-P Prinzip etabliert. Oder anstelle den einzelnen Mitarbeitern aus dem
First-Level Support Domänen-Administrator Rechte zu geben, sollten die benötigten Rechte im Active Directory über die Objektverwaltung
oder mit dem Kommandozeilentool DSACLS entsprechend delegiert werden. Dabei ist es empfehlenswert, auch hier idealerweise einer
Sicherheitsgruppe die Rechte im Active Directory zu delegieren und nicht einzelnen Personen.
Damit ein Administrator das richtige Delegierungskonzept für seine Active Directory Gesamtstruktur erarbeiten kann,
muss er sich dessen bewußt sein, was technisch möglich ist und was nicht. Er sollte dabei auch die Hintergründe kennen.
Was passiert nun im Hintergrund, wenn einem Benutzer oder einer Sicherheitsgruppe Rechte im Active Directory durch die
Objektverwaltung oder durch das Kommandozeilentool DSACLS delegiert werden? Und woher weiß das Active Directory,
das der Benutzer der eine Aufgabe durchführen möchte, das auch darf?
Um diese Fragen zu beantworten, müssen in diesem Zusammenhang die Begriffe SID,
Access Token, ACL, ACE, SD, DACL, SACL und SDDL erläutert werden.
Security Identifier (SID)
Jedes Sicherheitsprinzipal wie Benutzer, Gruppen, Computer usw. erhalten beim erstellen in einer Active Directory-Umgebung
oder auch lokal, eine einmalige Objekt-GUID sowie Objekt-SID. Der Security Identifier (zu deutsch, Identifikationsnummer),
der Teil des security descriptors ist, dient zur eindeutigen Kennzeichnug eines Objekts (z.B. eines Benutzers). Der leserfreundliche Name
eines Sicherheitsprinzipal ist eher für den Menschen gedacht, da er sich Namen einfacher merken kann, als eine Zahlenkombination.
Jede Berechtigung die einem Benutzerkonto für den Zugriff auf Objekte bzw. Ressourcen zugewiesen wird, werden vom
Windows-Betriebsystem immer direkt der SID zugewiesen. Oder werden einem Benutzer Aufgaben im Active Directory delegiert,
werden die Berechtigungen ebenfalls direkt der SID zugewiesen.
Wird der Benutzer in eine andere Domäne verschoben, so ändert sich seine SID.
Denn in der SID ist auch die betreffende Domäne hinterlegt. Ein SID ist ein Zahlen-Array mit einer variablen Länge,
das sich wie folgt zusammensetzt:
S-1-5-21-956547467-2769573453-2154042951-500
S = SID
1 = Die Revisionsnummer
5 = Identifier Authority
21 = Typisierung des nachfolgenden SID-Teils
956547467-2769573453-2154042951 = Domäne
500 = Benutzer (in diesem Beispiel, der Administrator)
Access Token
Wenn ein Sicherheitsprinzipal (security principal) wie es ein Benutzer darstellt, seinen Benutzernamen sowie das Kennwort im
Logon-Fenster an einem Client eingibt, werden diese Anmeldeinformationen an einen Domänencontroller (DC), den der Client
durch das DNS mitgeteilt bekommt, übermittelt. Der DC überprüft ob das richtige Kennwort passend zum Benutzernamen
eingegeben wurde. Falls dies der Fall sein sollte, erstellt der DC während dem Anmeldeprozess ein Access Token und falls nicht,
erhält der Benutzer eine Fehlermeldung das der Benutzername oder das Kennwort falsch sei. Das Token wird dabei vom
Local Security Authority (LSA) Prozess des DCs erstellt. Das Access Token enthält Informationen über die
Identität und Privilegien des Sicherheitsprinzipal. In dem Access Token sind die folgenden SIDs und Informationen enthalten:
-
Die SID des Benutzers (der Benutzername sAMAccountName oder UPN ist Schall und Rauch für die Systeme,
viel wichtiger ist die SID die dahintersteckt).
-
Falls vorhanden, die SID-History des Benutzers (von Migrationen).
-
Die SIDs von jeder domänenlokalen Gruppe, worin der Benutzer direkt oder transitiv Mitglied ist.
-
Die SIDs jeder gloablen Gruppe, in denen der Benutzer direkt sowie verschachtelt Mitglied ist und die SID-History der globalen Gruppen.
-
Die SIDs der universellen Gruppen in denen der Benutzer direkt sowie verschachtelt Mitglied ist, samt der SID-History
der universellen Gruppen. Dabei werden die Informationen zu den universellen Gruppenmitgliedschaften des Benutzers,
vom globalen Katalog (GC) geliefert.
-
Die SIDs von jeder BuiltIn Gruppe, in der der Benutzer direkt oder transitiv Mitglied ist.
-
Die SIDs von jeder lokalen Gruppen, in der der Benutzer direkt oder transitiv Mitglied ist.
-
Eine Liste mit Privilegien.
-
Andere Zugriffsinformationen.
Das Access Token hat allerdings eine Beschränkung. In einem Token für einen Sicherheitsprinzipal können maximal
1.024 Einträge enthalten sein. Daher sollte unbedingt darauf geachtet werden, das gerade wenn Benutzerkonten
über Jahre hinweg existieren und diese bereits mehrere Migrationen hinter sich haben, unbedingt die SID-History
nach jeder Migration zu bereinigen [1]. Sonst kann das später zu Problemen führen.
Bekommt der Benutzer bei der Windows-Anmeldung folgenden Fehler:
The system cannot log you on due to the following error:
During a logon attempt, the user`s security context accumulated too many security IDs
so liegt der Fehler darin, dass der Benutzer in zu vielen Gruppen enthalten ist oder die SID-History zu viele Einträge enthält.
Welche SIDs in dem Access Token enthalten sind, kann man sich mit dem Kommandozeilentool Whoami anzeigen lassen.
Der Befehl dazu lautet Whoami /All.
Wichtig ist zu wissen, dass Access Token wird nur ein einziges Mal und zwar während der Benutzeranmeldung erstellt.
Wird nun der Benutzer während seiner Benutzersitzung zu weiteren Gruppen hinzugefügt und es zeigt sich, dass der Benutzer
weiterhin auf die neue Ressource keinen Zugriff erhält, so sollte sich der Benutzer erneut anmelden, damit die neuen
Gruppeninformationen und somit die neuen Berechtigunen im Token enthalten sind.
Das Access Token in dem alle SIDs des Benutzers enthalten sind, ist quasi der Ausweis eines Benutzers im Netzwerk.
Jedes Objekt bzw. jede Ressource enthält auf der anderen Seite eine Zugriffskontrollliste (Access Control List, ACL).
Zu sehen ist die Zugriffskontrollliste in den Eigenschaften eines Objekts, im Reiter Sicherheit. In der Zugriffskontrollliste
eines Objekts stehen die SIDs (in Form von Namen) der zugriffsberechtigten Personen drin. Darin sind die Benutzer oder Gruppen
mit ihren entsprechenden Zugriffsrechten enthalten. Möchte nun ein Benutzer auf ein Objekt zugreifen, überprüft das
Windows-Betriebssystem das Access Token des Benutzers, mit der Zugriffskontrollliste des Objekts. Findet sich eine SID
die im Token enthalten ist auch in der Zugriffskontrollliste des Objekts wieder, erhält der Benutzer Zugriff auf das Objekt,
mit seinen dort definierten Rechten.
[1] How To Use Visual Basic Script to Clear SidHistory
Access Token Limitation
Access Control List (ACL)
Die Access Control List (zu deutsch, Zugriffskontrollliste), zu der die beiden Typen DACL und SACL gehören,
besteht aus Access Control Entries Einträgen. Die beiden ACL-Typen DACL und SACL befinden sich im security descriptor des
Objekts und sind Bestandteil der ACL. Die ACL ist eine Liste von festgelegten ACEs die spezifizieren, ob und mit welchen Rechten
der Zugriff auf ein Objekt erlaubt, verweigert oder erfolgreich bzw. fehlgeschlagen überwacht wird. Die Zugriffskontrollliste die in
den Eigenschaften eines jeden Objekts - im Reiter Sicherheit - zu finden ist, steuert den Zugriff auf ein Objekt. Damit der Reiter
Sicherheit in den Eigenschaften eines Benutzerkontos erscheint, ist in der MMC „Active Directory-Benutzer und -Computer“ (ADBuC)
unter „Ansicht“ die Option „Erweiterte Funktionen“ zu aktivieren.
Der Aufbau einer ACL sieht wie folgt aus:
ACL Size
Hier wird die Größe des zugewiesenen Speichers für die ACL gespeichert. Die Größe des Speicherbedarfs hängt von der Anzahl und Größe
der jeweiligen ACEs ab. Dabei kann eine ACL maximal 64kb groß werden. Das würde etwa 1820 ACEs entsprechen, wobei die Anzahl der
ACEs wiederum abhängig von der Größe der ACEs ist. Aus Performancegründen sollte die ACL so klein wie möglich sein und nicht bis
an ihre maximale Grenze wachsen.
ACL Revision
In diesem Eintrag wird die Revisionsnummer für die Datenstruktur der ACL gespeichert.
ACE Count
An dieser Stelle wird die Anzahl an ACEs in der ACL angegeben. Ist als Wert Null eingetragen, bedeutet dies, dass die ACL
keine ACEs enthält - es ist leer. Wobei eine leere DACL sich von einer Null-DACL unterscheidet. Bei einer leeren DACL erhält keiner
einen Zugriff auf das Objekt, aber eine Null-DACL gibt jedem uneingeschränkten Zugriff auf das Objekt.
Daher sollte diese Einstellung vermieden werden.
ACE
Dieser Eintrag enthält eine Liste mit den ACEs. Möchte ein Benutzer auf ein Objekt zugreifen,
werden die ACEs in der Reihenfolge in der sie aufgelistet sind kontrolliert.
Access Control Entries (ACEs)
Die einzelnen ACEs im security descriptor eines Objekts, werden in den erweiterten Sicherheitseinstellungen eines Objekts
angezeigt und legen den Zugriff entweder auf das gesamte Objekt oder auf ein einzelnes Attribut fest. Durch ACEs können
Zugriffsrechte präzise, bis auf ein einzelnes Attribut vergeben werden. Somit kann z.B. einem Benutzer oder einer Gruppe lediglich
das Recht zum lesen für das Feld Beschreibung (Attribut Description) eines Objekts erteilt werden, aber nicht das Schreibrecht.
Ehe mit dem Bearbeiten oder Erstellen von ACEs begonnen wird, sollte sich vorher der Aufbau und die Funktionsweise des
ACEs näher angeschaut werden.
Der Aufbau eines ACEs sieht wie folgt aus:
Access Mask
In der AccessMask werden die Rechte definiert, wobei es für jeden Objekttyp unterschiedliche Rechte gibt. Hier können die
gewünschten Berechtigungen ausgewählt werden, wie z.B. Vollzugriff, alle Eigenschaften lesen und schreiben, Besitzer ändern usw.
oder die zu überwachenden Ereignisse konfiguriert werden. Durch die AccessMask werden zum einen die zu vergebenen
Berechtigungen und zum anderen, die zu überwachenden Ereignisse festgelegt, abhängig von der durchzuführenden Aufgabe.
AceType
An dieser Stelle können die entsprechenden Berechtigungen zugelassen bzw. verweigert werden (der Typ ist ACCESS_ALLOWED_ACE (0)
oder ACCESS_DENIED_ACE (1)) oder die erfolgreiche bzw. fehlgeschlagene Überwachung aktiviert werden
(der Typ lautet immer SYSTEM_AUDIT_ACE). Es wird also definiert, ob für ein Objekt oder für eine Eigenschaft
die Berechtigung oder Überwachung festgelegt werden soll.
Trustee
Im Trustee wird der Benutzer bzw. die Gruppe (das Ziel) festgelegt (genauer, die SID in Form des Namen),
für den die Berechtigung oder die Überwachung gelten soll.
Aceflags
Die Aceflags definieren die Vererbungsoptionen, je nachdem ob in der ACE Berechtigungen oder Überwachungen konfiguriert wurden.
Diese Einstellung kann im Feld Übernehmen für: der ACE, dort betrifft es die ersten drei Einträge Nur dieses Objekt,
Dieses und alle untergeordneten Objekte, Nur untergeordnete Objekte, vorgenommen werden.
Flags
Alle ACEs enthalten die Eigenschaft Flags, durch das der ACE erkennt, welches Feld ObjectType oder InheritedObjectType
zusätzlich noch gesetzt ist.
ObjectType
Hier wird angegeben, auf welchen Objekttyp oder welches Attribut sich das ACE bezieht.
Als Wert wird die GUID des Objekts oder des Attributs gespeichert.
InheritedObjectType
Dieses Feld im ACE gibt die GUID des Objekts an, das den betreffenden ACE erben soll.
Diese Optionen sind in den Eigenschaften eines Objekts - im Reiter Sicherheit - dort auf Erweitert klicken -
im Reiter Berechtigungen (DACL)/oder im Reiter Überwachung (SACL) auf Hinzufügen… klicken - danach den Benutzer oder die Gruppe
auswählen bzw. eingeben - anschließend erscheint das Fenster „Berechtigungseintrag für… oder Überwachungseintrag für…“
was das ACE darstellt, zu finden.
Security Descriptor (SD)
Im Active Directory das auf Objekten basiert, wie es z.B. Benutzer, Grupppen, Computer, Container, Standorte usw. darstellen,
besitzen alle Objekte sogenannte security descriptors (zu deutsch, Sicherheitsbeschreibungen). Die Werte der Sicherheitseinstellungen
(wer darf mit welchen Rechten auf das Objekt zugreifen) werden in jedem Active Directory Objekt, in der Eigenschaft
nTSecurityDescriptor gespeichert. Der Wert im nTSecurityDescriptor wird als SDDL-String gespeichert, den man sich z.B. mit
LDP.exe oder dem „Active Directory Explorer“ anzeigen lassen kann. In dieser Eigenschaft werden alle Sicherheitsinformationen
für das Objekt gespeichert. Das Windows Betriebssystem verwendet security descriptors um den Zugriff auf eine Ressource zu steuern.
In den security descriptors wird folgendes festgelegt:
-
Es werden die Benutzer sowie Gruppen angezeigt, die Zugriff auf das Objekt haben.
-
Weiterhin werden die Berechtigungen angegeben, mit denen ein Benutzer oder eine Gruppe Zugriff auf das Objekt erhält.
-
Es werden die Ereignisse auf den Objekten definiert, die überwacht werden sollen.
-
Es wird der Besitzer des Objekts angegeben.
-
Weiterhin enthält der SD Informationen darüber, welche Rechte das Objekt von übergeordneten Containern vererbt bekommt.
Es existieren selbstverständlich nicht nur im Active Directory diese security descriptors. Ganz im Gegenteil, man findet sie an
vielen Stellen auf einem System wieder, z.B. in Dateien und Verzeichnissen die auf einem NTFS-Dateisystem gespeichert sind,
Freigaben, Drucker, Registry etc. Im Prinzip existieren security descriptors auf allen Objekten, auf denen eine Zugriffssteuerung
konfiguriert werden kann. Dabei befinden sich die Sicherheitsbeschreibungen in den erweiterten Sicherheitseinstellungen eines
Objekts (in den Eigenschaften eines Objekts - im Reiter Sicherheit - dort auf Erweitert).
Der security descriptor ist eine binäre Datenstruktur mit einer variablen Länge und besteht im wesentlichen aus den folgenden Teilen:
- Der Header beinhaltet eine Revisionsnummer und eine Reihe von Optionen die beschreiben, welche Eigenschaften vorhanden
sind und welche hinzugefügt oder geändert wurden.
- In der Discretionary Access Control List (DACL) werden die einzelnen Zugriffsrechte für ein bestimmtes Objekt, in Form von
Access Control Entries (ACEs) festgelegt. In der DACL sind die Benutzer und/oder Gruppen eingetragen, denen der Zugriff auf
das Objekt erlaubt oder verweigert wird. Werden einem Benutzer oder einer Gruppe Aufgaben im Active Directory delegiert,
so werden automatisch die SIDs der Personen in die DACL der Objekte geschrieben. Der Inhalt bzw- die Einträge in der
DACL werden vom Besitzer kontrolliert.
- Die SACL ist vergleichbar mit der DACL, allerdings mit dem Unterschied, dass die SACL für die Protokollierung - anstatt für
den Zugriff auf ein Objekt zuständig ist. In der System Access Control List (SACL) sind die Überwachungseinstellungen enthalten.
Auch hier befinden sich ACEs, die den definierten erfolgreichen oder fehlgeschlagenen Zugriff protokollieren. Findet ein Zugriff
auf ein Objekt statt für den die Protokollierung aktiviert wurde (sei es erfolgreich oder fehlgeschlagen), verzeichnet das
Betriebssystem im Sicherheitslog einen Eintrag.
- Der Security Identifier (SID) des Besitzers (Owner). Der Besitzer eines Objekts kann die Berechtigungen bearbeiten und anderen
Benutzern Rechte auf das Objekt erteilen.
- Ein weiterer Bestandteil ist der SID der primären Gruppe des Besitzers
(existiert aus Kompatibilitätsgründen zu Unix/Macintosh Systemen).
Security Descriptor Definition Language (SDDL)
Die Security Descriptor Definition Language stellt ein Textformat dar, das zur Beschreibung von security descriptors dient.
In diesem String, der natürlich jederzeit veränderbar ist, werden die Sicherheitsinformationen in Form von Access Control Lists (ACLs)
samt den einzelnen Access Control Entries (ACEs) eines Objekts, im nTSecurityDescriptor gespeichert. Microsoft verwendet
die SDDL immer dann, wenn ein security descriptor im String-Format definiert werden soll.
Die nachfolgend genannte kryptische Zeichenkette stellt einen SDDL-String dar (alles in einer Zeile):
O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)
(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)
Solch einen SDDL-String findet man z.B. dann wieder, wenn einem Benutzer das Recht vergeben werden soll,
dass Eventlog eines DCs lesen zu können. Dazu existiert im folgenden Registry-Pfad des DCs:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\* in dem jeweiligen Schlüssel
(Application, Directory Service, DNS Server…) ein REG_SZ Eintrag mit dem Namen CustomSD [2]. Dort fndet sich als Wert solch
ein SDDL-String wieder. Oder in den Security Templates im Verzeichnis %windir%\security\templates trifft man ebenfalls
einen SDDL-String an. Eine andere Stelle an der man einen SDDL-String vorfindet, wäre in der Eigenschaft nTSecurityDescriptor
eines jeden Active Directoy Objekts.
Auf ein Active Directoy Objekt wirken mehrere Berechtigungen. Wird ein Objekt im Active Directory erstellt, erhält es standardmäßig
gewisse Sicherheitsinformationen, im SDDL-String, die im Schema im Attribut Default-Security-Descriptor festgelegt sind.
Zusätzlich erbt das erstellte Objekt weitere Berechtigungen, durch die darüberliegenden Einheiten (Container, OU, Domäne).
Anschließend kann der Administrator jederzeit noch die Berechtigungen des Objekts modifizieren.
Gerade für Administratoren die evtl. durch Skripte ihre tägliche Arbeit erleichtern möchten, ist es unerlässich zu verstehen,
wie ein SDDL-String sich zusammensetzt. Denn schließlich lässt sich die Delegierung von Rechten im Active Directory, im SDDL-String,
natürlich auch per Skript setzen. Des Weiteren ist es unerlässich einen SDDL-String zu verstehen, wenn mit dem
Active Directory-Kommandozeilentool DSACLS Rechte im Active Directory händisch oder per Skript delegiert bzw. gelesen werden sollen.
Auch um Security Templates zu lesen und zu bearbeiten ist es zwingend, die Syntax verstanden zu haben.
Kommen wir nun zur Erläuterung eines SDDL-Strings.
In einem SDDL-String werden die Zeichen fortlaufend durchgeschrieben und nicht durch Leerzeichen getrennt.
Die Länge eines SDDL-Strings ist nicht hartcodiert und kann variieren.
Die Schreibweise eines nTSecurityDescriptor SDDL-Strings würde so aussehen:
O:Owner-SIDG:Group-SIDD:DACL-Flags(ACE1- String)( ACE2- String)(…usw.)S:SACL-Flags(ACE1- String)( ACE2- String)(…usw.)
Jeder nTSecurityDescriptor SDDL-String besteht aus fünf Teilen. Diese wären:
- Header: Der Header enthält Eigenschaften (Flags) die beschreiben,
ob das Objekt die Vererbung von DACL und SACL erlaubt oder blockiert.
-
Owner: Der Besitzer eines Objekts trägt in einem SDDL-String das Präfix „O:“. Dieser Wert gibt an,
welcher Trustee der Besitzer des Objekts ist. Hier die Erläuterung der geläufigsten SID-Strings (Abkürzungen)
die der Wert Owner (sowie G:Group-SID) enthalten kann: AN = Anonymous
AO = Account Operators
AU = Authenticated Users
BA = Builtin Administrators
BO = Backup Operators
CG = Creator Group
CO = Creator Owner
DA = Domain Administrators
DU = Domain Users
EA = Enterprise Admins
LA = Local Administrator Account
SA = Schema Administrators
SO = Server Operatoren
SY = Local System
WD = Everyone (World)
Die komplette Liste der SID-Strings befindet sich auf dieser Seite:
SID Strings (Windows)
Im o.g. SDDL-String ist in der kryptischen Zeichenkette als Owner der Eintrag „O:BA“ enthalten und dieser steht für
„Builtin Administrators“. Statt des SID-Strings kann auch eine SID verwendet werden,
z.B. so: O:S-1-5-21-956547467-2769573453-2154042951-500G:SYD:(…).
-
Primary Group: Die primäre Gruppe erhält in einem SDDL-String das Präfix „G:“. Dieser Wert enthält den SID-String
der primären Gruppe eines Objekts. Der Wert des Owner und der Primary Group entspricht einer einzigen SID.
Der Eintrag „G:SY” bedeutet, dass die primäre Gruppe Local System lautet.
-
DACL: Die DACL wird in einem SDDL-String mit einem „D:“ eingeleitet.
-
DACL-Flags: Dieser Wert ist ein security descriptor control Flag, das auf das DACL angewendet wird.
Dieser Eintrag kann mehrere Werte enthalten (z.B. D:PAI), muss aber keine enthalten. Folgende Wert lassen sich dabei eintragen:
P = SDDL_PROTECTED. Das SE_DACL_PROTECTED Flag ist gesetzt.
AR = SDDL_AUTO_INHERIT_REQ. Das SE_DACL_AUTO_INHERIT_REQ Flag ist gesetzt.
AI = SDDL_AUTO_INHERITED. Das SE_DACL_AUTO_INHERITED Flag ist gesetzt.
-
SACL: Die SACL wird im SDDL-String als „S:“ gekennzeichnet.
-
SACL-Flags : Dieser Wert ist ein security descriptor control Flag das auf das SACL angewendet wird und ebenfalls (wie DACL-Flags)
keine feste Länge hat. Bei dem SACL-Flags String werden die gleichen Werte wie bei dem DACL-Flags String verwendet.
-
ACE-String: Der ACE-String der in Klammern gesetzt ist, beschreibt einen ACE im security descriptor für den DACL und SACL.
Der ACE-String lautet beim DACL sowie SACL gleich und setzt sich aus den folgenden sechs Feldern
(jeweils getrennt durch ein Semikolon) zusammen, die nicht alle gesetzt sein müssen:
(ACE-Type;ACE-Flags;Rights;ObjectGUID;Inherit-ObjectGUID;Account-SID)
- Als ACE-Type könnten unter anderem A für Allow oder D für Deny eingetragen sein, was den Optionen „Zulassen“ oder „Verweigern“
im security descriptor des Objekts entspricht. Bei einem Eintrag der SACL könnte als Wert AU für Audit (Überwachung) eingetragen sein.
- Falls das Objekt ein Container sein sollte kann mit dem ACE-Flags String angegeben werden,
das sich das ACE nur auf den Container oder seinen Inhalt bezieht.
- Der Rights String gibt die Berechtigungen für den ACE an.
- Der String ObjectGUID hat als Wert die GUID einer Objektklasse, eines Attributs oder Attribut Sets.
- Im Inherit-ObjectGUID kann sich die GUID einer Objektklasse befinden. Falls es gesetzt ist, bezieht sich die Vererbung
auf den ACE der untergeordneten Einträge der Objektklasse.
- Im sechsten Teil Account-SID wird der Name des Benutzer- oder Gruppenkontos angegeben (Trustee), auf dem sich die
Berechtigungen auswirken. Als Wert kann entweder ein SID-String (z.B. DA) oder die SID in Form von S-1-5-21 angegeben werden.
Ein ACE-String könnte dabei in der Praxis so aussehen: (A;;WP;;;DU) und hat dabei folgende Bedeutung:
- ACE-Type lautet in dem String A, was für „Zulassen“ steht.
- Ein Wert im ACE-Flags ist nicht gesetzt.
- Als Berechtigung wurde der Wert WP (Write_Property) vergeben, was „Schreibberechtigung“ im Active Directory-Objekt bedeutet.
- Es ist keine ObjektGUID eingetragen.
- Ebenfalls ist der Wert Inherit-ObjektGUID nicht eingetragen.
- Die Berechtigung wurde an DU (Domain_Users) vergeben, das für „Domänen-Benutzer“ steht.
Mit dem Kommandozeilentool SC kann man sich unter anderem die Sicherheitsinformationen von Diensten anzeigen lassen.
Der security descriptor des Dienstes NTDS auf einem Windows Server 2008 DC sieht so aus:
C:\SC SDSHOW NTDS
D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)
(A;;CCLCSWLORC;;;BO)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
Man kann erkennen, dass neben dem DACL auch die SACL durch das S: gesetzt ist.
Die Zugriffsrechte eines Active Directory Objekts werden dabei, durch die folgenden ACE-Strings geregelt:
CC = Create all child Objects
CR = All extended Rights
DC = Delete all Child Objects
DT = Delete Subtree
LC = List Contents
LO = List Object
RC = Read permissions
RP = Read all Properties
SD = Delete
SW = All Validated Writes
WD = Modify Permissions
WO = Modify Owner
WP = Write all Properties
Alle Werte die in einem ACE-String enthalten sein können, werden auf der folgenden Seite erläutert:
ACE Strings (Windows)
[2] How to set event log security locally or by using Group Policy in Windows Server 2003
Objektverwaltung zuweisen
Die technische Umsetzung einer Active Directory-Delegierung über die GUI, wird im Snap-In
Active Directory-Benutzer und -Computer durchgeführt. Mit einem Rechtsklick auf den Standardcontainer Users oder einer OU,
ruft man mit der Auswahl von Objektverwaltung zuweisen… den Assistent zum Zuweisen der Objektverwaltung auf
(der bereits seit Windows 2000 existiert). Nach Auswahl des Benutzers oder der Gruppe kann im darauffolgenden Schritt die Wahl
zwischen einem allgemeinen und benutzerdefinierten Task getroffen werden. Bei dem benutzerdefinierten Task gilt es auf den
darauffolgenden beiden Schritten, zum einen den Objekttyp für die Delegierung auszuwählen und zum anderen, die gewünschten
Berechtigungen die auf Attributebene aktiviert werden können auszuwählen.
Der gewiefte Administrator kann den Delegierungsassistenten im ADBuC überspringen und direkt in den erweiterten
Sicherheitseinstellungen des Containers (auch eine OU ist ein Container) die entsprechenden Berechtigungen vergeben.
Denn der Assistent für die Objektverwaltung macht auch nichts weiter, als die Personen mit den vergebenen Berechtigungen
im security descriptor des Containers einzutragen.
Um auf die Anfangsfrage zurückzukommen was im Hintergrund passiert, wenn einem Benutzer oder einer Sicherheitsgruppe
Rechte im Active Directory delegiert werden, ist nichts weiter, als das die Benutzer mit den vergebenen Rechten im
security descriptor des Objekts eingetragen werden.
Die bereits delegierten Rechte auf einem Objekt zeigt einem der Objektverwaltungs-Assistent leider nicht an.
Stattdessen ist in der MMC „ADBuC“ unter Ansicht die Option „Erweiterte Funktionen“ zu aktivieren, damit in den Eigenschaften
eines Objekts der Reiter Sicherheit erscheint. Danach kann in den erweiterten Sicherheitseinstellungen (im security descriptor)
die Person ausgewählt und mit einem Klick auf Bearbeiten… die gesetzten Berechtigungen eingesehen werden. Sollen die
vergebenen Berechtigungen dem Benutzer entzogen werden, so gilt es lediglich den Benutzer aus der ACL des Objekts zu entfernen.
Einen Assistenten für das Entfernen von Berechtigungen gibt es nicht.
Über die Kommandozeile lassen sich die Berechtigungen mit dem Tool DSACLS, das sich in den Windows Support Tools befindet
(z.B. auf der Windows Server 2003 CD im Verzeichnis Support\Tools), ebenfalls ansehen sowie vergeben. Mit dem folgenden Befehl
werden die Berechtigungen für den Standardcontainer USERS (im ADBuC) aufgelistet:
Dsacls CN=Users,DC=intra,DC=dikmenoglu,DC=de.
Alles was mit dem Assistenten delegiert werden kann, lässt sich auch in einem Skript mit DSACLS realisieren.
Die Syntax zu dem Tool wird in der Hilfe erläutert, die sich mit dem Befehl Dsacls -? aufrufen lässt.
Die vergebenen Berechtigungen können in Form von ACEs auch mit dem Kommandozeilentool DSREVOKE angezeigt und entfernt werden.
Objektdelegierungen einrichten
Der Objektdelegierungsassistent
Delegierte AD-Berechtigungen anzeigen und entfernen
Zusammenfassung
Das Delegierungskonzept sollte sorgfältig geplant, in einer Testumgebung getestet und ganz wichtig, dokumentiert werden.
In der Planungsphase sollten diese Fragen geklärt werden:
- Welche Berechtigungen sollen die entsprechenden Personen erhalten?
Dabei werden idealerweise Berechtigungen Gruppen und nicht einzelnen Personen zugewiesen.
- Ist die gewünschte Berechtigung die delegiert werden soll technisch realisierbar?
- Wenn es technisch realisierbar ist, können mit den Standard-MMCs wie z.B. „Active Directory-Benuzter und -Computer“
die Aufgaben durchgeführt werden?
Wenn ein entsprechendes Konzept erarbeitet, getestet und implementiert wurde, gestaltet sich die tägliche Administration
in der Praxis mit dem geringsten Aufwand, wobei die Benutzer nur mit den notwendigsten Rechten ausgestattet werden.
Das Delegierungskonzept sollte dabei nicht übertrieben werden, ganz nach dem Motto „soviel wie nötig - so wenig wie möglich“.
Denn wenn unüberlegt Berechtigungen delegiert werden, kann das unter Ümständen zu Performance-Einbußen im Active Directory führen.
Large Numbers of ACEs in ACLs Impair Directory Service Performance
Des Weiteren sollte bei dem Delegierungskonzept unbedingt darauf geachtet werden,
dass einem der AdminSDHolder nicht in die Quere kommt.
Delegated permissions are not available and inheritance is automatically disabled
Weitere Informationen:
Security Descriptors and Access Control Lists Technical Reference
Security Descriptor Definition Language (Windows)
Best Practices for Delegating Active Directory Administration
Best Practices for Delegating Active Directory Administration Appendices
Best practices and guidance for writers of service discretionary access control lists
Well-known security identifiers in Windows operating systems
An welchen Stellen stößt das Active Directory und seine Werkzeuge an die Grenzen?
Das "Active Directory-Benutzer und -Computer" Snap-In
-
Falls in der MMC Active Directory-Benutzer und -Computer in einem Container bzw. OU mehr als 2000 Objekte enthalten sind,
wird die folgende Meldung angezeigt:
Screenshot vom Windows Server 2008
Anschließend kann dem Hinweis gefolgt und somit die maximale Anzahl der angezeigten Elemente erhöht werden.
Dieses Verhalten trifft auf Windows 2000, Windows Server 2003 und Windows Server 2008 zu.
Die maximal unterstützte Seitengröße für LDAP-Antworten
-
Um sich z.B. vor Denial of Service (DoS) Attacken zu schützen, liefert das Active Directory bei einer LDAP-Abfrage
als Ergebnis 1.000 Datensätze. Übersteigt das Ergebnis die Grenze von 1.000 Datensätzen, wird nach den 1.000 Einträgen
der folgende Fehler angezeigt: Size Limit Exceeded Error.
Es bestehen zwei Möglichkeiten dieses Problem zu umgehen. Zum einen ist es das ändern der maximum Page Size auf dem
LDAP-Client und zum anderen, dass Erhöhen des Wertes MaxPageSize in den LDAP-Richtlinien auf den DCs.
How to view and set LDAP policy in Active Directory by using Ntdsutil.exe
Der Name einer Organisationseinheit (OU)
-
Der Name einer OU kann maximal 64 Zeichen enthalten. Damit soll sichergestellt werden, dass beim aufrufen der Gruppenrichtlinien
die sich im SYSVOL-Verzeichnis befinden durch einen UNC-Pfad, nicht die Grenze von insgesamt 260 Zeichen überschritten wird.
Denn wenn der UNC-Pfad zu den GPOs 260 Zeichen überschreiten sollte, können somit die GPOs weder gelesen, noch an die DCs, Server und Clients angewendet werden.
Siehe auch:
Windows 2000 Supports Fully Qualified Domain Names up to 64 UTF-8 Bytes Long
Die Länge des Dateinamens
Der NetBIOS-Computername
-
Der NetBIOS-Name eines Computerkontos ist auf 15 Zeichen beschränkt.
Eigentlich enthält dieser 16 Zeichen, wobei aber das 16. Zeichen für das System reserviert ist.
Der Computername darf auch nicht ausschließlich aus Zahlen bestehen.
Windows 2000 Does Not Permit All-Numeric Computer Names
Der NetBIOS-Name einer Domäne
Die Länge des Fully Qualified Domain Name einer AD-Domäne
- Der FQDN einer Active Directory-Domäne darf insgesamt 64 Zeichen (samt Punkten) enthalten.
Weitere Beschränkungen bezgl. der Namenskonventionen
Die maximale Anzahl an Objekten die ein Domänencontroller erstellen kann
Die maximale Anzahl an SIDs die innerhalb einer Domäne erstellt werden kann
- Innerhalb einer Domäne können ca. eine Milliarde Security Identifier (SIDs) erstellt werden.
Die maximale Anzahl an GPOs die auf ein Objekt wirken können
- Es können maximal 999 Gruppenrichtlinienobjekte auf ein Benutzer- oder Computerkonto angewendet werden.
Dabei können auf einem System natürlich mehr als 999 GPOs existieren.
Diese Grenze wurde aus Performancegründen festgelegt.
Die maximale Anzahl an Benutzern pro Gruppe
- Unter Windows 2000 kann eine Benutzergruppe maximal 5.000 Mitglieder enthalten.
Unter Windows Server 2003 existiert diese Grenze nicht.
Siehe auch: Die Linked Value Replikation (LVR)
Die maximale Anzahl an Änderungen innerhalb eines schreibvorgangs im AD
-
Werden automatisiert z.B. per Skript oder Management-Tools eine größere Menge an Änderungen im Active Directory
durchgeführt (z.B. das erstellen, löschen oder bearbeiten von Benutzern), können innerhalb einer Transaktion nicht mehr
als 5.000 Änderungen durchgeführt werden.
Die maximale Gruppenzugehörigkeiten eines Sicherheitsprinzipals
- In das Access-Token eines Sicherheitsprinzipals wie es z.B. Benutzer, Gruppen oder Computer darstellen,
können maximal 1.024 Einträge existieren. Bei der Anmeldung eines Benutzers wird vom Local Security Authority (LSA)
ein Access-Token generiert. In diesem Access-Token befindet sich der Security Identifier (SID) des Benutzers,
die SIDs der direkten Gruppen in denen das Benutzerkonto Mitglied ist, die SIDs von Gruppenverschachtelungen und in einer
Windows Server 2003 Umgebung noch die SID History. Befindet sich der Benutzer in mehr als 1.024 Gruppen, so schlägt die
Authentifizierung des Benutzers fehl.
Tatsächlich sollte sich das Benutzerkonto nicht in mehr als 1.015 Gruppen befinden, denn vom LSA werden standardmäßig
bis zu 9 Well-Known SIDs dem Access-Token hinzugefügt.
Users Who Are Members of More Than 1,015 Groups May Fail Logon Authentication
In der Praxis hat sich allerdings gezeigt, dass bereits Probleme auftauchen, in denen der Benutzer sich in weitaus
weniger Guppen befindet. Unter Windows 2000 - dort je nach SP-Stand - kann es schon bei Gruppenmitgliedschaften
zwischen 70-80 bzw. 120 Gruppenmitgliedschaften zu Problemen kommen.
Group Policy may not be applied to users belonging to many groups
New resolution for problems with Kerberos authentication when users belong to many groups
Unter Windows Server 2003 kann es ebenfalls zu Problemen kommen, wenn sich der Benutzer
in weitaus mehr als 70 Gruppen befindet:
Authentication Fails Due to User PAC
Troubleshooting Kerberos Errors
When you try to log on to a Windows Server 2003-based domain by using a domain user account, the logon request fails
What's in a Token
Die empfohlene maximale Anzahl an Domänen innerhalb einer Gesamtstruktur
-
In einer Windows 2000 Gesamtstruktur wird empfohlen, nicht mehr als 800 Domänen zu betreiben.
Die empfohlene Anzahl an Domänen innerhalb einer Windows Server 2003 Gesamtstruktur, die sich in der
Gesamtstrukturfunktionsebene „Windows Server 2003“ befindet, ist auf 1.200 Domänen beschränkt.
Diese Grenze gilt sicherlich auch für eine Windows Server 2008 Gesamtstruktur.
Die empfohlene Anzahl an Domänencontrollern pro Domäne
-
Die unterstützte Anzahl an Domänencontrollern innerhalb einer Windows Server 2003-Domäne beträgt 1.200.
Diese Grenze wurde festgelegt, damit im Windows Server 2003 das SYSVOL-Verzeichnis, das durch das
File Replication Service (kurz, FRS) repliziert wird, noch ordnungsgemäß rückgesichert werden kann. Dabei kann es bereits bei über 400 DCs pro Domäne zu problemen kommen, wenn das DNS auf den DCs betrieben
wird und der AD-integirerte DNS-Name mit dem AD-Namen der Domäne gleich lautet.
Problems with Many Domain Controllers with Active Directory Integrated DNS Zones
Weitere Informationen:
Active Directory Maximum Limits - Scalability
Ist es nun mit dem Windows Server 2008 das endgültige aus für den Windows Internet Naming Service (WINS) Server?
Microsoft sieht diesen Dienst nicht mehr als eine wichtige Rolle an, denn der WINS-Server ist nicht etwa im
Windows Server 2008 unter den Rollen zu finden, sondern, unter den Features. Unter Windows Server 2003 befand sich
der WINS-Server noch neben den Server-Funktionen: Domänencontroller, DNS, DHCP etc.
Mit dem WINS-Dienst werden NetBIOS-Namen in IP-Adressen aufgelöst. Dieser Dienst stellt das Pendant zum
Domain Name System (DNS) dar, denn es arbeitet ähnlich wie das DNS, dynamisch. Ein Unterschied zwischen
DNS und WINS sind die genutzten Ports. DNS verwendet den Port 53 und WINS die Ports 137, 138, 139 und 445.
WINS ist ein älterer Dienst der NetBIOS über TCP/IP (NetBT) nutzt und der elementare Dienst für die Namensauflösung
im Windows 9x bzw. Windows NT Umfeld ist. Mit Einführung von Windows 2000 führte Microsoft das Active Directory ein
und forcierte somit die Nutzung des DNS.
Falls kein WINS-Server in der Domäne zur Verfügung steht, werden NetBIOS-Namen durch Broadcasts aufgelöst. Durch die
Broadcasts kann sich je nach Größe der Umgebung sowie den eingesetzten Applikationen, der Netzwerkverkehr erheblich erhöhen.
Das betreiben eines WINS-Server in der Domäne ist zwar nicht zwingend, es ist aber mehr als empfehlenswert.
Warum? Weil zum einen jede Applikation die eine NetBIOS-Namensauflösung benötigt vom WINS profitiert und zum anderen,
der administrative Aufwand gegenüber dem Nutzen in keinem Verhältnis steht. Wenn z.B. eine Applikation ein langsames
Start- oder Arbeitsverhalten an den Tag legt, könnte das durch einen fehlenden WINS-Server hervorgerufen werden.
Einmal den WINS-Server installiert sowie konfiguriert, produziert er im täglichen Leben kaum Arbeit.
Weitere Beispiele die eine NetBIOS-Namensauflösung benötigen und somit von einem WINS-Server profitieren, wären z.B.:
Was hat das nun mit dem Windows Server 2008 auf sich?
Da das Internet Protokoll in der Version 6 (IPv6) langsam aber sicher Einzug in den Unternehmen erhält und WINS
sowie NetBT nicht das IPv6 Protokoll unterstützen, hat Microsoft im Windows Server 2008 eine weitere neue Funktion,
nämlich die Global Names Zone (GNZ) im DNS eingeführt. Diese neue Funktion kann natürlich auch mit dem IPv4 Protokoll
genutzt werden. Bei der GNZ handelt es sich um eine Forward Lookup Zone (FLZ) mit statischen, globalen Einträgen,
die in erster Linie für größere Umgebungen konzipiert wurde.
Die GNZ ist kein neuer Zonentyp, sondern, dieser zeichnet sich alleine durch seinen reservierten Namen aus.
Diese Zone erlaubt das Auflösen von single-label, den sogenannten kurzen (NetBIOS) Namen, alleine durch den DNS-Dienst.
Somit können nun Unternehmen die auf ein reines IPv6-Netzwerk wechseln, dank der GNZ im DNS, die Namensauflösung mit
nur einer Domänenbezeichnung weiterhin nutzen. Oder wenn ein Unternehmen komplett auf die NetBIOS-Namensauflösung
verzichten und dabei aber trotzdem die single-label Namensauflösung nutzen möchte, dem wird das ebenfalls durch die GNZ ermöglicht.
Natürlich sollte vorher sichergestellt sein, dass nicht doch noch Applikationen existieren, die evtl. hart-codiert eine
NetBIOS-Namensauflösung benötigen. Auch ist diese Funktionalität für die Unternehmen interessant, die das verteilen
von DNS-Suffixen z.B. per GPO nicht als praktikabel ansehen.
Fakt ist aber, die GNZ ist kein Ersatz für den WINS-Dienst!
Da keine dynamischen Updates in der GlobalNames Zone registriert werden können wie im WINS, sollte die single-label
Namensauflösung in der GNZ primär für die wichtigsten Server oder Webseiten konfiguriert werden. Das bedeutet,
die Verwaltung dieser FLZ unterliegt dem Administrator. Dieser muss die Einträge händisch pflegen. Nach der Erstellung
der GlobalNames Zone im DNS, muss der Administrator manuell die Einträge in dieser Zone erstellen, hinzufügen, bearbeiten und entfernen.
Die Gründe für den Einsatz der GlobalNames Zone wären:
- WINS soll nicht mehr verwendet werden.
- Umstellung auf ein reines IPv6 Netzwerk.
- Die Namensauflösung von einfachen, kurzen Namen soll lediglich für wichtige Server und Webseiten möglich sein.
- Alle autorisierenden DNS-Server der Zone laufen unter Windows Server 2008.
- Wenn es sich um eine große Umgebung mit vielen Domänen handelt,
kann das bereitstellen der Suffixsuchlisten auf den Clients sehr aufwändig sein.
- Wenn keine zentrale Verwaltung in großen Umgebungen möglich ist,
kann auch nicht die Eindeutigkeit von Hostnamen sichergestellt werden.
Die Gründe gegen den Einsatz der GlobalNames Zone wären:
- Es werden keine dynamischen DNS-Updates unterstützt!
- Die Einträge in der GNZ müssen manuell gepflegt werden.
- Die GNZ funktioniert ausschließlich auf DNS-Servern die unter Windows Server 2008 laufen.
Die Vorrausetzungen und die Besonderheiten der Global Names Zone wären:
- Alle autoritativen DNS-Server einer Zone müssen unter Windows Server 2008 laufen.
- Die Global Names Zone wird wie eine ganz normale Forward Lookup Zone (FLZ) im DNS implementiert. Der Name der FLZ
muss dabei zwingend GlobalNames lauten. Falls bereits eine FLZ mit diesem Namen existieren sollte, ist diese vorher zu entfernen.
- Die GlobalNames Zone sollte AD-integriert gespeichert sein und auf alle DNS Server in der Gesamtstruktur repliziert werden.
Wenn aber lediglich eine begrenzte Anzahl der Server für die GlobalNames-Zone autorisierend sein soll, kann dazu eine
eigene DNS-Anwendungsverzeichnispartition erstellt werden.
- Alle Einträge in der GNZ sollten als Alias-Einträge (einem sogenannten CNAME-Eintrag) erfolgen.
-
Auf jedem autoritativen DNS-Server in der Domäne und Gesamtstruktur muss ab sofort und für die Zukunft,
der folgende Befehl mit Administratorrechten ausgeführt werden, damit die GNZ-Funktionalität auf den
Windows Server 2008 DNS-Servern gewährleistet ist:
Dnscmd Servername /Config /EnableGlobalNamessupport 1.
Hinweis: Als Servername ist der Name des entsprechenden Servers einzutragen.
Wobei der lokale Server mit einem Punkt angegeben werden kann. Somit entfällt die Eingabe des Servernamen.
Der Befehl würde dann so aussehen: Dnscmd . /Config /EnableGlobalNamessupport 1. Mit diesem Befehl wird in dem Registry-Pfad
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\DNS\Parameters der DWORD-Schlüssel EnableGlobalNamessupport
mit dem Wert 1 erstellt. Natürlich kann dieser Schlüssel manuell in der Registry erstellt werden,
damit sich das Ausführen von DNSCMD erübrigt.
Das einrichten einer GlobalNames Zone
Die GNZ kann entweder über die Benutzeroberfläche oder Kommandozeile eingerichtet werden.
Die Vorgehensweise über die GUI wäre folgende:
- Im ersten Schritt gilt es die DNS-Managementkonsole (dnsmgmt.msc) entweder über „Start - Programme - Verwaltung - DNS“
oder über „Start - Ausführen - dnsmgmt.msc“ aufzurufen.
- Mit einem Rechtsklick auf den Servernamen oder dem Eintrag Forward-Lookupzonen ist die Option Neue Zone… auszuwählen.
- Nach der Willkommensseite ist der Zonentyp zu wählen. Es ist die erste Option Primäre Zone sowie das Kontrollkästchen
Zone in Active Directory speichern (DNS-Server muss als schreibbarer Domänencontroller eingerichtet sein) auszuwählen.
Damit die Zone im AD gespeichert werden kann, muss der DNS-Server auf einem DC installiert sein. Ansonsten kann diese
Option nicht aktiviert werden (sie ist dann ausgegraut).
- Im nächsten Schritt möchte der Assistent auf der Active Directory-Zonenreplikationsbereich Seite wissen, auf welche
Server zum einen diese Zonendaten repliziert und zum anderen, in welcher Anwendungsverzeichnispartition diese Informationen
gespeichert werden sollen. Dabei ist es zwingend notwendig die erste Option
Auf allen DNS-Servern in der Gesamtstruktur:Root-Domäne.TLD zu wählen. Mit dieser Auswahl wird die Zone in der
Anwendungsverzeichnispartition ForestDNSZones gespeichert und wird zudem auf alle DNS-Server in der Gesamtstruktur repliziert.
- Als nächstes ist es notwendig, den Namen der neuen Zone einzutragen. Dieser muss GlobalNames lauten.
Die Schreibweise des Namens ist zu vernachlässigen, denn sie ist in diesem Fall nicht „case-sensitive“.
- Im darauffolgenden Schritt möchte der Assistent wissen, welche Art von dynamischen Updates für diese Zone gelten soll.
Da die GNZ keine dynamischen Updates unterstützt und die Einträge manuell zu pflegen sind, ist die letzte Option
Dynamische Updates nicht zulassen auszuwählen.
- Im letzten Schritt angelangt, wird mit einem Klick auf Fertig stellen der Assistenten beendet.
Anschließend steht die neue Zone zur Verfügung.
Das einrichten der GlobalNames Zone über die Kommandozeile wäre folgende:
Einträge zur GlobalNames Zone hinzufügen
Auch beim Hinzufügen von DNS-Einträgen hat der Administrator die Auswahl zwischen der GUI und der Kommandozeile.
Über die Benutzeroberfläche wird ein Eintrag wie folgt erstellt:
- Mit einem Rechtsklick auf die FLZ GlobalNames ist die Option Neuer Alias (CNAME)… auszuwählen.
- Im Feld Aliasname ist der gewünschte Name einzutragen.
- Im Feld Vollqualifizierter Domänenname des Zielhosts ist der Ziel-Host mit seinem Fully Qualified Domain Name (FQDN) einzutragen.
Der Befehl zum erstellen eines Eintrags über die Kommandozeile sieht so aus:
- Dnscmd /RecordAdd GlobalNames <Name> CNAME <FQDN des Ziel-Hosts>
Ein Windows 2000, XP oder Windows Vista Client hängt in folgender Reihenfolge das DNS-Suffix an:
- Zuerst wird das primäre DNS-Suffix angehängt, außer wenn (z.B. per GPO für XP/Vista-Clients) eine Suffixsuchliste konfiguriert wurde.
Das primäre DNS-Suffix ist standardmäßig der Domänenname, in welcher der Client Mitglied der Domäne ist. Das primäre DNS-Suffix
findet man unter: Systemsteuerung - System - Reiter Computername - Ändern - Weitere…
- Falls keine Suffixsuchliste an den Clients konfiguriert wurde, wird anschließend das Verbindungsspezifische DNS-Suffix
der entsprechenden Netzwerkkarte verwendet.
- Ist eine Suffixsuchliste bei den Clients konfiguriert, so werden einzig und alleine diese anstatt des primären und verbindungsspezifischen
DNS-Suffix angewendet. An Windows XP und Windows Vista Clients können per GPO eine Suffixsuchliste verteilt werden
(Computerkonfiguration-Administrative Vorlagen-Netzwerk-DNS-Client-„Suchliste für DNS-Suffix“).
How to configure a domain suffix search list on the Domain Name System clients
Ergänzend
Die aktuellen Betriebssysteme Windows Vista sowie Windows Server 2008 unterstützen zudem noch das
Link-Local Multicast Name Resolution (LLMNR), auch bekannt als Multicast DNS oder mDNS. Mit diesem neuen Protokoll wird
eine weitere Möglichkeit zur Auflösung von Hostnamen im gleichen Subnet zur Verfügung gestellt. Dies ist insbesondere dann
interessant, wenn kein DNS-Server zur Verfügung steht.
Mehr dazu: Link-Local Multicast Name Resolution
Fazit
Auch unter Windows Server 2008 lautet die Antwort: WINS hat weiterhin seine Daseinsberechtigung!
Weitere Informationen:
DNS Server GlobalNamesZone Deployment
Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution for full functionality
Bei einer Migration auf Windows Server 2008 führen die Träger der FSMO-Rollen wichtige Aufgaben durch.
Genau genommen handelt es sich dabei um zwei FSMO-Rollen. Zum einen wäre das die Rolle des Schemamasters,
den es nur einmal in der Gesamtstruktur gibt. Dieser erweitert bei einer Migration das Schema in dem neue Attribute
sowie Klassen dem Schema hinzugefügt oder bestehende Attribute verändert werden. Zum anderen wäre da noch der Infrastrukturmaster.
Diese Rolle, die einmal pro Domäne existiert, aktualisiert während einer Migration die bestehende Domäne in dem Berechtigungen
bestehender Objekte bearbeitet werden. Erst wenn diese beiden Rollen die Änderungen die durch das ADPREP hervorgerufen
werden durchgeführt haben, ist es möglich einen Domänencontroller (DC) auf Windows Server 2008 zu aktualisieren bzw. einen
Windows Server 2008 DC zur Domäne hinzuzufügen.
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Welche Rolle nimmt nun der PDC-Emulator bei einer Migration auf Windows Server 2008 ein?
Nun, eine analoge wie bei einer Migration von Windows 2000 auf Windows Server 2003. 
Der PDC-Emulator ist neben den beiden Rollen „RID-Master“ und „Infrastrukturmaster“ die dritte Rolle, die in jeder Active Directory-Domäne existiert.
Diese Rolle nimmt in seiner täglichen Arbeit wichtige Aufgaben wahr.
Unter anderem wären das:
-
Zeitsynchronisation. DCs gleichen sich ihre Zeit vom PDC-Emulator ab.
-
Gruppenrichtlinien werden auf dem PDC-Emulator bearbeitet.
-
Kennwortänderungen von Benutzern werden von dem DC auf dem diese Änderung durchgeführt wurde, bevorzugt zum PDC-Emulator repliziert.
-
Wenn ein Anmeldeversuch eines Benutzers fehlschlagen sollte, wird in letzter Instanz das Kennwort vom PDC-Emulator überprüft.
-
Kontosperrungen werden vom PDC-Emulator durchgeführt.
Findet eine Migration statt, so bekommt der PDC-Emulator eine weitere wichtige Aufgabe die im Folgenden erläutert wird.
Falls in einer Windows 2000 Domäne ein Windows Server 2003- oder Windows Server 2008 Domänencontroller hinzugefügt
und auf diesem die Rolle des PDC-Emulators verschoben wird, werden diverse neue Sicherheitsprinzipale erstellt und bestehende
Gruppenzugehörigkeiten verändert. Das gleiche erfolgt natürlich auch, wenn der Träger des PDC-Emulators per In-place Upgrade
auf Windows Server 2003 aktualisiert wurde.
Es werden die folgenden Builtin-Gruppen in jeder Domäne erstellt:
-
Builtin\Erstellungen eingehender Gesamtstrukturvertrauensstellung
-
Builtin\Distributed COM Users
-
Builtin\Leistungsprotokollbenutzer
-
Builtin\Netzwerkkonfigurations-Operatoren
-
Builtin\Remotedesktopbenutzer
-
Builtin\Systemmonitorbenutzer
-
Builtin\Terminalserver-Lizenzserver
-
Builtin\Windows-Autorisierungszugriffsgruppe
Zusätzlich werden die nachfolgend genannten Gruppenzugehörigkeiten in jeder Domäne aktualisiert:
-
Der Builtin-Gruppe\Prä-Windows 2000 kompatibler Zugriff wird das Objekt ForeignSecurityPrincipal\Authentifizierte Benutzer hinzugefügt.
-
Befindet sich aber das Objekt ForeignSecurityPrincipal\Jeder bereits in der Builtin-Gruppe\Prä-Windows 2000 kompatibler Zugriff,
so werden die Objekte ForeignSecurityPrincipal\ANONYMOUS-ANMELDUNG und ForeignSecurityPrincipal\Authentifizierte Benutzer hinzugefügt.
-
Das Objekt ForeignSecurityPrincipal\NETZWERKDIENST wird zu der Builtin-Gruppe\Leistungsprotokollbenutzer hinzugefügt, aber nur,
wenn der PDC-Emulator auf einen Windows Server 2003 DC aktualisiert bzw. verschoben wird. Das gilt nicht für einen Windows Server 2008 DC.
-
Die Builtin-Gruppe\Windows-Autorisierungszugriffsgruppe wird um das neue Mitglied
ForeignSecurityPrincipal\DOMÄNENCONTROLLER DER ORGANISATION ergänzt.
Den Container ForeignSecurityPrincipal kann man sich z.B. in der MMC „Active Directory-Benutzer und -Computer“ anschauen.
Allerdings werden die darin gespeicherten Objekte erst dann angezeigt, wenn in dem Snap-In unter Ansicht die Option
Erweiterte Funktionen aktiviert wurde.
Wird der Windows 2000 Domänencontroller der Root-Domäne auf dem der PDC-Emulator liegt per In-place Upgrade auf
Windows Server 2003 aktualisiert oder die Rolle auf einen Windows Server 2003 bzw. Windows Server 2008 DC verschoben,
so werden weitere Objekte der Klasse ForeignSecurityPrincipal im Container WellKnown Security Principals erstellt.
Der Container befindet sich in der Konfigurationspartition.
Die neuen Objekte wären:
-
Digest Authentication
-
Local Service
-
-
-
-
-
-
Bei einer Migration von Windows 2000 oder Windows Server 2003 auf Windows Server 2008
werden weitere Sicherheitsprinzipale erstellt sowie Gruppenzugehörigkeiten aktualisiert.
Neue Well-Known und Builtin-Gruppen werden erzeugt sowie bestehende Gruppenzugehörigkeiten verändert, wenn folgendes zutrifft:
Beim verschieben einer FSMO-Rolle wird im Verzeichnisdienstprotokoll die Event-ID 1458 protokolliert.
Leider fehlt in diesem Eintrag der Hinweis, welche Rolle verschoben wurde!
Die Veränderungen wären wie folgt:
Diese Builtin- sowie lokalen Sicherheitsgruppen werden in jeder Domäne erstellt:
-
Builtin\Ereignisprotokollleser
-
-
Builtin\Kryptografie-Operatoren
-
Builtin\Zertifikatdienst-DCOM-Zugriff
-
Users\Abgelehnte RODC-Kennwortreplikationsgruppe
-
Users\Domänencontroller ohne Schreibzugriff
-
Users\Zulässige RODC-Kennwortreplikationsgruppe
-
Users\Krbtgt_<ID> (wird nur erstellt, wenn ein RODC zu einer Windows Server 2003/2008 Domäne hinzugefügt wurde)
-
Users\Domänencontroller der Organisation ohne Schreibzugriff (diese Gruppe wird nur in der Root-Domäne erstellt)
Die neuen Gruppenzugehörigkeiten in jeder Domäne wären:
-
Das Sicherheitsprinzipal ForeignSecurityPrincipals\IUSR wird zur Builtin-Gruppe IIS_IUSRS hinzugefügt
-
Das Sicherheitsprinzipal ForeignSecurityPrincipals\NETZWERKDIENST wird aus der Builtin-Gruppe\Leistungsprotokollbenutzer entfernt
-
Die folgenden Gruppen werden der Gruppe Abgelehnte RODC-Kennwortreplikationsgruppe hinzugefügt:
-
-
-
Domänencontroller ohne Schreibzugriff
-
-
-
Richtlinien-Ersteller-Besitzer
-
-
In der Root-Domäne werden in der Konfigurationspartition die folgenden Objekte im Container WellKnown Security Principals erstellt:
-
-
-
Das Objekt Well-Known-Security-Id-System wird umbenannt zu System
Es ist stets empfehlenswert die FSMO-Rollen einer Domäne (insbesondere den PDC-Emulator) auf den DC,
der das aktuellere Serverbetriebssystem ausführt zu verschieben. Wird das nicht getan, so werden die entsprechenden
Sicherheitsprinzipale nicht erstellt. Dabei sollte aber beachtet werden, falls man sich dazu entscheidet die FSMO-Rollen
zu trennen (was in vielen Umgebungen nicht notwendig ist), dass es dabei ebenfalls einiges zu beachten gilt:
Die FSMO-Rollen verschieben
Weitere Informationen:
Well-known security identifiers in Windows operating systems
Immer wieder stolpere ich über Missverständnisse, welche Rolle der Domänen- respektive Gesamtstrukturfunktionsmodus in einer
bestehenden Umgebung spielt. Gerade im Zusammenhang wenn eine Migration bevor steht oder ein Windows 2000 Domänencontroller (DC)
in eine Windows Server 2003 Domäne hinzugefügt werden soll, kommen Administratoren des Öfteren ins straucheln.
Gerade auf dem Windows Server 2008 Launch in Frankfurt am Main fiel mir in den Gesprächen immer wieder auf,
dass es Missverständnisse mit den einzelnen Funktionsebenen gibt.
Als mit Windows 2000 das Active Directory in seiner ersten Version eingeführt wurde, musste Microsoft die Interoperabilität innerhalb
der Domänen zwischen den verschiedenen Serverbetriebssystemen die auf Domänencontrollern installiert sein können sicherstellen.
Demzufolge wurde mit Windows 2000 die Funktionsebenen, genauer, der Domänenfunktionsmodus eingeführt. Mit Windows Server 2003
kam zusätzlich der Gesamtstrukturfunktionsmodus hinzu. Durch die jeweiligen Funktionsebenen konnte gewährleistet werden,
dass Domänencontroller (DC) auf älteren Serverbetriebssystemen auch mit DCs die auf neueren Serverbetriebssystemen laufen,
zusammen innerhalb einer Domäne existieren können. Weiterhin konnte mit den Funktionsebenen sichergestellt werden,
dass Domänen sowie Gesamtstrukturen in einem bestimmten Modus betrieben werden können, um so die jeweils zur Verfügung stehenden
(neuen) Funktionen nutzen zu können. Denn dadurch, dass das Serverbetriebssystem stetig weiterentwickelt wird, werden mit jeder
neuen Version neue Funktionen der Domäne sowie der Gesamtstruktur hinzugefügt. Das bedeutet im Umkehrschluss,
dass die Vorgängerversionen die Neuerungen die mit jeder neuen Serverbetriebssystem-Version dem Active Directory hinzugefügt werden,
nicht kennen und somit auch nicht nutzen können.
Folglich wird mit den Funktionsebenen die Möglichkeit geschaffen, einerseits DCs mit verschiedenen Serverbetriebssystem-Versionen
innerhalb der Domäne zu betreiben und andererseits, neue Funktionen dem Active Directory hinzuzufügen. Der Administrator kann selbst
entscheiden wann er in die nächsthöhere Ebene wechselt, um von den Vorteilen die der höhere Modus bietet zu profitieren. Dies kann er
selbstverständlich nur dann tun, wenn die Voraussetzung für den höheren Modus gegeben sind. Den Unternehmen wird somit die Möglichkeit
geschaffen, eine sanfte Migration z.B. von Windows NT zu Windows 2000 oder Windows Server 2003 durchzuführen und parallel NT-BDCs,
Windows 2000 DCs und Windows Server 2003 DCs zu betreiben. Anschließend kann die sukzessive Migration der einzelnen DCs auf das neuere
Serverbetriebssystem durchgeführt und am Ende der Modus umgestellt werden.
NT-BDCs können neben Windows Server 2008 DCs nicht mehr existieren!
Stattdessen können Windows 2000 DCs sowie Windows Server 2003 DCs neben Windows Server 2008 DCs bestehen.
Der Domänenfunktionsmodus legt den Modus einer Domäne und somit die einzusetzenden Domänencontroller in dieser Domäne fest.
Dieser Modus kann nur dann heraufgestuft werden, wenn alle Domänencontroller einer Domäne eine gewisse Serverbetriebssystem-Version
ausführen, die für den höheren Modus notwendig ist.
Das bedeutet konkret, möchte man in den einheitlichen Domänenfunktionsmodus
Windows 2000 pur wechseln, so müssen alle DCs dieser Domäne unter Windows 2000, Windows Server 2003/2003R2,
Windows Server 2008 oder Windows Server 2008 R2 laufen. Es dürfen keine NT-BDCs mehr in der Domäne existieren,
da ansonsten die Möglichkeit des Heraufstufen nicht gegeben ist.
Befindet sich die Domäne im Modus Windows Server 2003, so ist es nicht mehr möglich einen Windows 2000 DC,
geschweige denn NT-BDC zur Domäne hinzuzufügen, sondern nur noch Windows Server 2003/2003 R2 und Windows Server 2008/2008 R2 DCs.
Oder wenn man in den Domänenfunktionsmodus Windows Server 2008 wechseln möchte um von den neuen Features zu profitieren
(Password Settings Objects - kurz PSO - oder die DFS-Replikation für das SYSVOL-Verzeichnis), so müssen alle DCs dieser Domäne
unter Windows Server 2008 oder Windows Server 2008 R2 laufen. Sonst ist das Heraufstufen der Domäne nicht möglich.
Möchte man den AD-Papierkorb der unter Windows Server 2008 R2 zur Verfügung steht nutzen, so muss sich der Gesamtstrukturfunktionsmodus
auf Windows Server 2008 R2 befinden. In diesem Modus können dann nur Windows Server 2008 R2 DCs oder höher existieren.
Wie bereits erwähnt, wurde im Active Directory von Windows Server 2003 neben dem Domänenfunktionsmodus zusätzlich der
Gesamtstrukturfunktionsmodus eingeführt. Mit diesem zusätzlichen Modus auf Gesamtstrukturebene wird zwischen einer Windows 2000,
Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2 Gesamtstruktur klar unterschieden.
Der Gesamtstrukturfunktionsmodus legt den Modus einer Gesamtstruktur fest. Das Heraufstufen ist nur dann möglich,
wenn sich alle Domänen in dieser Gesamtstruktur in einem bestimmten Domänenfunktionsmodus befinden.
In den Gesamtstrukturfunktionsmodus Windows 2000 lässt sich nur dann wechseln, wenn sich alle Domänen im Domänenfunktionsmodus
„Windows 2000 pur“ oder höher befinden. Auf den Gesamtstrukturfunktionsmodus Windows Server 2003 kann nur dann gewechselt werden,
wenn sich alle Domänen im Domänenfunktionsmodus Windows Server 2003 oder höher befinden.
Das gleiche gilt natürlich auch für den Gesamtstrukturfunktionsmodus Windows Server 2008. Dort kann in diese Ebene nur gewechselt werden,
wenn alle Domänen im Domänenfunktionsmodus Windows Server 2008 oder höher sind. Um in den Gesamtstrukturfunktionsmodus
Windows Server 2008 R2 zu wechseln, müssen sich alle Domänen im Domänenfunktionsmodus "Windows Server 2008 R2" oder höher befinden.
Hinweis: Wenn sich die Domänen in einer Windows Server 2003 Gesamtstruktur im Domänenfunktionsmodus „Windows 2000 pur“ befinden,
werden diese automatisch auf den Domänenfunktionsmodus „Windows Server 2003“ heraufgestuft, sobald man den
Gesamtstrukturfunktionsmodus auf Windows Server 2003 stuft. Vorausgesetzt, es befinden sich in allen Domänen der
Gesamtstruktur ausschließlich Windows Server 2003 DCs.
Das gleiche trifft im Übrigen auf eine Windows Server 2008 Gesamtstruktur zu. Wenn dort die Domänen im einheitlichen
Domänen-Modus „Windows 2000“ oder „Windows Server 2003“ sind und sich ausschließlich Windows Server 2008 DCs in
den Domänen befinden, werden alle Domänen auf den Domänenfunktionsmodus Windows Server 2008 gestuft, sobald der
Gesamtstrukturfunktionsmodus auf Windows Server 2008 gestuft wird.
Das bedeutet im Klartext, befinden sich alle Domänen in der Gesamtstruktur in einem "einheitlichen Modus" und werden die Betriebssysteme
die auf den DCs laufen von dem höheren Modus unterstützt, so werden alle Domänen automatisch in den höheren Domänenfunktionsmodus heraufgestuft,
sobald man den Gesamtstrukturfunktionsmodus heraufstuft.
Die Funktionsebenen auf Domänen- sowie Gesamtstrukturebene haben einzig und allein Einfluss auf die Domänencontroller.
Mitgliedsserver sowie Clients sind davon unbetroffen und können in jedem Modus Mitglied der Domäne sein. Auch im
Domänenfunktionsmodus „Windows Server 2003“ können Windows NT Mitgliedsserver weiterhin existieren.
Wichtig ist, wurde der Domänen- oder Gesamtstrukturfunktionsmodus einmal heraufgestuft, kann der Modus nicht mehr zurückgestuft werden!
Das Heraufstufen der Domäne bzw. Gesamtstruktur ist ein irreversibler Vorgang!
Eine Ausnahme besteht jedoch seit Windows Server 2008 R2. Ist der AD-Papierkorb nicht aktiviert, kann der Domänen- sowie Gesamtstrukturfunktionsmodus
nur auf "Windows Server 2008" zurückgestuft werden (Details unter "Weitere Informationen").
Für das Heraufstufen des Domänenfunktionsmodus werden Domänen-Administrator Rechte benötigt.
Die Heraufstufung wird von dem DC durchgeführt, der die FSMO-Rolle des PDC-Emulators innehat.
Egal mit welchem DC der Administrator mit der MMC „Active Directory-Benutzer und -Computer“ oder
„Active Directory-Domänen und -Vertrauensstellungen“ verbunden ist, zum Zeitpunkt des Heraufstufens
verbindet sich der DC mit dem PDC-Emulator.
Zum Heraufstufen des Gesamtstrukturfunktionsmodus werden Organisations-Admin Rechte benötigt.
Dieser Vorgang wird vom Schema-Master durchgeführt. Auch hier ist die Durchführung die gleiche,
wie beim Heraufstufen der Domäne. Falls der DC mit dem der Administrator nicht die Rolle des
Schemamasters innehat, verbindet sich der DC mit diesem, der dann die Gesamtstruktur herauf stuft.
Welche Vorteile in Bezug auf Funktionen und Sicherheit die einzelnen Funktionsebenen mit sich bringen,
wird auf den folgenden Seiten beschrieben:
Understanding AD DS Functional Levels
How to raise domain and forest functional levels in Windows Server 2003
Domain and forest functionality
How Active Directory Functional Levels Work
Den Domänen- bzw. Gesamtstrukturfunktionsmodus kann man während dem Betrieb umstellen und es ist auch kein Neustart notwendig!
Mit wenigen Mausklicks wird die Domäne bzw. Gesamtstruktur umgestellt. Bei dem Aktualisierungsprozess wird einiges an Netzwerkverkehr in der
Domäne bzw. Gesamtstruktur erzeugt, daher sollte darauf geachtet werden die Heraufstufung nicht im Hochbetrieb durchzuführen.
Bestehende Vertrauensstellungen, sei es zu Windows NT, Windows 2000, Windows Server 2003 oder Windows Server 2008
sind davon nicht betroffen bzw. haben mit dieser Umstellung kein Problem und funktionieren weiterhin.
Über die MMCs lässt sich das Heraufstufen des Domänenfunktionsmodus entweder über das Snap-In
„Active Directory-Benutzer und -Computer“ (dsa.msc) oder „Active Directory-Domänen und -Vertrauensstellungen“ (domain.msc)
durchführen, wobei die Gesamtstruktur ausschließlich im Snap-In „Active Directory-Domänen und -Vertrauensstellung“ heraufgestuft
werden kann. Mit einem Rechtsklick auf den FQDN steht in der jeweiligen MMC die Option Domänenfunktionsebene heraufstufen…
zur Verfügung. Zum Heraufstufen der Gesamtstruktur muss in der MMC domain.msc mit einem Rechtsklick auf den Eintrag
Active Directory-Domänen und -Vertrauensstellung die Option Gesamtstrukturfunktionsebene heraufstufen… ausgewählt werden.
Danach können jeweils die zur Verfügung stehenden Ebenen eingestellt werden.
Beide Ebenen lassen sich ebenfalls durch bearbeiten (mit LDP.exe oder ADSIEdit.msc) des Attributs msDS-Behavior-Version heraufstufen.
Für den Gesamtstrukturfunktionsmodus ist im Attribut msDS-Behavior-Version, das sich in den Eigenschaften des Containers
<CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet, der entsprechende Wert einzutragen.
Für den Domänenfunktionsmodus findet man das Attribut msDS-Behavior-Version in den Eigenschaften des Containers <DC=Domäne,DC=TLD>.
Folgende Werte können im Attribut msDS-Behavior-Version eingetragen werden:
0 = Domänenfunktionsebene: Windows 2000 gemischt und Windows 2000 pur
0 = Gesamtstrukturfunktionsebene: Windows 2000
1 = Domänenfunktionsebene: Windows Server 2003 Interim
1 = Gesamtstrukturfunktionsebene: Windows Server 2003 Interim
2 = Domänenfunktionsebene: Windows Server 2003
2 = Gesamtstrukturfunktionsebene: Windows Server 2003
3 = Domänenfunktionsebene: Windows Server 2008
3 = Gesamtstrukturfunktionsebene: Windows Server 2008
4 = Domänenfunktionsebene: Windows Server 2008 R2
4 = Gesamtstrukturfunktionsebene: Windows Server 2008 R2
Im Übrigen ist durch das bearbeiten des Attributs msDS-Behavior-Version dies die einzige Möglichkeit, die Gesamtstrukturfunktionsebene
„Windows Server 2003 Interim“ zu wählen, wenn kein Inplace-Update von Windows NT durchgeführt wurde. Findet kein Inplace-Update
von Windows NT statt, steht dieser Modus nicht zur Verfügung.
Es gibt die folgenden Domänenfunktionsebenen:
Windows 2000 gemischt
Dieser Modus existiert in Windows 2000 und Windows Server 2003 Domänen.
Es können NT-BDCs, Windows 2000 DCs und Windows Server 2003 DCs in diesem Modus bestehen.
Windows 2000 pur
Diese Ebene besteht in Windows 2000, Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2 Domänen.
Darin können Windows 2000, Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2 DCs existieren.
Windows Server 2003 Interim
Die Auswahl des Modus „Windows Server 2003 Interim“ steht ausschließlich nur zur Auswahl, wenn von einer NT-Domäne
per Inplace-Update auf Windows Server 2003 aktualisiert wird. In diesem Modus können NT-BDCs sowie Windows Server 2003 DCs existieren.
Windows Server 2003
Dieser native Modus besteht in Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 Domänen.
Neben Windows Server 2003 DCs können auch Windows Server 2008 sowie Windows Server 2008 R2 DCs in der Domäne betrieben werden.
Windows Server 2008
In diesem Domänenfunktionsmodus können sich Windows Server 2008 DCs und Windows Server 2008 R2 DCs befinden.
Windows Server 2008 R2
Dieser Domänenfunktionsmodus kann lediglich Windows Server 2008 R2 DCs beinhalten!
Als Gesamtstrukturfunktionsebenen gibt es:
Windows 2000
In dieser Gesamtstrukturebene können die folgenden Domänenfunktionsebenen existieren:
- Windows 2000 gemischt
- Windows 2000 pur
- Windows Server 2003
- Windows Server 2008
- Windows Server 2008 R2
Windows Server 2003 Interim
Hier können Windows Server 2003 Interim, Windows Server 2003 und Windows Server 2008 Domänen
(im Domänenfunktionsmodus Windows Server 2003) bestehen.
Windows Server 2003
Dieser Modus kann Domänen im Domänenfunktionsmodus Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 beinhalten.
Windows Server 2008
Dieser Gesamtstrukturmodus legt fest, dass ausschließlich Windows Server 2008 und Windows Server 2008 R2 Domänen in der Gesamtstruktur bestehen können.
Windows Server 2008 R2
In diesem Gesamtstrukturfunktionsmodus können ausschließlich Windows Server 2008 R2 Domänen in der Gesamtstruktur bestehen.
Weitere Informationen:
Den Domänen- sowie Gesamtstrukturfunktionsmodus mit der AD-Powershell hochstufen
Den Domänen- und Gesamtstrukturfunktionsmodus zurückstufen
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|