Es ist empfehlenswert, dass jedes Unternehmen eine Kennwortrichtlinie einsetzt, die entsprechend konfiguriert ist
(Komplexität, Kennwortchronik, Kennwortlänge, Kennwortalter etc.).
Kennwortrichtlinien, die für Domänen-Benutzer gelten sollen, müssen auf Domänenebene verlinkt werden. Wenn eine Kennwortrichtlinie auf einer Organisationseinheit (OU) verlinkt wird, betrifft das lediglich die lokalen Benutzerkonten auf den Clients. Bis Windows Server 2003 kann es dabei pro Domäne nur eine Kennwortrichtlinie geben. Besteht der Bedarf für einen Standort eine eigene Kennwortrichtlinie zu definieren, so musste für diesen Standort eine Sub-Domäne erstellt werden. Anders war dieses Ziel mit Bordmitteln nicht lösbar. Erst ab Windows Server 2008 lassen sich mehrere Kennwortrichtlinien pro Domäne mit Bordmitteln einrichten und nennen sich dort "Password Settings Objects" kurz PSO. In einer Windows Server 2003 Umgebung kann man mehrere Kennwortrichtlinien pro Domäne nur mit Dritt-Anbieter Tools realisieren, wie z.B. Specops Password Policy oder nFront Password Filter.
Möchte ein Unternehmen das bisher keine Kennwortrichtlinie im Einsatz hatte, dieses nun nachholen, sollte die Einführung einer Kennwortrichtlinie sorgfältig geplant und die Benutzer ausführlich informiert werden. Es ist ratsam nach der Konfiguration der Kennwortrichtlinie, im Reiter Konto die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ in allen Benutzerkonten zu aktivieren. Denn schließlich existierte bisher keine Sicherheitsanforderung bei der Kennwortwahl, so dass es höchste Zeit wird dieses schnellstmöglich zu aktivieren.
Ist allerdings eines der Flags im userAccountControl Attribut, nämlich die Option „Kennwort läuft nie ab“ aktiviert, so ist ein zusätzliches aktivieren der Option Benutzer muss Kennwort bei der nächsten Anmeldung ändern nicht möglich. Es dürfte jedem klar sein, dass sich diese beiden Optionen widersprechen. Wird die Option „Kennwort läuft nie ab“ aktiviert, so wird mit einem Hinweis die evtl. bereits aktivierte Option „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ deaktiviert.
Wird in den Kennwortrichtlinien die Einstellung „Maximales Kennwortalter“ konfiguriert, so kann es passieren, dass die Benutzer bei ihrer nächsten Anmeldung aufgefordert werden ihr Kennwort zu ändern, ohne dass die Option „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ gesetzt ist. Denn angenommen ein Benutzer verwendet sein Kennwort, das bereits 200 Tage alt ist und es wird ein maximales Kennwortalter von 180 Tagen definiert, so erhält dieser Benutzer bei seiner nächsten Domänenanmeldung die Aufforderung sein Kennwort zu ändern. Das Alter des Kennworts wird vom Attribut Pwd-Last-Set errechnet. In dem Attribut wird ein 64Bit Integer Wert des Zeitpunkts der letzten Kennwortänderung gespeichert. Umrechnen lässt sich dieser Wert mit dem Befehl: w32tm /ntte <Wert>.
Es gibt aber eine Option, die verhindert, dass nach der Konfiguration eines maximalen Kennwortalters die Benutzer mit einem älteren Kennwort dies nicht bei der nächsten Domänenanmeldung ändern müssen.
-
In den Benutzerkonten ist zuerst die Kontooption Benutzer muss Kennwort bei der nächsten Anmeldung ändern zu aktivieren.
-
Danach gilt es die gewählte Option mit Übernehmen zu bestätigen.
-
Anschließend muss die soeben aktivierte Kontooption erneut deaktiviert und mit Übernehmen oder OK bestätigt werden.
Wird in den Eigenschaften eines Benutzerkontos im Reiter Konto die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ gesetzt, so erhält das Attribut pwdLastSet im entsprechenden Benutzerobjekt den Wert „0“. Wenn anschließend der Haken wieder entfernt wird, erhält das Attribut als Wert, dass Datum sowie die Uhrzeit von dem Moment, in dem diese Einstellung durchgeführt wurde.
In den Benutzerobjekten lässt sich die Kontooption z.B. durch ein Skript aktivieren oder deaktivieren. Eine andere Variante wäre zuerst die Benutzer mit STRG auszuwählen, dann mit einem Rechtsklick auf die Benutzerobjekte die Eigenschaften aufzurufen, um danach im Reiter Konto die entsprechende Option auszuwählen bzw. zu deaktivieren.
Verifizieren kann man das durch Überprüfen des Attributs pwdLastSet im Benutzerobjekt, mit dem Befehl: w32tm /ntte <Wert aus pwdLastSet>.
Dort sollte dann das aktuelle Datum stehen.
Wann das Kennwort zuletzt gesetzt wurde, kann man auch wie folgt kontrollieren: Net User <username> /Domain.
Oder mit der Account Info DLL (kurz Acctinfo.dll).
Zum dritten Mal in Folge, wurde mir von Microsoft der Titel Most Valuable Professional - MVP verliehen.
Gerade der Launch des Windows Server 2008 im Februar diesen Jahres in Frankfurt am Main, war ein Highlight!
Es war für mich ein spannendes und sehr aufregendes Erlebnis als ATE bei dem Launch dabei zu sein, was mir richtigen Spaß bereitet hat.
Die vielen Diskussionen rund um Active Directory (insbesondere der RODC) und Grobkonzepte bei der Migration zu Windows Server 2008 waren sehr amüsant.
Auch erlebe ich täglich viele und interessante Diskussionen im Internet.
Zum einen in den Microsoft-Newsgroups und zum anderen, im MCSEboard.de, wo ich täglich anzutreffen bin.
Hiermit lade ich jeden herzlich ein, sich bei Problemen an eine dieser Communities zu wenden oder einfach selbst mitzumachen, um anderen zu helfen.
In beiden Communities sind viele Experten sowie MVPs aus verschiedenen Fachbereichen anzutreffen.
Willkommen bei den Microsoft Newsgroups
MCSEboard.de
Ich freue mich sehr über den Re-Award zum MVP und kann mich wie in den beiden vergangenen Jahren nur wiederholen:
Alle Jahre wieder…
[MVP] Herzlichen Glückwunsch! Sie wurden mit dem Microsoft MVP Award ausgezeichnet!
Vielen Dank Microsoft und ich hoffe es werden noch viele weitere Jahre als MVP folgen. 
Die Active Directory-Replikation ist ein komplexer Vorgang, die regelmäßig (um nicht zu sagen ständig) kontrolliert werden sollte.
Falls es zwischen Domänencontrollern zu Replikationsproblemen kommt, helfen neben der Ereignisanzeige in erster Linie die beiden
Tools REPADMIN sowie REPLMON bei der Suche nach der Fehlerquelle.
Gerade das Kommandozeilentool REPADMIN, das sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools
und im Windows Server 2008 bereits im Betriebssystem befindet, ist ein mächtiges Tool das mit vielen Parametern ausgestattet ist.
Nun hat Microsoft speziell für dieses Tool ein Whitepaper veröffentlicht, in dem das Tool mit all seinen Parametern erläutert wird.
Weiterhin werden auch Szenarien beschrieben, in denen REPADMIN helfen kann.
Hier kann das Whitepaper heruntergeladen werden:
Troubleshooting replication with Repadmin
Weitere Informationen:
Windows 2000 Service Pack 4 Support Tools
Windows Server 2003 Service Pack 2 32-bit Support Tools
Standardmäßig werden in der MMC Active Directory-Benutzer und -Computer (ADBuC) die drei Spalten Name, Typ und Beschreibung angezeigt.
In der MMC lassen sich unter Ansicht - Spalten hinzufügen/entfernen… in Windows 2000 sowie Windows Server 2003 weitere 22 und unter
Windows Server 2008 weitere 27 Spalten einblenden.
Nun ist es seit Windows Server 2003 möglich eigene Spalten in der MMC dsa.msc zu integrieren. Dafür ist ein Windows Server 2003
oder Windows Server 2008 Schema notwendig. Somit hat man dann die Möglichkeit die in keinem Feld angezeigten, jedoch im Schema
existierenden Attribute (wie z.B. employeeID) doch in einer Spalte zum Vorschein zu bringen. Natürlich können dabei auch eigene Attribute
die durch eine Schemaerweiterung hinzugefügt wurden, in der MMC angezeigt werden. Die Werte in den Attributen sind allerdings auf einem
anderen Weg einzutragen. Entweder skriptbasiert oder manuell (z.B. mit ADSIEdit). Im Fall der Personalnummer lässt sich das durch die in dem
folgenden Artikel gezeigte Vorgehensweise erledigen.
Personalnummer im AD eintragen
Weitere Reiter oder Datenfelder können in die Verwaltungstools nur mühselig und mit viel Aufwand (z.B. durch die COM-Programmierung
mit C++, VB oder durch Dritt-Anbieter) eingefügt werden. Leichter ist es hingegen, sich die Informationen skriptbasiert über das Kontextmenü
anzeigen zu lassen (siehe o.g. Artikel). Diese Variante der Anzeige hat den Vorteil, dass es sich recht einfach und schnell implementieren lässt.
Denn im Active Directory-Schema existieren weitaus mehr Attribute, als in den MMCs angezeigt werden. Daher sollte stets vor einer
Schemaerweiterung das Schema kontrolliert werden, ob nicht doch ein passendes Attribut bereits existiert, jedoch nirgendwo angezeigt wird.
Das modifizieren der Spalten ist dank der Display-Specifier Klasse möglich. In Windows Server 2003 sowie Windows Server 2008
existieren standardmäßig 55 Display-Specifier Objekte. Die Klasse Display-Specifier beschreibt das Kontextmenü und die Eigenschaften
von Active Directory-Objekten. Durch das Bearbeiten der Display-Specifier lassen sich recht simpel die grafischen Active Directory-
Verwaltungswerkzeuge anpassen. Jede Objektklasse die in der grafischen Oberfläche erscheint, besitzt ein Display-Specifier Objekt
in der die Elemente die angezeigt werden definiert sind. Denn die AD-Verwaltungswerkzeuge (wie dsa.msc oder dssite.msc) rufen ihre
Konfigurationen aus den Display-Specifiern ab.
Zu finden sind die Display-Specifier in der Konfigurationspartition, im Container:
CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>.
Dort befinden sich weitere durchnummerierte Container, wobei jeder Container jeweils einer bestimmten Sprachversion entspricht.
Der für das deutsche Gebietsschema zuständige Container lautet CN=407. Demnach müssen auf einem deutschen Server die Änderungen
mit Organisations-Admin Rechten im Container CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
durchgeführt werden. Auf einer englischen Serverversion müssen die Display-Specifier im Container CN=409 bearbeitet werden.
Entsprechendes gilt natürlich für die anderen Sprachen.
Locale Identifier Constants and Strings
Wo kann man eigene Spalten definieren?
Eigene Spalten können im mehrwertigen Attribut Extra-Columns, des jeweiligen Display-Specifier Objekts definiert werden. Dies kann
getrennt entweder für Container wie z.B. dem Standard-Container Users bzw. Computers oder für Organisationseinheiten (OUs)
festgelegt werden. Die zusätzlichen Spalten die standardmäßig im dsa.msc zur Verfügung stehen, sind im Attribut extraColumns
das sich im Objekt CN=default-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne> befindet, definiert.
Die technische Umsetzung
Wenn man nun z.B. die Personalnummer statt aus dem Kontextmenü heraus, direkt in einer Spalte angezeigt haben möchte,
so ist das folgendermaßen möglich:
-
Zuerst gilt es mit ADSIEdit oder LDP, welche sich unter Windows Server 2003 in den Support Tools befinden und unter
Windows Server 2008 bereits im Betriebssystem integriert ist, zu dem für Container zuständigen Display-Specifier Objekt
zu navigieren. Der Pfad lautet:
container-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne> Anschließend ruft man durch einen Doppelklick auf das Objekt container-Display die Eigenschaften auf. Mit dem Objekt
container-Display hat man Einfluss auf die Spalten in Containern, wie es die beiden Standard-Container Computers oder Users darstellen.
-
Möchte man stattdessen eigene Spalten in Organisationseinheiten (OU) integrieren, so navigiert man zu diesem Pfad:
organizationalUnit-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
-
Eine weitere Möglichkeit wäre die "eigenen" Spalten lediglich in den gespeicherten Abfragen anzuzeigen.
Das hat den Vorteil, dass dadurch die selbst hinzugefügten Spalten mit den bereits bestehenden Spalten
zusammengefügt werden. Somit bleibt die Anzeige der Spalten in den Standardcontainern Users und Computers
sowie in den OUs unverändert.
Damit neben den bereits existierenden Spalten die eigenen Spalten bei einer gespeicherten Abfrage
angezeigt werden, gilt es zuerst die Eigenschaften des folgenden Containers aufzurufen:
default-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
Als nächstes ist in den Eigenschaften des entsprechenden Objekts, dass mehrwertige Attribut extraColumns zu bearbeiten.
Die Syntax wäre wie folgt:
<Ldap-Display-Name>,<Spaltenbezeichnung>,<Default Visibility>,<Spaltenbreite>,<Reserviert/unbenutzt> Die Werte bedeuten:
<Ldap-Display-Name>= Zuerst muss der LDAP-Display Name des gewünschten Attributs angegeben werden.
<Spaltenbezeichnung>= Der angezeigte Name der im Spaltenkopf der MMC erscheint.
<Default Visibility>= Wenn die eigene Spalte standardmäßig angezeigt werden soll, ist als Wert 1 einzutragen.
Soll hingegen die Spalte unter Ansicht - Spalten hinzufügen/entfernen… manuell hinzugefügt werden, so ist als Wert 0 einzutragen.
<Spaltenbreite>= Mit diesem Wert wird die Breite der Spalte in Pixels angegeben. Der Wert -1 gibt an,
das sich die Breite der Spalte nach der Spaltenbezeichnung richtet.
<Reserviert/Unbenutzt>= Hier ist als Wert 0 einzutragen.
Die einzelnen Werte sollten fortlaufend ohne Leerzeichen und jeweils durch ein Komma getrennt angegeben werden.
Im Falle der Personalnummer sähe die Syntax so aus:
employeeID,Personalnummer,1,150,0 oder employeeID,Personalnummer,1,-1,0
Was ist der Nachteil an dieser Vorgehensweise?
-
Werden im Objekt container-Display und/oder organizationalUnit-Display eigene Spalten integriert, erscheinen neben den
drei standardmäßig angezeigten Spalten (Name, Typ, Beschreibung) nur noch die selbst hinzugefügten Spalten.
Danach werden die zusätzlichen 22 bzw. 27 Spalten unter Windows Server 2003/2008 vollständig durch die eigenen Spalten
ersetzt und nicht zusammengefügt.
Stattdessen werden die eigenen Spalten die im Objekt default-Display definiert wurden, neben den Standard-Spalten bei
einer gespeicherten Abfrage angezeigt.
-
Wird lediglich das Objekt container-Display bearbeitet, stehen jedoch die zusätzlichen Spalten für OUs weiterhin zur Verfügung.
Das gleiche gilt auch vice-versa. Werden eigene Spalten nur für OUs hinzugefügt, stehen für die Standard-Container
Computers/Users weiterhin die zusätzlichen Spalten aus dem Objekt default-Display zur Verfügung.
Das Hinzufügen der eigenen Spalten im Attribut extraColumns das sich im Objekt default-Display befindet,
bringt in diesem Fall auch nicht den gewünschten Erfolg.
Möchte man aber neben den eigenen auch die vom System vorgegebenen Spalten weiter nutzen, können die Einträge aus
dem Objekt default-Display kopiert und in das gewünschte Container-Objekt (container-Display oder organizationaUnit-Display)
hinzugefügt werden.
-
Ein weiterer Haken an dieser Vorgehensweise wäre, dass die Änderungen in der Konfigurationspartition durchgeführt werden.
Diese Verzeichnispartition wird auf jeden DC in der Gesamtstruktur repliziert. Folglich wären alle Domänen in der Gesamtstruktur
von dieser Änderung betroffen.
Weitere Informationen:
Extending the User Interface for Directory Objects
Display Specifiers
About MMC 2.0
Microsoft Management Console 3.0
In der heutigen Zeit ist es üblich das Firmen fusionieren, übernommen werden, komplett oder bloß ein Firmenteil verkauft
bzw. selbstständig wird. Wenn Firmen fusionieren ist es meistens erforderlich, eine Verbindung zwischen den Strukturen herzustellen.
Das kann eine Vertrauensstellung oder aber auch eine Migration bedeuten, je nachdem welche Anforderungen erfüllt werden müssen.
Soll sich aber ein Firmenteil eigenständig machen, steht dem Administrator eine Migration bevor. Oder etwa doch nicht?
Der gestresste Administrator der ohnehin mit seinen täglichen Aufgaben mehr als genug zu tun hat, möchte sich die Arbeit
der Firmenteilung gering halten. Er stellt sich dabei vor, weitere DCs in der Root-Domäne der Muttergesellschaft zu installieren
und die AD/DNS-Replikation abzuwarten. Anschließend stellt er diese DCs in einem isolierten Netzwerk, das keine Verbindung
zur Gesamtstruktur der Muttergesellschaft hat an ihren Zielort auf. Die überflüssigen AD-Objekte (Benutzer- und Computerkonten,
OUs, AD-Standorte, DC-Objekte, Sub-Domänen etc.) werden auf den verschobenen DCs entfernt. Ebenso werden auf den DCs
der Muttergesellschaft die verschobenen Objekte entfernt.
Weitere Details werden an dieser Stelle mit Absicht nicht genannt!
Wenn die DCs an ihrem Zielort stehen hat man als Ergebnis nun zwei völlig unabhängige Gesamtstrukturen,
was sogar mit dem minimalsten Aufwand erreicht wurde, nicht wahr? Weiterhin denkt sich der scheinbar clevere Administrator,
dass dieser Domänensplitt keine Sicherheitsrisiken für beide Gesamtstrukturen mit sich bringt.
Das nach dem Splitt beide Gesamtstrukturen den gleichen internen NetBIOS- sowie DNS-Domänennamen haben stört
den Administrator nicht, da es sich schließlich um interne Domänennamen handelt. Diese können bekanntermaßen auch
mühevoll unter Windows Server 2003/2008 geändert werden. Aber ob dies am Ende vollständig von Erfolg gekrönt ist,
steht auf einem anderen Blatt.
Außerdem ist der ganz schlaue Administrator der Meinung, dass solch ein Domänensplitt auch einen Vorteil hätte.
Denn falls das unternehmerische Vorhaben der Firmenteilung scheitern und beide Firmenteile sich erneut zusammenschließen würden,
könnte er einfach die verschobenen DCs zurück zur Domäne der Muttergesellschaft stecken. Nur was würde das bringen,
wenn auf beiden Seiten die DC-Objekte der jeweils anderen Seite gelöscht wurden.
Kommen wir zu dem Punkt des Sicherheitsfaktors.
Unterliegen nach einem Domänensplitt beide Gesamtstrukturen wirklich keinem Sicherheitsrisiko?
Die Antwort lautet: In beiden Gesamtstrukturen wäre die Sicherheit so löchrig wie ein Schweizer Käse!
Wird eine Root-Domäne geteilt, sind in beiden Firmenteilen unter anderem die folgenden Punkte identisch:
-
Beide Seiten enthalten das vordefinierte Administratorkonto mit dem gleichen Kennwort.
-
Alle vordefinierten Sicherheitsgruppen, in erster Linie die Sicherheitsgruppe Organisations-Admins wären auf beiden Seiten identisch.
- Auf beiden Seiten ist die Domäne als Root-Domäne deklariert, mit derselben SID.
- Durch den globalen Katalog existieren auch auf den verschobenen DCs alle Objekte aus der Gesamtstruktur der Muttergesellschaft.
Diese Situation stellt für beide Seiten ein echtes Sicherheitsrisiko dar.
In den richtigen Händen ist keines der Domänen vor einer Kompromittierung sicher.
Weitere Risiken wären:
Auf den verschobenen DCs wären ebenfalls die Tombstones der Muttergesellschaft enthalten
die wiederbelebt werden könnten. Tombstones sind bereits gelöschte Objekte die aber noch in der AD-Datenbank existieren,
solange noch nicht die Tombstone Lifetime abgelaufen ist.
Wenn Applikationen in der Muttergesellschaft eingesetzt werden die sensible Informationen im Active Directory speichern,
wandern diese Daten ebenfalls auf den verschobenen DCs mit.
Sind Applikationen vorhanden die sich ins Active Directory verankern (wie z.B. Exchange), wandern diese Informationen ebenfalls mit.
Daher kann ich nur an jeden appellieren, auch wenn der Kunde König ist:
Finger weg von einem Domänensplitt!
Diese Art der Migration wird seitens Microsoft nicht supportet!
Wer einen Domänensplitt durchführt, der sollte sich ernsthaft überlegen ob er den richtigen Job ausübt.
Findet eine Firmenteilung statt, ist stets eine Migration durchzuführen.
Nur eine Migration wird seitens Microsoft unterstützt und ist auch reichlich sowie ausführlich auf den Microsoft-Seiten dokumentiert.
Eine Migration durchzuführen benötigt Zeit, Know-How und kann mehr oder weniger je nach Größe der Umgebung kompliziert sein.
Doch trotzdem rechtfertigt dies nicht einen Domänensplitt durchzuführen. Wer einer Migration nicht gewachsen ist,
der sollte sich statt einen Domänensplitt durchzuführen, besser einen erfahrenen Dienstleister zur Seite holen.
Ein Tool welches bei einer Migration nie fehlen darf, ist das Active Directory Migration Tool - ADMT.
Weitere Informationen:
Eine Domänenmigration durchführen
ADMT Version 3.1
Forest Recovery
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|