…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
Eines der vielen Aufgaben eines Administrators ist, Ordnung in seinem Netzwerk zu halten. Dazu gehört unter anderem,
Mitarbeiter die das Unternehmen verlassen haben aus dem Active Directory zu löschen (oder mindestens zu deaktivieren).
Ebenso bei ausgemusterten Clients, die Computerobjekte aus dem Active Directory zu entfernen.
Möchte man nun ein Computerkonto aus dem Active Directory entfernen, könnte es zu folgender Meldung kommen:
Object <Computername> is a container and contains other objects. Are you sure you want to delete object <Computername> and
the objects it contains? This operation could take a long time if <Computername> contains a large number of objects.
Diese Meldung bedeutet, dass das Computerkonto Unterobjekte enthält.
Der eine oder andere wird sich vielleicht fragen, wie das sein kann. Ein Computerkonto das sich etwa wie eine OU verhält?
Es reicht zum Beispiel auf dem XP-Client den Message Queuing Dienst (genauer: Integration in das Active Directory) zu installieren,
um ein neues Objekt unter dem Computerobjekt zu erhalten.
Oftmals ist es aber lediglich ein im Verzeichnis freigegebener Drucker an dem Client.
Um das zu überprüfen muss man nicht unbedingt ADSIEdit, einen LDAP-Browser oder den Active Directory Explorer verwenden, sondern,
im Snap-In Active Directory-Benutzer und -Computer einfach unter ANSICHT die Option Benutzer, Gruppen und Computer als Container aktivieren.
Danach werden die Computerobjekte als Container dargestellt und falls diese weitere Objekte enthalten, kommen diese somit zum Vorschein.
Wenn nun also die o.g. Meldung erscheint, gilt es zuerst wie in diesen beiden Fällen genannt,
zuerst den Message Queuing Dienst (unter Systemsteuerung – Software) zu deinstallieren oder die Druckerfreigabe zu entfernen.
Die Objekte lassen sich auch mit ADSIEdit oder dem Active Directory Explorer löschen.
Danach lässt sich das Computerkonto ohne eine Meldung entfernen.
Wie lassen sich veraltete Computerkonten aufspüren?
Clients die sich seit dem Zeitraum x nicht mehr an der Domäne angemeldet haben, lassen sich im Domänenfunktionsmodus
Windows Server 2003 mit DSQUERY aufspüren. Bei der Abfrage mit DSQUERY, werden die Computerkonten die ihr Kennwort
seit dem angegebenen Wert nicht geändert haben ermittelt. Standardmäßig wird das Computerkontokennwort ab Windows 2000
alle 30 Tage geändert (unter NT sind es 7 Tage), daher sollte ein höherer Wert für die Abfrage gewählt werden.
Mit dem folgenden Befehl werden alle Computerkonten angezeigt, die seit 70 Tagen ihr Kennwort nicht geändert haben:
dsquery computer -stalepwd 70
Zusammen mit DSRM lassen sich die ermittelten Computerkonten automatisch löschen. Der Befehl lautet wie folgt:
dsquery computer -stalepwd 70 | dsrm -noprompt -c
Das Computerkontokennwort wird aber nur geändert, wenn der Client Verbindung zur Domäne hat. Ist der Client wie es
z.B. bei Laptops der Fall sein kann monatelang unterwegs und hat somit keine Verbindung zur Domäne, ändert sich
das Kennwort nicht automatisch nach 30 Tagen. Erst wenn sich der Client das nächste Mal an der Domäne authentifiziert,
erhält der Client ein neues Computerkontokennwort.
Wie lassen sich veraltete Computerkonten entfernen?
Wie bereits oben erwähnt, lassen sich veraltete Computerkonten mit DSQUERY in Verbindung mit DSRM entfernen.
Microsoft bietet ein Skript an, um veraltete Computerkonten zu entdecken sowie zu entfernen.
How to detect and remove inactive machine accounts
Mit dem Tool von Joe Richard OldCMP lassen sich ebenfalls veraltete Computerkonten entfernen.
Richard Mueller bietet dazu folgendes Skript an Move Old Computers.
Mit der AD-PowerShell lassen sich deaktivierte und alte Computerkonten wie folgt aufspüren bzw. löschen
Alte oder deaktivierte Computerkonten mit der AD-PowerShell löschen
Möchte man die letzte Anmeldung eines Benutzers herausfinden, so führen zu diesem Vorhaben mehrere Wege zum Ziel.
Die benötigte Information lässt sich wie vieles (aufwändig) über das ADSI auslesen.
Das Attribut in dem die letzte Anmeldung gespeichert wird, lautet Last-Logon.
Der Nachteil an diesem Attribut ist, dass es nicht zwischen den Domänencontrollern repliziert wird.
Es gilt also das Attribut Last-Logon auf jedem Domänencontroller in der Domäne abzufragen um das aktuellste Datum herauszufinden.
Additional Account Info - AcctInfo.dll
Eine recht einfache Möglichkeit wäre (unter Windows 2000/2003/2008), sich die Account Lockout and Management Tools herunterzuladen
und die AcctInfo.dll zu nutzen. Diese DLL muss vorher registriert werden. Dazu extrahiert man zuerst die heruntergeladene Datei in ein
Verzeichnis (z.B. C:\Tools), öffnet eine Kommandozeile (CMD) und navigiert zu den entpackten Dateien. Anschließend registriert man mit
folgendem Befehl die DLL: regsvr32 acctinfo.dll. Danach erscheint im Snap-In Active Directory-Benutzer und -Computer in den
Eigenschaften der Benutzer ein weiterer Reiter. Dieser neue Reiter zeigt unter anderem die letzte Benutzeranmeldung an:
Hinweis: Wenn ein Benutzer in der MMC über eine Suche aufgerufen wird, ist dieser Reiter nicht zu sehen.
Dieser Reiter erscheint lediglich auf dem Arbeitsplatz/Server, auf dem die DLL registriert wurde. Um den Reiter zu entfernen,
muss der Befehl (über Start – Ausführen) regsvr32 /u <Pad zur AcctInfo.dll> ausgeführt werden.
Das Attribut Last-Logon-Timestamp
Wie vieles andere wurde auch dieses Verhalten in Windows Server 2003 verbessert.
Im Schema des Windows Server 2003 wurde ein neues Attribut namens Last-Logon-Timestamp dem Benutzer-Objekt hinzugefügt.
Wenn sich die Domäne mindestens im Domänenfunktionsmodus Windows Server 2003 befindet, kann man das Attribut Last-Logon-Timestamp nutzen.
Dieses Attribut ist aber vom Attribut Last-Logon abhängig. Würde z.B. bei einer Benutzer-Anmeldung das Attribut Last-Logon nicht gesetzt,
wird auch das Attribut Last-Logon-Timestamp nicht aktualisiert. Es bietet allerdings den Vorteil, dass es auf andere DCs repliziert wird und somit
einem das durchsuchen aller DCs erspart bleibt. Jedoch wird Last-Logon-Timestamp (um die Replikationslast gering zu halten) standardmäßig alle 14 Tage,
abzüglich einer zufällig gewählten Differenz von bis zu 5 Tagen aktualisiert. Das Attribut wird also zwischen zehn und vierzehn Tagen repliziert.
Wird nun das Attribut Last-Logon aktualisiert, überprüft der DC ob das Aktualisierungsintervall das in dem Attribut ms-DS-Logon-Time-Sync-Interval
angegeben ist, erreicht wurde, um dann Last-Logon-Timestamp zu aktualisieren.
Das Aktualisierungsintervall von Last-Logon-Timestamp wird im Attribut ms-DS-Logon-Time-Sync-Interval gesteuert.
Dieses Attribut befindet sich in den Eigenschaften der Domänenpartition und lässt sich z.B. mit ADSIEdit bearbeiten.
Der Wert dieses Attributs ist standardmäßig <Not Set> und bedeutet einen Standardwert von 14 Tagen.
Dieser Wert kann zwischen 1 und 100.000 Tage betragen. Trägt man als Wert 0 ein, wird das Attribut Last-Logon-Timestamp nicht mehr aktualisiert.
Ein zweimonatiger Test mit 50 Benutzerkonten in einer produktiven Umgebung hat ergeben, dass die Aktualisierung von Last-Logon-Timestamp
(mit einem Standardwert im Attribut ms-DS-Logon-Time-Sync-Interval) bei 80% der Benutzerkonten, ausgeglichen zwischen zehn und elf Tagen lag.
Wenn ein DC unter Windows Server 2003 (ohne SP1) läuft, kann es unter Umständen vorkommen, dass dieses Attribut nicht aktualisiert wird:
A network logon that uses NTLM authentication does not update the lastLogonTimestamp attribute in the Active Directory schema of a Windows Server 2003-based domain controller
Sowohl das Attribut Last-Logon, als auch Last-Logon-Timestamp, sind Integer8 Datentypen.
Diese haben eine Länge von 8 Byte bzw. 64 Bit. Die Zeit wird ab dem 1. Januar 1601 12:00 AM im 100 Nanosekunden Intervall berechnet.
Der Wert aus Last-Logon oder Last-Logon-Timestamp wird in der Greenwich Mean Time (GMT) Zone im Active Directory gespeichert und muss
in ein leserliches Datumsformat konvertiert werden, da man ansonsten mit dem Wert (der in etwa so aussieht: 128362271633877741) nicht
sonderlich viel anfangen kann. Zum konvertieren gibt man in der Kommandozeile den Befehl w32tm /ntte <Wert> ein.
Benutzer die sich länger nicht an der Domäne angemeldet haben
Benutzerkonten die sich seit längerem an der Domäne nicht authentifiziert haben, lassen sich recht schnell auf verschiedene Weise herausfinden.
Hinweis: Die folgenden Beispiele benötigen die Domänenfunktionsebene Windows Server 2003!
1. Das Snap-In Active Directory-Benutzer und –Computer (ADBuC)
In der MMC ADBuC kann man sich eine Allgemeine Abfrage durch eine Suche (Rechtsklick auf die Domäne) oder durch eine Gespeicherte Abfrage erstellen.
Dort gilt es die Auswahl bei der Option Tage seit der letzten Anmeldung zwischen 30, 60, 90, 120 oder 180 zu treffen.
Der Wert ist nicht frei definierbar sondern fest vorgegeben:
2. Dsquery
Mit einem der DS*-Tools die standardmäßig ab Windows Server 2003 integriert sind, lässt sich eine einfache Abfrage erstellen.
Die Rede ist von DSQUERY. Die Abfrage z.B. in einer Kommandozeile, könnte wie folgt aussehen:
dsquery user domainroot –inactive <Anzahl der Wochen>
Damit werden alle Benutzerkonten der Domäne, die während der angegebenen Anzahl an Wochen (oder länger) nicht angemeldet waren angezeigt.
Hinweis: Die Abfrage in ADBuC sowie Dsquery nutzen bei der Abfrage das Attribut Last-Logon-Timestamp.
3. Ab Windows Server 2008 und Windows Vista steht eine weitere Option zur Verfügung, um die letzte interaktive Domänenanmeldung herauszufinden:
Die letzte interaktive Domänenanmeldung anzeigen
4. Mit der AD-PowerShell kann man sich ebenfalls das letzte Anmeldedatum der Benutzer ausgeben lassen. Dazu muss eine Abfrage nach "LastLogonDate" durchgeführt werden. Diese Eigenschaft liest den Wert aus dem Attribut LastLogonTimeStamp aus. Der Befehl lautet:
Get-ADUser -Filter * -Properties LastLogonDate | Sort-Object -Property LastLogonDate -descending | FT -Property Name, LastLogonDate -A
AD-PowerShell Befehle
Weitere Beispiele
Wie bekomme ich heraus, wann ein User sich zuletzt ans AD angemeldet hat?
Die Scipting-Guys haben dazu zwei Artikel veröffentlicht:
http://www.microsoft.com/technet/technetmag/issues/2006/01/ScriptingGuy/default.aspx
http://www.microsoft.com/technet/scriptcenter/topics/win2003/lastlogon.mspx
How can I report all inactive user accounts, and optionally disable them?
TRUELAST.EXE freeware outputs the last logon time a particular user logged onto the current or a specified domain
The Windows Server 2003 Active Directory lastLogonTimeStamp attribute is replicated across all domain controllers
Using the lastLogonTimestamp attribute in Windows Server 2003
Weitere Informationen:
Account Info DLL Version 2
Einen Large Integer Wert umrechnen
The lastLogon attribute is not updated when a client computer runs an LDAP simple bind operation against a Windows Server 2003-based domain controller
Steht eine Domänenaktualisierung von Windows 2000 auf Windows Server 2003/2003 R2 oder auf Windows Server 2008/2008 R2 bevor,
sei es durch ein Inplace-Upgrade oder durch das Hinzufügen des ersten Windows Server 2003/2003 R2/2008/2008 R2 Domänencontroller zur Gesamtstruktur,
so gilt es zuerst das AD-Schema zu aktualisieren.
Doch bevor dieser Schritt durchgeführt wird, wäre es empfehlenswert die Ausgangssituation zu überprüfen.
Die Active Directory- sowie die NTFRS/DFSR- Replikation sollte und muss ohnehin ordnungsgemäß auf allen Domänencontrollern funktionieren.
Das Verzeichnisdienstprotokoll auf den Domänencontrollern sollte weder Warnungen, noch Fehler vorweisen.
Diverse Tests mit den Tools DCDIAG, NetDIAG, FRSDiag sowie REPADMIN sind einem beim sicherstellen der fehlerfreien Funktion der DCs sowie der Replikation hilfreich.
Die genannten Tools befinden sich bis einschließlich Windows Server 2003 in den Windows Support Tools und sind ab Windows Server 2008 bereits "on Bord."
Was noch alles zu beachten und auszuführen wäre, erfährt man aus diesen Artikeln:
Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
Den einzigen Domänencontroller austauschen
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
Hinweis zu Exchange
Wenn ein Exchange 2000 Schema in der Gesamtstruktur vorhanden ist, so ist zuerst die Exchange Schema-Erweiterung zu „korrigieren“.
Dazu wird die Datei InetOrgPersonfix.ldf benötigt, die sich in der Archiv-Datei Support.cab im Verzeichnis „Support\Tools\" auf der
Windows Server 2003 CD befindet. Diese Archiv-Datei gilt es zu entpacken und anschließend mit LDIFDE ins Schema zu importieren.
Der Befehl dazu lautet:
Ldifde.exe /i /f inetOrgPersonFix.ldf /c "DC=X" "DC=Domäne,DC=TLD".
Führt man diesen Schritt vorher nicht aus, würde es zu entstellten Attributen kommen:
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
Soll im Zuge der AD Migration gleichzeitig auch ein Update auf Exchange 2003 erfolgen, so ist es einfacher,
erst das Exchangesetup mit dem Schalter /Forestprep durchzuführen. Der oben beschriebene Fix wird dadurch unnötig.
Hinweis: Im weiteren Verlauf ist zwar die Rede von "Windows Server 2003", doch die einzelnen Schritte gelten auch für neuere Serverbetriebssystemversionen.
Das Ausführen von ADPREP
Wenn alles soweit in Ordnung ist, kann die eigentliche Schemaaktualisierung durchgeführt werden.
Dazu ist das Active Directory Preparation Tool (kurz ADPREP) von der Windows Server 2003 CD zum einen auf dem Schemamaster
und zum anderen auf dem Infrastrukturmaster der jeweiligen Domäne, mit jeweils anderen Parametern auszuführen.
Alle Windows 2000 Domänencontroller in der Gesamtstruktur sollten idealerweise das aktuelle Service Pack 4 und alle weiteren Updates installiert haben.
Prepare Your Infrastructure for Upgrade
Hotfixes to install before you run adprep /Forestprep on a Windows 2000 domain controller to prepare the Forest and domains for the addition of Windows Server 2003-based domain controllers
Im ersten Schritt, muss zuerst die Gesamtstruktur mit dem Befehl ADPREP /Forestprep auf dem Domänencontroller,
der die Rolle des Schemamaster innehat, auf eine Windows Server 2003 Gesamtstruktur aktualisiert werden.
Würde die Gesamtstruktur (oder Domäne) nicht auf Windows Server 2003 aktualisiert werden, würde der Active Directory-Assistent DCPROMO
beim Heraufstufen des ersten Windows Server 2003/R2 zum Domänencontroller an entsprechender Stelle bzgl. des ADPREP`s einen Fehler melden.
Danach hat man immer noch Zeit das ADPREP auszuführen um anschließend mit dem Heraufstufen des Servers fortzufahren.
Im zweiten Schritt ist das ADPREP mit dem Parameter /Domainprep /GPPREP auf dem Infrastrukturmaster in der Domäne, in der man
den neuen Windows Server 2003 DC hinzufügen möchte auszuführen. Somit wird die Domäne auf Windows Server 2003 aktualisiert.
Wenn man ab Windows Server 2008 einen Read Only Domain Controller (RODC) zur Domäne hinzufügen möchte, so sollte der Befehl ADPREP /RODCPREP auf einem Infrastrukturmaster ausgeführt werden.
Falls das ADPREP in einer Gesamtstruktur oder Domäne nicht ausgeführt wurde, so wird während dem Heraufstufen eines DCs eine Fehlermeldung
bzgl. ADPREP angezeigt und der Vorgang bleibt stehen. Danach kann man jederzeit das ADPREP nachholen und anschließend mit dem Heraufstufen
des DCs fortfahren.
Wie stellt man nun sicher, dass die Änderungen die auf dem Schemamaster mit ADPREP /Forestprep durchgeführt wurden,
auch auf allen Domänencontrollern in der Gesamtstruktur repliziert wurde?
Mit dem Ausführen von ADPREP /Domainprep /GPPREP muss solange gewartet werden, bis die durch ADPREP /Forestprep
vorgenommenen Änderungen vom Schemamaster, auf den Infrastrukturmaster (in der Domäne, in der man den neuen
Windows Server 2003 hinzufügen möchte) repliziert worden ist.
Wenn ADPREP erfolgreich (oder nicht) durchgeführt wurde, wird das in der Kommandozeile angezeigt.
Auf dem Schema-Master wird in der Konfigurationspartition die folgenden beiden Container erstellt und
diese müssen auf allen DCs in der Gesamtstruktur repliziert werden:
CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.
CN=Operations,CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.
Mit Ausführen von Adprep /Forestprep werden 36 Änderungen in der CN=Configuration und CN=Schema Verzeichnispartition des Schemamasters durchgeführt.
Für jede Operation die durch den Befehl ADPREP /Forestprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations.
Jede GUID stellt eine Operation dar.
Wenn alle 36 Operationen erfolgreich durchgeführt wurden, wird anschließend der folgende Container erstellt:
CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC= Domäne,TLD.
Im Container CN=Windows2003Update muss das Attribut Revision den Wert 9 enthalten.
Das ADPREP /Forestprep wird nur einmal auf dem Schemamaster in der Gesamtstruktur ausgeführt.
Welche Änderungen im Detail ausgeführt werden, zeigt dieser Artikel:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest
Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!
Was wird mit ADPREP /Domainprep durchgeführt?
Es werden 50 Änderungen auf dem Infrastrukturmaster vorgenommen.
Auf dem Infrastrukturmaster wird in der Domänenpartition die folgenden beiden Container erstellt und diese müssen auf allen DCs in der Domäne repliziert werden:
CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
Für jede Operation die durch den Befehl ADPREP /Domainprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
Jede GUID stellt eine Operation dar. Im Container CN=Windows2003Update muss das Attribut Revision den Wert 8 enthalten.
Das ADPREP /Domainprep muss in jeder Domäne, in der ein Windows Server 2003 hinzugefügt werden soll, auf dem Infrastrukturmaster ausgeführt werden.
Für detailierte Infos siehe:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest
Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!
Was macht der Befehl ADPREP /Domainprep /Gpprep?
Dieser Befehl steht ab Windows Server 2003 zur Verfügung und ist bei einer Domänenaktualisierung von Windows 2000 zwingend auszuführen!
Er führt das gleiche wie der Befehl ADPREP /Domainprep aus. Zusätzlich wird durch den Parameter /Gpprep
den Gruppenrichtlinienobjekten im SYSVOL-Verzeichnis vererbbare Zugriffssteuerungseinträge hinzugefügt.
Gibt es etwas vor dem Ausführen von ADPREP zu beachten?
Das Windows 2000 Active Directory-Schema muss eine Schemaaktualisierung zulassen:
Schema Updates Require Write Access to Schema in Active Directory
Des Weiteren wurde in früheren Microsoft-Artikeln empfohlen, den Schemamaster vor dem Ausführen von ADPREP /Forestprep vorübergehend
in ein privates Netzwerk zu isolieren bzw. „offline“ zu nehmen. In der Praxis hat sich diese Vorgehensweise eher als Nachteil erwiesen.
Denn die Schemaänderungen wurden teilweise nach dem Neustart des Schemamasters „zurückgewiesen“.
Wenn man dennoch den Schemamaster vor dem Ausführen von ADPREP /Forestprep isolieren möchte,
dann wäre es empfehlenswert die ausgehende Active Directory-Replikation vorübergehend zu deaktivieren.
Die AD-Replikation lässt sich mit REPADMIN aus den Windows Support Tools deaktivieren. Der Befehl dazu lautet:
REPADMIN /Options +DISABLE_OUTBOUND_REPL
Nach dem Ausführen von ADPREP /Forestprep ist folgendes zu prüfen:
-
Der Befehl Adprep /Forestprep wurde ohne Fehler in der Kommandozeile ausgeführt.
-
Der Container CN=Windows2003Update wurde unter "CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD" erstellt.
Der Wert des Attributs Revision im Container CN=Windows2003Update muss 9 sein.
-
Die Schemaversion wurde auf Version 30 bzw. 31 erhöht. Überprüfen lässt sich die Schema-Version entweder durch die Registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\“SchemaVersion“ (die Zahl in Klammern gibt die Version an)
oder durch das Attribut
ObjectVersion das sich unter "CN=Schema,CN=Configuration,DC=Domäne.TLD befindet.
Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
Vorausgesetzt dass der Vorgang erfolgreich durchgeführt wurde, ist anschließend die ausgehende Replikation zu aktivieren.
Dazu muss der folgende Befehl in der Kommandozeile ausgeführt werden:
REPADMIN /Options -DISABLE_OUTBOUND_REPL
How to upgrade Windows 2000 domain controllers to Windows Server 2003
Von welcher CD/DVD muss das ADPREP ausgeführt werden?
Das ADPREP muss immer von der Server-CD ausgeführt werden, auf die man aktualisieren möchte.
Das ADPREP befindet sich auf der Windows Server 2003 CD im Verzeichnis CD-Laufwerk:\i386.
Ist der neue DC ein Windows Server 2003 R2, so muss das ADPREP von der zweiten R2-CD aus dem Verzeichnis CD-Laufwerk:\CMPNENTS\R2\ADREP ausgeführt werden.
Unter Windows Server 2008 befindet sich das ADPREP im Verzeichnis: <DVD-Laufwerk>:\Sources\Adprep
Und unter Windows Server 2008 R2 im Verzeichnis: <DVD-Laufwerk>:\Support\Adprep. Achtung: Unter Windows Server 2008 R2 gibt es zwei ADPREP-Versionen.
Eine Version lautet Adprep.exe, mit der man das AD-Schema auf einem x64Bit DC aktualisieren muss. Die andere Version lautet Adprep32.exe, mit der man das AD-Schema auf einem x32Bit DC aktualisieren muss.
Wird hingegen der erste Windows Server 2003 R2 in der 64Bit Version einer 32Bit Windows 2000/2003 Gesamtstruktur hinzugefügt,
so muss von Microsoft entweder ein Hotfix angefordert oder die 32Bit-Trial Version heruntergeladen und von dort das ADPREP ausgeführt werden.
Siehe dazu: Schemaupdate beim Windows Server 2003 R2
Wenn der erste SBS 2003 oder SBS 2003 R2 hinzugefügt werden soll, dann ist das ADPREP von der ersten SBS-CD, im Verzeichnis i386 auszuführen.
In welchen Gruppen muss das Benutzerkonto mit dem das ADPREP ausgeführt wird, Mitglied sein?
Das Benutzerkonto mit dem das ADPREP ausgeführt wird, muss beim ausführen des Parameters /Forestprep Mitglied in den Gruppen
Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.
Oder die entsprechenden Berechtigungen müssen dem Benutzerkonto delegiert worden sein.
Beim ausführen von ADPREP mit dem Parameter /Domainprep oder /Domainprep /Gpprep muss das Benutzerkonto Mitglied in der Gruppe
Domänen-Admins sein. Die Delegierung der entsprechenden Berechtigungen an das Benutzerkonto wäre ebenfalls möglich.
Für das Ausführen von ADPREP /RODCPREP muss das Benutzerkonto Mitglied in der Gruppe Organisations-Admins sein.
Auf welche Schema-Version wird das Schema aktualisiert?
Die Schema-Version lässt sich in der Registry (das es unter Start-Ausführen-Regedit aufzurufen gilt) des DCs überprüfen.
Anschließend navigiert man zu folgendem Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters.
Dort kontrolliert man den Eintrag "Schema Version". Die Zahl in Klammern, gibt die Schema-Version an.
Diese wären:
- (13) = Windows 2000 (ohne/mit allen SPs)
- (30) = Windows Server 2003 ohne/mit SP1/SP2 (und höhere SPs)
- (31) = Windows Server 2003 R2 ohne/mit SP2 (und höhere SPs)
- (44) = Windows Server 2008
- (47) = Windows Server 2008 R2
Die Schema-Version lässt sich ebenfalls mit ADSIEdit oder dem Active Directory Explorer überprüfen.
Das zu überprüfende Attribut lautet objectVersion und befindet sich im Container:
CN=Schema,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>.
Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
Gibt es auch ein Protokoll vom ADPREP?
Es wird ein ADPREP-Protokoll im Verzeichnis %Systemroot%\System32\Debug\Adprep\Logs
erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
Weitere wichtige Informationen
When you run the "Adprep /forestprep" command to prepare Windows 2000 Active Directory for Windows Server 2003, the forest preparation operation fails
Aktualisieren von einer Windows 2000-Domäne
Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
Upgrading from Windows 2000 Server to Windows Server 2003
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|