Wer kennt das nicht. Man unterhält sich während der Benutzerpflege im Active Directory mit seinen Kollegen über
das gestrige Fußball-Spiel oder hängt während dessen am Telefon und versucht an einem kniffligen Problem Hilfe zu leisten,
so das man abgelenkt ist und dabei alte Benutzerkonten entfernt. Schnell wurden zwei-Klicks im Snap-In
Active Directory-Benutzer und -Computer am falschen Benutzer-Objekt getätigt und schon wurde der falsche Benutzer gelöscht.
Das ist ärgerlich. Zumal wenn es sich auch noch um das Benutzerkonto einer wichtigen Person (des CEO vielleicht?) handelt.
Oder es wird irrtümlich ein anderes Objekt gelöscht etc.
Was passiert nun genau im Hintergrund, mit dem aus Versehen gelöschten Objekt?
Welche Änderungen am Objekt während des Löschvorgangs durchgeführt werden oder welche Attribute
im Tombstone erhalten bleiben, zeigt der folgende Artikel:
Lingering Objects (veraltete Objekte)
Doch bevor das Objekt gelöscht wird und somit in den versteckten Container Deleted Objects
(in der Verzeichnispartition, in der das Objekt gelöscht wurde) wandert, wird anhand bestimmter Kriterien geprüft ob das Objekt
tatsächlich gelöscht werden darf. Diese Kriterien wären unter anderem:
-
Der Benutzer der das Objekt löschen möchte hat die benötigten Rechte
-
Das Objekt wurde nicht bereits gelöscht und somit befindet sich das Attribut Is-Deleted des Objekts, nicht auf dem gesetzten Wert True
-
Das System-Flags Attribut (0x80000000) des Objekts verhindert nicht das löschen
-
Das Objekt enthält keine untergeordneten Objekte (ansonsten erscheint eine Fehlermeldung, siehe: Computerkonto löschen)
-
-
Es handelt sich nicht um ein Schemaobjekt, wie es Attribute und Klassen darstellen. Denn diese können weder
entfernt und somit auch nicht wiederhergestellt werden. Denn wenn das möglich wäre, könnten Inkonsistenzen in der
Active Directory-Datenbank (NTDS.dit) entstehen. Unter Umständen bestehen nämlich Abhängigkeiten z.B. auf das zu löschende Attribut.
Die einzige Möglichkeit wäre, dass Attribut Is-Defunct zu nutzen, um das entsprechende Attribut bzw. die Klasse zu deaktivieren
Wird nun das Objekt gelöscht, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.DIT).
Das Active Directory markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE gesetzt wird.
Dabei werden von dem Objekt die meisten Attribute auf ewig entfernt. Anschließend wandert das Objekt in den Container
Deleted Objects (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Im Container Deleted Objects erhält das Tombstone einen speziellen Relative Distinguished Name (RDN),
der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“.
Das gelöschte Objekt verbleibt in dem Container so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist.
Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage.
Beim erstellen einer Gesamtstruktur mit Windows Server 2003 SP1, beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit,
wird das Objekt nun endgültig vom Garbage Collection Prozess (der alle 12 Stunden läuft) aus dem Active Directory entfernt.
Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit die Replikation genug Zeit hat,
diese Information des Löschens auch wirklich an alle DCs zu kommunizieren.
Welche Möglichkeiten hätte man nun, um das Objekt wiederherzustellen?
Zum einen funktioniert das natürlich durch eine autoritative Wiederherstellung und zum anderen bietet das Active Directory
unter Windows Server 2003 die Möglichkeit, den Tombstone, der also noch im Active Directory existiert, wiederzubeleben.
Für eine autoritative Wiederherstellung ist es ratsam, eine möglichst aktuelle System State-Sicherung des entsprechenden DCs
zu verwenden (Stichwort: Registry). Es darf keine System State-Sicherung die älter als die TSL ist, verwendet werden.
Was auch noch wichtig ist und von vielen Administratoren nicht beachtet wird, ist der Pfad zum Objekt,
also der sogenannte Distinguished-Name (DN). Dieser muss bekannt sein.
Der Nachteil bei dieser Variante der Wiederherstellung wäre, der Domänencontroller muss im Modus
„Verzeichnisdienste wiederherstellen“ gestartet werden und wäre somit für die Dauer der Wiederherstellung offline.
Der Vorteil wiederum wäre, dass z.B. ein Benutzer-Objekt mit den Einstellungen die es zum Zeitpunkt der Sicherung hatte,
wiederhergestellt wird (Stichwort: Object-GUID und Object-SID).
Einen Kern des Problems, stellen beim rücksichern von Benutzer- sowie Gruppen-Objekten, die Gruppenmitgliedschaften dar.
Dieses wird aber im folgenden KB-Artikel ausführlich behandelt. Insbesondere mit Windows Server 2003 SP1 hat sich dieses
Verhalten verbessert, was das wiederherstellen von Backlinks betrifft.
How to restore deleted user accounts and their group memberships in Active Directory
Um in den Modus Verzeichnisdienste wiederherstellen zu gelangen, gilt es beim Starten des DCs auf die F8-Taste zu drücken,
damit diese Auswahlmöglichkeit überhaupt erscheint. Erst in diesem Modus ist das Active Directory offline und kann gewartet werden.
Dort angelangt, muss zuerst das System State rückgesichert und anschließend mit NTDSUTIL das gewünschte Objekt
autoritativ wiederhergestellt werden. Denn erst mit anwenden von NTDSUTIL wird die Versionsnummer
des Objekts um 100.000 erhöht. Damit wird sichergestellt, dass zum einen das Objekt von keinem anderen DC erneut gelöscht
und zum anderen, dieses Objekt auf alle anderen DCs repliziert wird. Viele Administratoren machen an dieser Stelle oftmals einen Fehler,
denn sie starten nach dem rücksichern des System States direkt den DC im normalen Modus ohne mit
NTDSUTIL das Objekt autoritativ wiederherzustellen.
Es sei denn, es handelt sich um eine Domäne mit nur einem DC (was ohnehin grob fahrlässig wäre).
Denn dann gäbe es keinen anderen DC, der die Rücksicherung überschreiben würde und man bräuchte NTDSUTIL nicht anzuwenden.
Einen Tombstone wiederbeleben
Das wiederbeleben eines Tombstones hat gegenüber einem neu erstellen eines Benutzer-Objekts einen großen Vorteil.
Im Tombstone ist nämlich (unter anderem) die Object-GUID sowie Object-SID enthalten. Somit wären beim wiederbeleben
die Verweise in den ACLs der Netzwerk-Ressourcen (z.B. Freigaben etc.) weiterhin gültig und müssten nicht neu vergeben werden.
Denn beim erstellen eines Sicherheitsprinzipals (so wie es ein Benutzer-Objekt darstellt), wird auch bei der Eingabe der
gleichen Benutzerdaten wie z.B. der gleiche Benutzeranmeldename etc. eine andere Object-GUID sowie Object-SID vergeben.
Deshalb ist das neue Objekt ein „anderes“, da es sich von der GUID und SID des originalen Objekts unterscheidet.
Des Weiteren ist es auch nicht notwendig, wie bei der autoritativen Wiederherstellung, den DC offline zu schalten.
Der Nachteil bei dieser Variante wiederum wäre, dass Objekt wird mit einigen wenigen Attributen wiederhergestellt
und die fehlenden Informationen z.B. bei einem Benutzer-Objekt, müssten erneut in den Benutzereigenschaften ein gepflegt werden.
Im Active Directory Schema ist vorgegeben, welche Attribute im Tombstone erhalten bleiben. Im Tombstone werden vor allem
keine Attribute der Gruppenzugehörigkeit oder das memberOf-Attribut eines Benutzer-Objekts gespeichert. Daher ist das
wiederbeleben eines Tombstones, zum wiederherstellen der Gruppenmitgliedschaften nicht geeignet.
Tipp: Genau an dieser Stelle, setzt das Skript Werding an.
Durch das vierte Bit im Search-Flags Attribut (in Dezimal 8) allerdings, lassen sich weitere Attribute im Tombstone speichern.
Somit lässt sich im Active Directory-Schema beeinflussen, welche zusätzlichen (neben den hartcodierten) Attribute im
Tombstone erhalten bleiben. Bei der Installation eines Exchange-Servers z.B. werden zusätzliche Attribute im Tombstone gespeichert.
Damit ein Tombstone zum Leben erweckt werden kann, muss zum einen das Attribut Is-Deleted regelrecht entfernt werden
(den Wert auf FALSE setzen reicht in diesem Fall nicht aus) und zum anderen, muss das Distinguished-Name-Attribut vom
Objekt geändert werden. Erst jetzt ist es möglich, dass Objekt in einen anderen Container zu verschieben. Doch auch bevor das
durchgeführt werden kann, wird überprüft, ob die notwendigen Kriterien für zum durchführen dieser Aufgabe erfüllt werden.
Diese wären unter anderem:
- Das Benutzerkonto mit dem das Objekt wiederhergestellt werden soll, muss über das Recht des Wiederbelebens eines Tombstone verfügen
- Natürlich kann der Benutzer nicht sein eigenes Benutzer-Objekt wiederherstellen
- Das Attribut Is-Deleted des Objekts muss auf den Wert TRUE gesetzt sein
Um einen Tombstone wiederzubeleben, lässt sich das z.B. mit ADRestore (einem Kommandozeilen-Tool aus dem Hause Microsoft)
oder LDP.exe aus den Windows Support Tools erledigen. Im Internet gibt es noch eine Menge Dritt-Anbieter Tools mit denen ein
Tombstone wiederbelebt oder das Active Directory gesichert und wiederhergestellt werden kann.
Zum speichern und wiederherstellen wichtiger Attribute, könnte auch das in Windows Server 2003 integrierte LDIFDE verwendet werden.
Als weitere Möglichkeit, kann unter Windows Server 2003 eine API verwendet werden, um einen Tombstone wiederzubeleben.
Im ersten Schritt, wird das gelöschte Objekt abgerufen und im zweiten wieder hergestellt:
Retrieving Deleted Objects (Windows)
Restoring Deleted Objects (Windows)
Beispiel:
Damit eine OU autoritativ wiederhergestellt werden kann, müssen folgende Schritte durchgeführt werden:
-
Der DC muss zuerst im Modus "Verzeichnisdienste wiederherstellen" gestartet werden (F8 beim starten)
-
Nach der Anmeldung ist ein aktuelles System State z.B. mit NTBACKUP vom DC rückzusichern
-
Anschließend darf kein Neustart durchgeführt werden
-
In der Kommandozeile muss NTDSUTIL aufgerufen und folgende Befehle eingegeben werden:
authotitative restore
restore subtree <Distinguished Name der gelöschten OU>
Der Distinguished Name (DN) für eine OU Benutzer direkt unter der Domäne intra.dikmenoglu.de würde so aus:
OU=Benutzer,DC=intra,DC=dikmenoglu,DC=de
-
Zu guter Letzt ist durch Eingabe von „quit“ (insgesamt zweimal) das NTDSUTIL und mit „exit“ die Kommandozeile zu verlassen.
Nach einem Neustart ist die OU erneut im Active Directory verfügbar.
Für eine autoritative Wiederherstellung eines Benutzer-Objekts, muss anstatt „restore subtree DN“,
dass Kommando „restore object DN“ verwendet werden.
Weitere Informationen:
Wie stelle ich das AD wieder her?
Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen
Useful shelf life of a system-state backup of Active Directory
How To Use the Backup Program to Back Up and Restore the System State in Windows 2000
How to perform an authoritative restore to a domain controller in Windows 2000
How to Recover from a Deleted Domain Controller Machine Account in Windows 2000
How to perform a disaster recovery restoration of Active Directory on a computer with a different hardware configuration
Das Geheimnis der Tombstone Lifetime
The effects on trusts and computer accounts when you authoritatively restore Active Directory
HOW TO: Back Up the System State Data of a Remote Computer in Windows 2000
Microsoft hat in den vergangenen Tagen ein überarbeitetes Tool veröffentlicht.
Die Rede ist vom Microsoft Active Directory Topology Diagrammer.
Dieses Tool ist genau das richtige Werkzeug für den Administrator, der quasi auf Knopfdruck ein Diagramm über seine
Active Directory Gesamtstruktur erstellt haben möchte. Das Tool erstellt auf einem Arbeitsplatz, auf dem das Visio 2003
oder 2007 installiert ist, ein Diagramm mit den wichtigen Details einer Active Directory Umgebung.
Die Systemvorrausetzungen um das ADTD zu installieren, wären:
Das Tool liest die Informationen aus dem Active Directory über die ActiveX Data Objects (ADO) Schnittstelle aus und erstellt
automatisch ein Visio-Diagramm. Es bleiben lediglich wenige Handgriffe im Nachhinein notwendig, um das Diagramm fertig zu stellen.
In diesem Diagramm werden Domänen, Standorte, Domänencontroller, OUs, Standortverknüpfungen, GPO-Links, Replikationsverbindungen,
Subnetze, Exchange-Organisation und einiges mehr dargestellt.
Die Installation des ADTD lässt sich recht schnell und einfach durchführen.
Anschließend steht das Tool unter Start – Programme zur Verfügung.
Nach Aufruf des Tools muss zuerst ein Domänencontroller, auf dem der globale Katalog (GC) aktiviert ist eingegeben werden.
Idealerweise wählt man einen GC aus, der sich am gleichen Standort befindet, wie der Arbeitsplatz von dem aus das ADTD ausgeführt wird.
Wenn die Option Use DNS and connect to each Domain im Reiter Domains gewählt wird, bedeutet dies,
dass in jeder vertrauten Domäne ein DC kontaktiert wird.
Auf den einzelnen Reitern gilt es die gewünschten Optionen zu aktivieren.
Wenn die Auswahl der gewünschten Optionen getroffen wurde, gilt es anschließend mit einem Klick auf Discover! die Abfrage zu starten.
Die Abfrage die an den GC gesendet wird, dauert lediglich wenige Sekunden. Dabei entsteht auch keine größere Ressourcen-Beanspruchung
an den GC. Erst beim erstellen des Visio-Diagramms auf der Arbeitsstation, worauf die eigentliche Arbeit durchgeführt wird,
entsteht je nach Größe der Gesamtstruktur einiges an Last.
Wurde die Abfrage abgeschlossen, so wird das Visio-Diagramm mit einem Klick auf Draw! erstellt.
Im fertig gestellten Diagramm bleiben kleinere Handgriffe wie z.B. das verschieben der einzelnen Bilder
oder die farbliche Kennzeichnung der einzelnen Domänen übrig.
Das verschieben sowie die farbliche Kennzeichnung der einzelnen Bilder dieses Diagramms, dass aus einer produktiven Umgebung stammt,
hat weniger als fünf Minuten gedauert. Dabei wandern die Standortverknüpfungen sowie die standortübergreifende Replikationsverbindungen automatisch mit.
Die einzelnen Bilder stellen hier jeweils eine Domäne dar.
Je nachdem welche Optionen bei der Abfrage eingestellt wurden, werden mehr oder weniger Werte angezeigt.
Sei es der Domänenfunktionsmodus, die Anzahl der Benutzer-Objekte, die Anzahl der DCs oder den/die Träger der FSMO-Rollen oder die Schema-Version usw.
Alle diese Informationen können angezeigt werden und decken evtl. den einen oder anderen Konfigurationsfehler auf.
Es lassen sich auch die GPO-Verknüpfungen anzeigen. Man sieht auf welche OU eine GPO verlinkt wurde.
Nur leider fehlt an dieser Stelle, welche GPO an die jeweilige OU verlinkt wurde.
Als besonderes Bonbon werden beim installieren vom ADTD auch noch weitere Visio-Shapes mit installiert,
die später für eigene Diagramme verwendet werden können.
Alles in allem ist das kostenlose Tool eine echte Dokumentationshilfe für den Administrator.
Weitere nützliche Tools:
José: Active-Directory-Dokumentation
Borg: AD-Standorte dokumentieren
Eines der sich immer wiederholenden Aufgaben eines Administrators ist es, Benutzer im Active Directory einzurichten.
Um sich die tägliche Arbeit etwas zu erleichtern, ist es möglich, ein Benutzer- oder inetOrgPerson-Objekt zu kopieren.
Somit ist es mit wenigen Mausklicks möglich, Benutzer, die z.B. in den gleichen Gruppen Mitglied sein sollen oder die
gleichen Firmendaten haben, zu erstellen und somit Zeit zu sparen.
Wird nun ein Benutzer im Snap-In Active Directory-Benutzer und -Computer kopiert (Rechtsklick auf den Benutzer – Kopieren…),
müssen lediglich der Vorname, Nachname, der Benutzeranmeldename sowie ein Kennwort vergeben werden.
Für das einrichten eines Benutzerkontos muss das Konto mit dem die Benutzer eingerichtet werden, entweder Mitglied
der Gruppe Konten-Operatoren, Domänen-Admins oder Organisations-Admins sein. Die entsprechenden Berechtigungen
können natürlich auch über die Objektverwaltung delegiert werden.
Wird nun ein Benutzer-Objekt kopiert, werden nicht alle Informationen kopiert.
Im Active Directory-Schema ist definiert, welche Attribute im einzelnen kopiert werden.
Lediglich die am meisten verwendeten Attribute, wie z. B. die Gruppenmitgliedschaften, Anmeldezeiten,
Konto-Optionen und Adress-Daten werden beim kopieren eines Benutzers übernommen.
Es macht wenig Sinn, Persönliche Daten wie es z.B. der Reiter Rufnummern in den Benutzereigenschaften darstellt, zu kopieren.
Es werden folgende Attribute standardmäßig kopiert.
Im Reiter Adresse wären es: Post-Office-Box, L (Locality-Name), ST (State-Or-Province-Name),
Postal-Code, C (Country-Name), CO (Text-Country), Country-Code.
Das interessante an diesem Reiter ist, dass das Attribut Street-Address nicht mit kopiert wird.
Im Reiter Konto wären es: Account-Expires, Logon-Hours, Logon-Workstation, User-Account-Control (Konto-Optionen).
Im Reiter Mitglied von sind es: Is-Member-Of-DL, Primary-Group-ID.
Im Reiter Organisation: Department, Company, Manager.
Im Reiter Profil: Profile-Path, Script-Path, Home-Directory, Home-Drive.
Es werden noch weitere Attribute kopiert, die nicht in der MMC angezeigt werden.
Diese wären: Assistant, Code-Page, Local-ID, Max-Storage, Postal-Address, Preferred-OU, Other-Login-Workstations und einige mehr.
Andere Attribute wiederum, wie z.B. die Object-GUID oder Object-SID können nicht kopiert werden, da diese einmalig vergeben werden.
Des Weiteren werden auch die Informationen auf diversen Reitern by Design nicht mit kopiert.
Diese wären die Reiter: Einwählen, Remoteüberwachung, Sitzungen, Terminaldiensteprofil sowie Umgebung.
In diesen Reitern werden benutzerspezifische Daten, die im Attribut User-Parameters hinterlegt werden, gespeichert.
Im folgenden Artikel wird gezeigt wie man beeinflussen kann, ob ein Attribut kopiert wird oder nicht.
Dabei ist im Schema-Snap-In, in den Eigenschaften des entsprechenden Attributs, die Option
Attribut wird kopiert, wenn ein Benutzer dupliziert wird zu aktivieren bzw. deaktivieren.
Wie kann ich beeinflussen, welche Attribute beim Kopieren eines Benutzers kopiert werden?
Durch aktivieren oder deaktivieren der Kopieroption, lässt sich das Kopierverhalten von Attributen beeinflussen.
Die Option Attribut wird kopiert, wenn ein Benutzer dupliziert wird steht ohnehin (wenn überhaupt) nur bei
den Attributen zur Verfügung, die zur Benutzerklasse User Class gehören.
Was aber, wenn die Option zum kopieren ausgegraut und somit nicht zur Verfügung steht
(wie z.B. bei den Attributen Description oder Facsimile-Telephone-Number etc.)?
Dann lässt sich das Attribut nicht so ohne weiteres kopieren.
Hinweis: Das dieses Feld ausgegraut ist, ist ein bekannter Fehler des Schema-Snap-Ins und liegt
nicht am Schema selbst. Das liegt einzig und allein an dem Tool das eingesetzt wird.
Ob ein Attribut kopiert wird oder nicht, entscheidet das fünfte Bit im Attribut Search-Flags.
Wenn nun also ein Attribut kopiert werden soll, das standardmäßig nicht mit kopiert wird und das Kopier-Flag ausgegraut ist
(wie es z.B. bei dem Attribut Description der Fall ist), gilt es mit ADSIEdit (aus den Windows Support Tools) in die Schema-Partition
zu navigieren und in den Eigenschaften des gewünschten Attributs, als Wert 16 (Dezimal) bei Search-Flags einzutragen.
Oder man verwendet diese Skripts zum aktivieren bzw. deaktivieren der Kopiermöglichkeit eines Attributs:
http://www.it-administrator.de/magazin/download/ita0703-SearchFlags.zip
Danach ist zwar das Kontrollkästchen bei der Option Attribut wird kopiert, wenn ein Benutzer dupliziert wird weiterhin ausgegraut,
doch nun ist es aktiviert und somit wird das Attribut kopiert. Möchte man dieses rückgängig machen, gilt es als Wert „0“ einzutragen
Weitere Informationen:
Copying Users Does Not Copy All Attributes
The "Attribute is copied when duplicating a user" check box is unavailable in the Active Directory Schema console
When I copy a user account, not all the attributes in the source account are copied to the destination account?
User Object User Interface Mapping
Active Directory: LDAP-Feldnamen
Copying User Accounts
…vergibt Microsoft den MVP-Award für die außerordentliche Leistung in den technischen Communitys.
Im Prinzip kann ich die Worte vom letzten Jahr wiederholen:
[MVP] Herzlichen Glückwunsch! Sie wurden mit dem Microsoft MVP Award ausgezeichnet!
Diesmal aber mit drei Änderungen:
-
Mein Fachbereich ist nun: Windows Server System – Directory Services.
-
Mein Dank an Microsoft, im speziellen an meine beiden MVP-Leads Katrin Letzel und Florian Eichinger,
ist größer als im letzten Jahr  .
-
Aber mein allergrößter Dank für Ihre Geduld und den Rückhalt den ich jederzeit bekomme,
geht weiterhin an meine bezaubernde Ehefrau Aysim.
Sen benim hayatimda oldugun sürece, ne sen kimseye rakip,
Ne de kimse sana rakiptir. Cünkü sen benim icin daima teksin!
Sen benim hayatimda kalmam icin, nefesimsin. Seni canimdan daha cok seviyorum.
Ich freue mich auf ein weiteres Jahr als MVP und hoffe, dass noch viele weitere Jahre folgen werden .
Das kommende Jahr wird allein durch die Einführung des neuen Server-Betriebssystems Windows Server 2008 sehr spannend.
Seit der Einführung des "Active Directory" mit Windows 2000, können standardmäßig "authentifizierte Benutzer" 10 Clients in die Domäne aufnehmen.
Im weiteren Verlauf wird beschrieben, welche beiden Möglichkeiten dem Administrator zur Verfügung stehen um diese Konfiguration zu ändern
und wie die notwendige Berechtigung zum "Hinzufügen der Clients zur Domäne" an die entsprechenden Personen erteilt werden können.
Die Gruppenrichtlinie
In der Default Domain Controllers Richtlinie ist das Benutzerrecht festgelegt, wer Arbeitsstationen zur Domäne hinzufügen darf.
Der Pfad ist folgender:
Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\
Zuweisen von Benutzerrechten\Hinzufügen von Arbeitsstationen zur Domäne
Diese Richtlinie enthält standardmäßig bereits die Gruppe Authentifizierte Benutzer.
Somit ist es jedem Domänen-Benutzer möglich, 10 Clients in die Domäne hinzuzufügen.
Weitere Benutzer und/oder Gruppen können jederzeit in die Richtlinie hinzugefügt werden.
Dieses Verhalten ist aber meistens (wegen der Unternehmensrichtlinie) nicht gewünscht.
Nicht nur, dass der Domänen-Benutzer sein privates Laptop – das nicht den Sicherheitsrichtlinien des Unternehmens entspricht –
mitbringen und zur Domäne hinzufügen könnte, sondern, er kennt bereits das lokale Administrator Kennwort und kann sich damit lokal anmelden.
Danach hat er die Möglichkeit, seinen Domänen-Account (unter Angabe seiner Domänen-Benutzer Daten) der lokalen Gruppe Administratoren hinzufügen.
Um dies zu unterbinden, könnte man aus der o.g. Richtlinie die Gruppe „Authentifizierte Benutzer“
entfernen und lediglich autorisierte Benutzer aus der IT-Abteilung hinzufügen.
Das Kontingent von 10 Arbeitsstationen, wird im Attribut MS-DS-Machine-Account-Quota das sich in den Eigenschaften
der Domänenpartition befindet festgelegt. Dieser Wert lässt sich mit ADSIEdit verändern. Wird im Attribut als Wert "0" eingetragen,
können die in der Richtlinie eingetragenen Benutzer oder Gruppen keine Arbeitsstationen mehr zur Domäne hinzufügen.
Das im Attribut definierte Kontingent, gilt ausschließlich für die Benutzer und Gruppen die in der o.g. Richtlinie definiert sind.
Sie gilt nicht für Benutzer oder Gruppen, die die Berechtigung zum Erstellen von Computerobjekten delegiert bekommen haben.
Wie viele Arbeitsstationen der Benutzer bereits zur Domäne hinzugefügt hat, wird anhand des Attributs MS-DS-Creator-SID,
dass sich in den Eigenschaften der Computerkonten befindet errechnet. In diesem Attribut wird die ObjectSID (als ein "Octet Stream")
des Benutzers eingetragen, natürlich nur, wenn die Grenze des im Attribut MS-DS-MachineAccountQuota eingetragenen Werts (standardmäßig 10)
noch nicht erreicht wurde. Das überprüfen geht recht schnell, da das Attribut MS-DS-Creator-SID indiziert ist.
Wird ein Client der vom Benutzer zur Domäne hinzugefügt wurde aus der Domäne entfernt, deaktiviert sich lediglich das Computerkonto im AD.
Das Computerkonto bleibt jedoch weiterhin im AD bestehen. Erst wenn das Computerkonto aus dem AD gelöscht wird,
kann der Benutzer einen weiteren Client zur Domäne hinzufügen.
Falls aber ein Benutzer dem die Berechtigung "Erstellen von Computerobjekten" delegiert wurde oder ein administratives Konto (Domänen-Admin)
einen Client zur Domäne hinzufügt, erhält anschließend das Attribut MS-DS-Creator-SID im Computerkonto keinen Wert!
Wenn nun ein Client mithilfe des Benutzerrechts "Hinzufügen von Arbeitsstationen zur Domäne" zur Domäne hinzugefügt wurde,
wird als Besitzer des Computerkontos die Gruppe "Domänen-Admins" eingetragen. Das Computerkonto befindet sich
nicht im Besitz desjenigen, der den Client zur Domäne hinzugefügt hat. Natürlich wird aber im Attribut MS-DS-Creator-SID
die ObjektSID des Benutzers eingetragen.
Besitzt ein Benutzer das Recht Hinzufügen von Arbeitsstationen zur Domäne und wurde ihm zusätzlich die Berechtigung zum Estellen
von Computerkonten in der Domäne delegiert, wird der Client basierend auf der delegierten Berechtigung zur Domäne hinzugefügt und nicht
basierend auf dem Benutzerrecht.
Die Erklärung zu der o.g. Richtlinie lautet wie folgt:
Mit dieser Sicherheitseinstellung wird festgelegt, welche Gruppen oder Benutzer Arbeitsstationen zu einer Domäne hinzufügen können.
Diese Sicherheitseinstellung ist nur für Domänencontroller gültig. Standardmäßig besitzt jeder
authentifizierte Benutzer dieses Recht und kann bis zu 10 Computerkonten in der Domäne erstellen.
Durch Hinzufügen eines Computerkontos zur Domäne kann der Computer an der Active Directory-Vernetzung teilnehmen.
Wenn eine Arbeitsstation zum Beispiel einer Domäne hinzugefügt wird, kann diese Arbeitsstation Konten und Gruppen erkennen,
die in Active Directory vorhanden sind.
Standardwert: "Authentifizierte Benutzer" bei Domänencontrollern.
Hinweis: Benutzer, die für den Active Directory-Container "Computer" die Berechtigung zum Erstellen von Computerobjekten
besitzen, können auch in der Domäne Computerkonten erstellen. Der Unterschied ist, dass auf Benutzer, die über Berechtigungen
für den Container verfügen, die Einschränkung zum Erstellen von maximal 10 Benutzerkonten nicht zutrifft. Darüber hinaus sind
die Computerkonten, die mithilfe von "Hinzufügen von Arbeitsstationen zur Domäne" erstellt wurden, im Besitz von
Domänenadministratoren, während bei Computerkonten, die mithilfe der Berechtigungen für den Container "Computer" erstellt wurden,
der Ersteller des Computerkontos der Besitzer ist. Wenn ein Benutzer über Berechtigungen für den Container verfügt und auch das Benutzerrecht
"Hinzufügen von Arbeitsstationen zur Domäne" besitzt, wird der Computer basierend auf den Berechtigungen für den Container "Computer" und nicht
basierend auf dem Benutzerrecht hinzugefügt.
Die Objektdelegierung
Idealerweise delegiert man über die Objektverwaltung in der MMC Active Directory-Benutzer und Computer (dsa.msc) einem Benutzer (besser einer Gruppe) die Berechtigung "Fügt einen Computer einer Domäne hinzu", anstatt die Werte in der o.g. Gruppenrichtlinie zu verändern. Dazu kann man mit einem Rechtsklick auf den Domänennamen in der dsa.msc den Objektdelegierungsassistenten aufrufen. Die entsprechende Berechtigung wird dann durch einen "allgemeinen Task" delegiert.
Diese Vorgehensweise hat aber einen Nachteil. Da der Objektdelegierungsassistent auf "Domänenebene" ausgeführt wurde,
können die Benutzer die diese Berechtigung erhalten haben in der MMC dsa.msc in jedem Container (dazu zählen auch OUs)
Computerkonten erstellen. Für viele Administratoren sind das (zurecht) zu viele Berechtigungen, denn die Benutzer sollen nur die
nötigsten Berechtigungen erhalten. Aber dieser allgemeine Task steht standardmäßig weder auf dem Standard-Container Computers,
noch in einer OU zur Verfügung. Das kommt daher, da in der Datei delegwiz.inf im [template6] lediglich der Eintrag
AppliesToClasses=domainDNS existiert. Dieser Eintrag lässt sich bearbeiten, so das die allgemeine Aufgabe
"Fügt einen Computer einer Domäne hinzu" auch auf dem Standard-Container Computers und
auf OUs zur Verfügung steht. Das würde dann folgendermaßen aussehen:
;----------------------------------------------------------
[template6] <-- ACHTUNG: Bei dieser Vorlage muss auf die Groß- und Kleinschreibung geachtet werden!
AppliesToClasses=domainDNS,organizationalUnit,container
Description="Fügt einen Computer einer Domäne hinzu"
ObjectTypes=SCOPE,computer
[template6.SCOPE]
;Berechtigung um Computerobjekte zu erstellen
computer=CC
[template6.computer]
;Berechtigungen für das Hinzufügen eines Computers zur Domäne
CONTROLRIGHT="Validated write to DNS host name","Account Restrictions","Reset Password","Validated write to service principal name"
;----------------------------------------------------------
Nach der Bearbeitung der Datei kann nun die Delegierung z.B. auf dem Standard-Container Computers
durchgeführt werden. Danach kann der Benutzer der diese Berechtigung erteilt bekommen hat, vom Client aus
diesen zur Domäne hinzufügen.
Der Benutzer kann einen Client auch dann zur Domäne hinzufügen, wenn dieser zuvor vom Domänen-Admin (!)
zur Domäne hinzugefügt und später wieder entfernt wurde. Das Computerobjekt im AD bleibt weiterhin im Besitz
des Domänen-Admins. Jedoch kann der Benutzer der diese Berechtigung erteilt bekommen hat, einen Client der zuvor
vom Domänen-Admin aus der Domäne entfernt wurde, erneut zur Domäne hinzufügen.
Zur Erinnerung: Wird ein Client von der Domäne zu einer Arbeitsgruppe hinzugefügt, bleibt das Computerkonto im AD
bestehen und wird nicht gelöscht!
Wird jedoch diese Berechtigung auf einer OU delegiert, so muss der Benutzer zuerst in der entsprechenden OU
das Computerkonto erstellen und kann erst dann, den Client zur Domäne hinzufügen.
Die Delegierung muss nicht zwangsläufig über den Assistenten eingerichtet werden. Stattdessen kann die Delegierung
auch durch das Bearbeiten der "Discretionary Access Control List (DACL)" des Containers oder mit DSACLS eingerichtet werden.
Für die Delegierung über die DACL, ist nach Hinzufügen des entsprechenden Benutzers oder der Gruppe, im Feld "Übernehmen für"
die Option Dieses und alle untergeordneten Objekte auszuwählen. Bei den Berechtigungen gilt es dann
die Option "Computer" erstellen zuzulassen. Auch hierbei gilt, wird die Delegierung im Standard-Container Computers eingerichtet,
kann der Benutzer den Client vom Client aus zur Domäne hinzufügen. Andernfalls muss zuerst das Computerkonto in der OU erstellt werden,
ehe der Client zur Domäne hinzugefügt werden kann.
Objektdelegierungen einrichten
Benutzer die über diese Berechtigung verfügen, können unbegrenzt Clients zur Domäne hinzufügen.
Versierte Administratoren können diese Berechtigung (Computerobjekte erstellen) natürlich auch automatisiert mit DSACLS vergeben.
Weitere Informationen:
Der Objektdelegierungsassistent
Delegierte Berechtigungen im AD verstehen
Delegierte AD-Berechtigungen anzeigen und entfernen
Default Limit to Number of Workstations a User Can Join to the Domain
Domain Users Cannot Join Workstation or Server to a Domain
"You Have Exceeded the Maximum Number of Computer Accounts" Error Message When You Try to Join a Windows XP Computer to a Windows 2000 Domain
|
Copyright © 2013 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|