Bis einschließlich Windows Server 2003 kann mit Bordmittel nur eine Kennwort- und Kontosperrungsrichtlinie innerhalb einer Domäne auf Domänenbenutzer wirken. Damit die Richtlinien auf Domänenbenutzer wirken, müssen diese zwingend auf Domänenebene verlinkt werden. Wenn stattdessen die beiden Richtlinien auf eine Organisationseinheit (OU) verlinkt werden, wirkt sich das lediglich auf die Computer die sich in dieser OU befinden aus und die Kennwortvorgaben gelten somit nur für die lokalen Benutzerkonten, die sich auf diesen Computern befinden!
Möchte man bis Windows Server 2003 mit Bordmittel mehrere Kennwortrichtlinien nutzen, muss man weitere Domänen erstellen, was natürlich den Ressourceneinsatz sowie den Verwaltungsaufwand wesentlich erhöht. Man kann sich aber auch zusätzliche Kennwortfilter erstellen oder weicht auf Dritt-Anbieter Lösungen aus.
Die Kennwort- und Kontosperrungsrichtlinie sollten in allen Serverversionen stets in der Default Domain Policy (DDP) konfiguriert werden, nicht zuletzt, da die DDP standardmäßig ohnehin schon auf der Domänenebene verlinkt ist. Ein weiterer viel wichtiger Punkt ist, das man in den Eigenschaften der Domänenpartition die Attribute die für beide Richtlinien relevant sind (maxPwdAge, minPwdAge, minPwdLength, pwdHistoryLength, pwdProperties, lockoutDuration, lockOutObservationWindow, lockouThreshold etc.) auf dem PDC-Emulator auch direkt konfigurieren kann. Die Konfiguration der Kennwortvorgaben muss nicht zwingend in der DDP vorgenommen werden. Durch einen automatisierten Prozess werden dann die Änderungen die man in den Attributen vorgenommen hat vom PDC-Emulator in die beiden Richtlinien, aber nur in die DDP übertragen!
Es gilt zu beachten, dass die Kennwortoptionen unter den Computerkonfigurationen in der Gruppenrichtlinie und nicht wie man annehmen könnte, unter den Benutzerkonfigurationen konfiguriert wird! Die Benutzerobjekte können mit den Kennworteinstellungen nichts anfangen. Die Kennwortoptionen werden nur von Computerobjekten verwertet und befinden sich unter:
Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kennwortrichtlinien
und
Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontorichtlinien\Kontosperrungsrichtlinien
Die fein abgestimmten Kennwortrichtlinien
Seit Windows Server 2008 ist es mit Bordmittel nun endlich möglich, mehrere Kennwort- und Kontosperrungsrichtlinien für verschiedene Benutzergruppen innerhalb einer einzigen Domäne zu erstellen. Genau genommen sind es keine weiteren Richtlinien, sondern Active Directory (AD) Objekte. Die AD Objekte nennen sich Kennworteinstellungsobjekte und lauten im Fachjargon Password Setting Objects, kurz PSO.
Mit dieser Funktion die auch als granulare Kennwort- und Kontosperrungsrichtlinien oder als fein abgestimmte/abgestufte Kennwortrichtlinien (auf Englisch: Fine-Grained Password Policy, FGPP) bezeichnet wird, können getrennte Kennwort- und Kontosperreinstellungen für bestimmte Benutzer in der Domäne eingerichtet werden. Standardmäßig können die Mitglieder der Gruppe Domänen-Admins verschiedene Kennwortbeschränkungen und Kontosperreinstellungen für verschiedene Benutzertypen in der Domäne einrichten. Das Erstellen und administrieren von PSOs kann aber auch an eine entsprechende Gruppe delegiert werden.
Durch die beiden neuen Objektklassen Password Settings Container (PSC) und Password Settings die dem AD-Schema ab Windows Server 2008 hinzugefügt wurden, ist das Erstellen und Speichern von PSOs möglich. Der PSC in dem die PSOs für die Domäne gespeichert werden wird standardmäßig im Container System erstellt, dass sich in jeder Domänenpartition befindet. Der LDAP-Pfad zum PSC lautet CN=Password Settings Container,CN=System,DC=Domäne,DC=de.
Aktiviert man in der MMC Active Directory-Benutzer und -Computer unter Ansicht die „Erweiterten Features“, kommt der System Container in dem sich der PSC befindet zum Vorschein. Das systemflags Attribut in den Eigenschaften des PSCs verhindert, dass der Container weder verschoben, noch umbenannt oder gar gelöscht werden kann.
Die Voraussetzungen
- Der Domänenfunktionsmodus muss sich mindestens auf der Ebene Windows Server 2008 befinden! Der Gesamtstrukturfunktionsmodus wiederum kann sich z.B. auf der Ebene Windows Server 2003 befinden. Somit dürften sich in der Gesamtstruktur noch Domänen mit Windows Server 2003 DCs befinden, die dann aber keine PSOs einsetzen können!
- PSOs können nur auf Benutzerobjekte, globale Sicherheitsgruppen und auf inetOrgPerson-Objekte angewendet werden. Die Gruppenbereiche „Lokal (in Domäne)“ und „Universal“ sowie der Gruppentyp „Verteiler“ werden nicht berücksichtigt! Es ist empfehlenswert PSOs lediglich auf globale Gruppen zu verlinken. Dadurch müssen die Benutzer die eine andere Kennwortvorgabe erhalten sollen, nur noch zur entsprechenden Gruppe hinzugefügt werden.
- Auf eine OU können PSOs nicht direkt angewendet werden! Stattdessen kann man eine Schattengruppe (shadow group) verwenden, die der OU logisch zugeordnet ist. Eine Schattengruppe ist nichts anderes als eine globale Sicherheitsgruppe. Alle Benutzer einer OU werden dann zu dieser Schattengruppe hinzugefügt und die PSO wird dieser Schattengruppe zugewiesen. Wird ein Benutzer aus einer OU in eine andere verschoben, muss die Mitgliedschaft der Schattengruppe angepasst werden, falls der Benutzer die PSO der neuen OU zugewiesen bekommen soll.
- Auf einen Benutzer kann immer nur ein einziges PSO wirken!
- PSOs können nur im PSC erstellt werden!
- Das ein und dasselbe PSO kann auf mehrere Benutzer und/oder Gruppen angewandt werden, die sich in der gleichen Domäne befinden wie das PSO.
- Es gibt kein eigenes Bordmittel für PSOs. Ein PSO kann nicht in der MMC Active Directory-Benutzer und -Computer erstellt werden, lediglich das Anzeigen ist möglich. PSOs können mit Bordmittel mit der MMC ADSIEdit, mit dem Kommandozeilentool LDIFDE, LDP oder der AD-PowerShell erstellt und administriert werden. Zusätzlich gibt es aber im Internet kostenlose Tools, die einem das Leben mit den PSOs erleichtern.
Die Attribute eines PSO
Ein PSO in dem die Kennwortvorgaben und Kontosperreinstellungen konfiguriert werden, hat Attribute für alle Kennwortoptionen, die ebenfalls in der DDP festgelegt werden können (bis auf die Kerberos-Einstellungen).
In einem PSO existieren die Attribute für die folgenden Kennwort- und Kontosperreinstellungen:
- Vorrang: Das Attribut msDS-PasswordSettingsPrecedence dient zum Lösen von Konflikten, wenn auf ein Benutzer- oder Gruppenobjekt mehrere PSOs verlinkt sind. Dieses Attribut entscheidet letztendlich darüber welches PSO angewendet wird, falls mehrere PSOs auf ein Benutzer- oder Gruppenobjekt verlinkt sind. Das PSO, das den niedrigsten Wert in diesem Attribut enthält wird angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist! Als Werte wird jeder Wert akzeptiert, der größer als 0 ist.
- Kennwörter mit umkehrbarer Verschlüsselung speichern: Diese Option wird im Attribut msDS-PasswordReversibleEncryptionEnabled konfiguriert. Als Werte können FALSE und TRUE vergeben werden. Es versteht sich von selbst, dass man der Empfehlung folgen und hier als Wert FALSE vergeben sollte. Ansonsten würden die Kennwörter im Klartext abgespeichert werden, was ein erhebliches Sicherheitsrisiko darstellt!
- Kennwortchronik erzwingen: Für diese Option ist das Attribut msDS-PasswordHistoryLength zuständig. Hiermit wird die Anzahl der zu speichernden Kennwörter festgelegt. Wird als Wert 10 konfiguriert, werden die letzten 10 Kennwörter die der Benutzer vergeben hatte gespeichert. Wenn der Benutzer aufgefordert wird ein neues Kennwort zu vergeben, darf es kein Kennwort von den letzten 10 Kennwörtern sein. Der Wert muss zwischen 0 und 1024 liegen. Wird als Wert 0 vergeben, werden keine Kennwörter gespeichert.
-
Kennwort muss Komplexitätsvoraussetzungen entsprechen: Hinter dieser Option steckt das Attribut msDS-PasswordComplexityEnabled. Als Werte können hier FALSE (Deaktiviert) und TRUE (Aktiviert) vergeben werden, wobei TRUE empfohlen ist. Mit dieser Option wird festgelegt, dass das Kennwort komplex sein muss.
Komplex bedeutet:
1. Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.
2. Das Kennwort muss mindestens sechs Zeichen lang sein.
3. Das Kennwort muss Zeichen aus drei der folgenden Kategorien enthalten: - Großbuchstaben (A bis Z)
- Kleinbuchstaben (a bis z)
- Zahlen zur Basis 10 (0 bis 9)
- Nicht alphabetische Zeichen (zum Beispiel !, $, #, %)
- Minimale Kennwortlänge: Die minimale Kennwortlänge wird im Attribut msDS-MinimumPasswordLength konfiguriert. In diesem Attribut muss angegeben werden, aus wie vielen Zeichen das Kennwort mindestens bestehen muss. Als Wert kann 0 bis 255 vergeben werden, wobei mit 0 der Benutzer selbst die Länge seines Kennworts bestimmen kann.
- Minimales Kennwortalter: Das minimale Kennwortalter im PSO konfiguriert man im Attribut msDS-MinimumPasswordAge. Dieses Attribut gibt vor, wie alt ein Kennwort mindestens sein muss ehe es geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Soll der Benutzer erst nach fünf Tagen sein Kennwort ändern dürfen, so muss als Wert 5:00:00:00 eingetragen werden. Man kann aber auch als Wert mit Klammern (Nie) oder 0 eingeben, um kein Mindestalter zu definieren. Dadurch kann der Benutzer noch am selben Tag sein Kennwort erneut ändern. Der Wert von msDS-MinimumPasswordAge muss „kleiner als“ oder „gleich“ dem Wert von msDS-MaximumPasswordAge sein.
- Maximales Kennwortalter: Das Attribut das hinter dieser Option steckt lautet msDS-MaximumPasswordAge. Mit dieser Option wird angegeben, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss. Dieser Wert muss „gleich“ oder „größer“ als der Wert im Attribut msDS-MinimumPasswordAge sein. Die Zeitangabe muss in diesem Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) eingegeben werden. Vergibt man als Wert mit Klammern (Nie), läuft das Kennwort des Benutzers nicht ab. Als Wert kann nicht 0 konfiguriert werden.
Des Weiteren existieren im PSO Attribute, mit denen man die folgenden Kontosperreinstellungen konfigurieren kann:
- Kontensperrungsschwelle: Die Anzahl maximal möglicher Fehlversuche bei der Benutzeranmeldung bestimmt das Attribut msDS-LockoutThreshold. Als Wert kann man 0 bis 65535 eintragen, wobei 0 diese Option deaktiviert. Dann erfolgt niemals eine Kontosperrung. Das ist allerdings aus Sicherheitsgründen, z.B. wegen Brute Force Attacken nicht zu empfehlen!
- Zurücksetzungsdauer des Kontosperrungszählers: Wie lange die fehlgeschlagenen Anmeldeversuche zwischengespeichert werden, bevor der Kontosperrungszähler auf 0 zurückgesetzt wird, bestimmt das Attribut msDS-LockoutObservationWindow. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man als Wert 30 Minuten eintragen, so gilt es die Zeit wie folgt einzugeben 00:00:30:00. Der Wert von msDS-LockoutObservationWindow darf nicht „größer“ als der Wert von msDS-LockoutDuration sein, höchstens „gleich“! Denn es ist nicht möglich, den Kontosperrungszähler länger aktiv zu halten als die Zeit, die das Konto gesperrt und somit im Attribut msDS-LockoutDuration konfiguriert ist.
- Kontosperrdauer: Wie lange ein Benutzerkonto nach den Anmeldefehlversuchen (es zählt der Wert im Attribut msDS-LockoutThreshold) gesperrt werden soll, ehe es automatisch entsperrt wird, definiert man im Attribut msDS-LockoutDuration. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Wird als Wert mit Klammern (Nie) eingetragen, entsperrt sich das Benutzerkonto nicht automatisch. Stattdessen muss ein Administrator manuell das Konto entsperren. Der Wert im Attribut msDS-LockoutDuration darf nicht „kleiner“ sondern höchstens „gleich“ sein, als der Wert in msDS-LockoutObservationWindow.
Ferner existiert im PSO zusätzlich noch dieses Attribut:
-
PSO-Link: Im PSO-Link hinter dem das mehrwertige Attribut msDS-PSOAppliesTo steckt, konfiguriert man auf welche Objekte das PSO angewendet werden soll. Das bedeutet, ein PSO kann auf mehrere Benutzer und/oder Gruppen angewendet werden. In diesem Forward-Link muss der LDAP-Pfad bzw. der Distinguished Name (DN) des Objekts eingetragen werden, auf dem das PSO wirken soll.
Das Pendant zum Forward-Link ist das Back-Link, dass Attribut msDS-PSOApplied. In diesem Back-Link das den Benutzer und Gruppenobjekten ab Windows Server 2008 hinzugefügt wurde, ist das PSO bzw. wenn mehrere PSOs auf ein Benutzerobjekt direkt oder indirekt infrage kommen, sind die PSOs enthalten, mit dem das Objekt verknüpft ist. Welches PSO dann letztendlich auf ein Benutzerkonto angewandt wird, entscheidet der Richtlinienergebnissatz (Resultant Set of Policy, RSOP), genauer das Attribut msDS-ResultantPSO das sich ebenfalls in den Eigenschaften eines Benutzerobjekts befindet. Back-Links werden als constructed Attributes bezeichnet was nichts anderes bedeutet, als dass diese Art von Attribut von jedem DC selbst veraltet wird und der Wert eines solchen Attributs auch nicht vom Administrator bearbeitet werden kann. Es ist ein system-only Attribut und wird auch nicht auf andere DCs repliziert. Des Weiteren wird ein Back-Link und sein Wert erst zum Zeitpunkt der Abfrage generiert.
Verknüpfte Attribute
Die konstruierten Attribute abfragen
Die PSO-Attribute mit einer Zeitangabe
Es gibt im PSO vier Attribute die als Wert eine Zeitangabe im Form von Tage:Stunden:Minuten:Sekunden verlangen.
Die vier Attribute sind:
- msDS-MaximumPasswordAge
- msDS-MinimumPasswordAge
- msDS-LockoutObservationWindow
- msDS-LockoutDuration
Erstellt man ein PSO in der AD-PowerShell oder mit ADSIEdit, muss man die Zeitangabe nach der Vorgabe tt:ss:mm:ss konfigurieren. Möchte man jedoch ein oder mehrere PSOs mit LDIFDE erstellen, so müssen die Werte in diesen Attributen im I8-Format angegeben werden! Im I8-Format wird die Zeit in Intervallen von -100 Nanosekunden (Schema: attributeSyntax = 2.5.5.16 (I8)) gespeichert. Unter Windows Server 2003 wird in der Default Domain Policy genau diese Zeiteinheit für die entsprechenden Zeit-bezogenen Attribute verwendet. Um in diesen vier Attributen die entsprechenden Werte zu konfigurieren, gilt es die Zeitangabe in Tage, Stunden oder Minuten in die Intervalle von -100 Nanosekunden zu konvertieren. Anschließend muss dem konvertierten Ergebnis noch ein negatives Vorzeichen (das Minuszeichen „-„) vorangestellt werden.
Zum umrechnen der Zeit können die folgenden Umrechnungsformel verwendet werden, um die entsprechenden I8-Werte zu erhalten:
Tage: Die Umrechnungsformel für einen Tag lautet = -24*60*60*(10^7) = -864000000000.
Demzufolge würde der Wert für fünf Tage so lauten: -4320000000000 (5*864000000000).
Stunden: Eine Stunde wird wie folgt umgerechnet: -60*60*(10^7) = -36000000000.
Der Wert für zwei Stunden lautet -72000000000 (2*36000000000).
Minuten: Die Formel für eine Minute lautet = -60*(10^7) = -600000000.
Sollen 30 Minuten ins I8-Format konvertiert werden, so lautet das Ergebnis -18000000000 (30*600000000).
Welches PSO wird angewendet und hat Vorrang, falls mehrere PSOs infrage kommen?
PSOs können sowohl Benutzerobjekten als auch globalen Sicherheitsgruppen zugewiesen werden. Der Richtlinienergebnissatz (RSOP) kann jedoch nur für das Benutzerobjekt berechnet werden. Sind mehrere PSOs mit einem Benutzer oder einer globalen Gruppe verknüpft, wird der RSOP wie folgt berechnet:
- Es wird zuerst geprüft, ob ein PSO direkt mit dem Benutzerkonto verknüpft ist. Ist das der Fall, wird dieses PSO angewendet. Sind mehrere PSOs direkt mit dem Benutzerkonto verknüpft, gewinnt das PSO, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence enthält! Existieren mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
- Wenn kein PSO direkt mit dem Benutzerobjekt verknüpft ist, werden die Mitgliedschaften in den globalen Sicherheitsgruppen des betreffenden Benutzers überprüft. Existiert darunter eine Gruppe das mit einem PSO verknüpft ist, wird das PSO auf Umwege auf das Benutzerkonto angewendet. Befindet sich der Benutzer in mehreren globalen Gruppen auf denen verschiedene PSOs verknüpft sind, wird das PSO auf das Benutzerkonto angewendet, das den niedrigsten Wert im Attribut msDS-PasswordSettingsPrecedence hat! Wenn mehrere PSOs mit demselben Wert im Attribut msDS-PasswordSettingsPrecedence existieren, wird das PSO auf das Benutzerkonto angewendet dessen GUID niedriger ist!
- Wenn kein PSO direkt oder indirekt per globaler Sicherheitsgruppe mit einem Benutzerobjekt verknüpft ist, werden die Kennwort- und Kontosperrungsrichtlinien aus der Default Domain Policy angewandt! Deshalb sollten immer die Kennwort- und Kontosperrungsrichtlinien in der DDP konfiguriert werden, um eine Mindestanforderung an die Benutzerkennwörter zu stellen.
- Existiert ein PSO das direkt oder indirekt mit einem Benutzerobjekt verknüpft ist, hat das PSO stets vor der DDP Vorrang! Erst wenn ermittelt wurde, dass letztendlich einem Benutzerobjekt kein PSO zugewiesen wurde, greifen die Kennwortbeschränkungen aus der DDP.
- Welches PSO letzten Endes auf ein Benutzerkonto angewendet wird, entscheidet das RSOP! Denn ein weiteres neues constructed Attribut das dem Benutzerobjekt ab Windows Server 2008 hinzugefügt wurde, lautet msDS-ResultantPSO. In diesem Attribut ist der DN des PSOs gespeichert, das letztendlich nach den o.g. Regeln auf den Benutzer angewandt wird.
Mehr über constructed Attribute gibt es hier:
Die konstruierten Attribute abfragen
-
Es gibt jedoch drei Einstellungen die direkt im Benutzerobjekt vorgenommen werden können, um stets die Kennwortvorgaben eines PSOs auszuhebeln. Die drei Optionen lassen sich mit den Flags des userAccountControl Attributs konfigurieren und sind: - Kennwort läuft nie ab
- Kennwort mit umkehrbarer Verschlüsselung speichern
- Kennwort nicht erforderlich
How to use the UserAccountControl flags to manipulate user account properties
Im Übrigen setzen diese drei Flags die Kennwortvorgaben die in der DDP konfiguriert sind, ebenso außer Kraft!
PSOs mit der AD-PowerShell erstellen und verwalten
Unter „Windows Server 2008“ konnten PSOs mit Bordmittel lediglich mit ADSIEdit, LDIFDE sowie LDP erstellt und administriert werden. Ab „Windows Server 2008 R2“ können PSOs mit einem weiteren Bordmittel, mit dem State of the Art Werkzeug der AD-PowerShell erstellt und verwaltet werden.
Auch unter Windows Server 2003 und Windows Server 2008 kann man die AD-PowerShell nach vorheriger Installation der AD-Management Gateway Services nutzen.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Zum Überprüfen und konfigurieren der Kennwort- und Kontosperrungsrichtlinie in der DDP gibt es ebenfalls die beiden AD-PowerShell Cmdlets Get-ADDefaultDomainPasswordPolicy und Set-ADDefaultDomainPasswordPolicy. Das Cmdlet Get-ADDefaultDomainPasswordPolicy mit dem die Kennwortoptionen direkt aus den Attributen (und nicht aus der DDP) die sich in der Domänenpartition befinden abgerufen werden, zeigt die Kennwortvorgaben die mit der DDP verteilt werden an.
Das Cmdlet Set-ADDefaultDomainPasswordPolicy ändert nicht etwa die Kennworteinstellungen in der DDP, sondern direkt die Attribute die sich in der Domänenpartition befinden. Wie die einzelnen Kennwortoptionen zum Konfigurieren in der AD-PowerShell lauten, erfährt man mit dem Befehl Get-Help <Cmdlet> -Full. Also z.B. Get-Help Set-ADDefaultDomainPasswordPolicy –Full.
Zum Administrieren der PSOs in der AD-PowerShell stellt Microsoft diese acht Cmdlets zur Verfügung:
- Add-ADFineGrainedPasswordPolicySubject
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADUserResultantPasswordPolicy
- New-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Set-ADFineGrainedPasswordPolicy
- Mit diesem Einzeiler lässt sich ein PSO wie folgt erstellen:
New-ADFineGrainedPasswordPolicy –Name “PSO für die GF” –Precedence 20 –ComplexityEnabled $true –Description “Dieses PSO gilt nur für die GF” –Displayname “GF-PSO” –LockoutDuration “0.00:15:00” –LockoutObservationWindow “0.00:15:00” –LockoutThreshold 15 -MaxPasswordAge "60.00:00:00" -MinPasswordAge "5.00:00:00" -MinPasswordLength 8 -PasswordHistoryCount 10 -ReversibleEncryptionEnabled $false
- Ist das PSO erstellt, muss es anschließend mit dem folgenden Befehl an einen Benutzer oder eine Gruppe wie folgt zugewiesen werden:
Add-ADFineGrainedPasswordPolicySubject <Name der PSO> <Benutzer/Gruppe>
- Einzelne Optionen lassen sich in einem bestehenden PSO folgendermaßen ändern:
Set-ADFineGrainedPasswordPolicy “CN=<Name der PSO>,CN=Password Settings Container,CN=System,DC=Domäne,DC=de” –Precedence 15 -MinPasswordLength 12
- Alle PSOs mit den konfigurierten Kennwortoptionen lassen sich mit diesem Befehl Anzeigen:
Get-ADFineGrainedPasswordPolicy -Filter { Name -Like "*" }
- Welches PSO letzten Endes auf einen Benutzer wirkt und wie die einzelnen Kennwortoptionen konfiguriert sind, erfährt man mit diesem Befehl:
Get-ADUserResultantPasswordPolicy <Benutzer>
- Mit der AD-PowerShell kann man sogar abfragen, auf welche Benutzer- und/oder Gruppenobjekte ein bestimmtes PSO verlinkt ist. Der Befehl lautet:
Get-ADFineGrainedPasswordPolicySubject <Name der PSO>
- Um die Verlinkung einer PSO von einem Benutzer oder von einer Gruppe zu entfernen, muss dieser Befehl ausgeführt werden:
Remove-ADFineGrainedPasswordPolicySubject <Name der PSO> -Subjects <Benutzer/Gruppen> -Confirm:$False
- Eine PSO kann man in der AD-PowerShell so löschen:
Remove-ADFineGrainedPasswordPolicy <Name der PSO> -Confirm:$False
Ein PSO mit ADSIEdit erstellen
Die Attribute eines PSO, müssen zwingend in dieser Reihenfolge bei der Erstellung mit ADSIEdit konfiguriert werden.
Das Erstellen eines PSOs erfolgt mit Bordmittel in ADSIEdit wie folgt:
- Zuerst verbindet man sich in ADSIEdit mit der Domänenpartition und navigiert zum Container CN=Password Settings Container,CN=System,DC=Domäne,DC=de.
- Mit einem Rechtsklick auf den PSC kann man unter Neu - Objekt… ein PSO, das zur Klasse msDS-PasswordSettings gehört erstellen.
- Mit einem Klick auf Weiter muss der Common-Name im Attribut cn angegeben werden. Der CN ist ein Name, der das PSO eindeutig identifiziert (z.B. „PSO für GF“ etc.).
- Im nächsten Schritt muss der Password Settings Precedence, der Wert für das Attribut msDS-PasswordSettingsPrecedence angegeben werden. Der Wert (der größer 0 sein muss!) der hier eingetragen wird entscheidet darüber, welches PSO auf das Objekt letztendlich angewendet wird, falls mehrere PSOs auf das Objekt verlinkt sind. Das PSO das den niedrigsten Wert in diesem Attribut enthält, wird auf das Objekt angewendet. Existieren mehrere PSOs mit dem gleichen Wert, gewinnt das PSO dessen GUID niedriger ist.
- Dann muss für die Option Password reversible encryption status for user accounts im Attribut msDS-PasswordReversibleEncryptionEnabled entweder als Wert FALSE (was empfohlen ist!) oder TRUE eingegeben werden.
- Als nächstes muss bei der Option Password History Length for user accounts ein Wert zwischen 0 und 1024 im Attribut msDS-PasswordHistoryLength vergeben werden.
- Bei der Option Password complexity status for user accounts muss im Attribut msDS-PasswordComplexityEnabled als Wert FALSE oder TRUE vergeben werden. Wobei TRUE die empfohlene Einstellung ist.
- Danach gibt man bei der Option Minimum Password Length for user accounts im Attribut msDS-MinimumPasswordLength die Mindestlänge, die ein Kennwort zwingend haben muss an! Es kann ein Wert zwischen 0 und 255 vergeben werden.
- Nun muss im Attribut msDS-MinimumPasswordAge für die Option Minimum Password Age for user accounts das minimale Kennwortalter angegeben werden, ehe es vom Benutzer geändert werden darf. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden (z.B. 7:00:00:00 für sieben Tage). Wird als Wert mit Klammern (Nie) eingetragen, wird kein Mindestalter definiert.
- Im darauffolgenden Schritt muss man in der Option Maximum Password Age for user accounts im Attribut msDS-MaximumPasswordAge diesmal das maximale Alter eines Kennworts eingeben. In diesem Attribut wird definiert, nach wie vielen Tagen spätestens der Benutzer sein Kennwort ändern muss! Auch hier muss die Zeitangabe im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) erfolgen. Es dürfte jedem klar sein, dass dieser Wert gleich oder höher sein muss als der Wert im Attribut msDS-MinimumPasswordAge.
- Bei der nächsten Option Lockout threshold for lockout of user accounts muss im Attribut msDS-LockoutThreshold der Wert für die Kontosperrschwelle eingegeben werden. Wie oft der Benutzer sein Kennwort falsch eingeben darf ehe sein Benutzerkonto gesperrt wird, legt man in diesem Attribut fest. Als Wert kann zwischen 0 und 65535 gewählt werden. Gibt man als Wert 0 ein, wird das Benutzerkonto nie gesperrt.
- Mit der Option Observation Window for lockout of user accounts bestimmt man im Attribut msDS-LockoutObservationWindow, wie lange die Anmeldefehlversuche gespeichert werden sollen, ehe der Kontosperrungszähler zurückgesetzt wird. Die Zeitangabe muss im Format Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss) angegeben werden. Möchte man die Zeit auf 20 Minuten festlegen, so muss der Wert folgendermaßen konfiguriert werden 00:00:20:00.
- Zum Schluss muss man noch für die Option Lockout duration for locked out user accounts im Attribut msDS-LockoutDuration die Kontosperrdauer angeben. Das Format der Zeitangabe muss so aussehen Tage:Stunden:Minuten:Sekunden (tt:ss:mm:ss). Wenn also der Benutzer sein Kennwort mehr als der Wert, der im Attribut msDS-LockoutThreshold definiert ist falsch eingegeben hat und das Benutzerkonto für zehn Minuten gesperrt werden soll, muss man diesen Wert eintragen 00:00:10:00.
- Nun gelangt man auf die letzte Seite, auf der man zum einen Fertig stellen und zum anderen auf Weitere Attribute klicken kann. Mit einem Klick auf Weitere Attribute öffnet sich ein weiteres Dialogfenster in dem man die Benutzer und Gruppen angeben kann, mit denen dieses PSO verknüpft werden soll. Dort gilt es im Feld Anzuzeigende Eigenschaften den Eintrag Optional und im Feld Anzuzeigende Eigenschaft das Attribut msDS-PSOAppliesTo auszuwählen. Daraufhin muss im Feld Attribut bearbeiten der DN des Objekts angegeben werden, auf dem das PSO angewendet werden soll. Da es sich hierbei um ein mehrwertiges Attribut handelt, können mehrere Objekte angegeben werden, auf denen dasselbe PSO wirken soll. Wenn ein DN eingetragen wurde, muss der Wert mit Hinzufügen in das Feld Wert(e) übernommen werden. Wurden alle Werte eingetragen, gelangt man mit OK zum Dialogfeld Objekt erstellen zurück.
- Mit einem Klick auf Fertig stellen wird nun endlich das PSO im „Password Settings Container“ erstellt. Falls ein Attribut einen ungültigen Wert enthält, erscheint nach dem Klick auf Fertig stellen eine Fehlermeldung.
Nach dem bestätigen der Fehlermeldung mit OK kann man im Dialogfenster Objekt erstellen zurück zum bemängelten Attribut navigieren, um den Wert zu korrigieren. Die Verdächtigen sind dabei die Attribute, die eine Zeitangabe in Form von Tage:Stunden:Minuten:Sekunden enthalten. Z.B. darf der Wert im Attribut msDS-LockoutObservationWindow nicht größer sein (höchstens gleich) als der Wert im Attribut msDS-LockoutDuration. Auch das UAC kann schuld sein. Das ADSIEdit sollte explizit als Administrator gestartet werden.
PSOs mit LDIFDE erstellen
Es gibt auch eine skriptbasierte Alternative, mit dem PSOs erstellt werden können. Das Erstellen von PSOs kann auch mit dem Kommandozeilentool LDIFDE automatisiert durchgeführt werden.
Die Einträge in der LDF Datei müssen folgendermaßen aussehen:
dn:CN=PSO,CN=Password Settings Container,CN=System,DC=Domäne,DC=de
changetype:add
objectClass:msDS-PasswordSettings
msDS-MaximumPasswordAge:-51840000000000 (entspricht 60 Tage)
msDS-MinimumPasswordAge:-1728000000000 (entspricht 2 Tage)
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:20
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-36000000000 (entspricht 60 Minuten)
msDS-LockoutDuration:-36000000000 (entspricht 60 Minuten)
msDS-LockoutThreshold:0
msDS-PasswordSettingsPrecedence:10
msDS-PSOAppliesTo:CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de
Der Import erfolgt mit diesem Befehl:
Ldifde -i -f C:\PSO.ldf
Weitere Informationen:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Domänen- und Gesamtstrukturfunktionsmodus
LDIFDE - LDAP Data Interchange Format Data Exchange
Das Active Directory (AD), das auf dem Extensible Storage Engine (ESE) Datenbankmodul basiert organisiert Objekte in einer hierarchischen Baumstruktur und stellt die Hierarchie der Objekte für eine Gesamtstruktur. Das AD speichert die transaktionale Datenbank intern in drei Tabellen: Datentabelle (Data-Table), Verknüpfungstabelle (Link-Table) und in der erweiterten Sicherheitseinstellungen Tabelle (Security Descriptor-Table, kurz SD-Table). Die beiden wichtigsten Tabellen in der sich die Daten des AD befinden ist die Datentabelle, die alle Objekte sowie Attribute enthält und die Verknüpfungstabelle, in der die Beziehungen zwischen den Objekten gespeichert werden.
Siehe auch: Verknüpfte Attribute
In der Datentabelle wird jedes Attribut und jedes Objekt in einer einzelnen Zeile, mit einer Spalte pro Attribut gespeichert. Das bedeutet, jede Zeile in der Datentabelle entspricht einem Attribut bzw. Objekt. Die Einträge die sich auf einem Domänencontroller (DC) in der Datentabelle befinden, sind aus der Schema-, Konfigurations-, Anwendungs- und Domänenpartition. Die Datentabelle eines globalen Katalogs (GC) enthält neben den Einträgen aus den bereits erwähnten Verzeichnispartitionen, zusätzlich noch die Einträge aus allen anderen Domänenpartitionen innerhalb der Gesamtstruktur. Denn bekanntermaßen werden alle Objekte aus allen Domänen innerhalb einer Gesamtstruktur, lediglich mit den Attributen die für eine Suche relevant sind in den GC repliziert.
Um jede Zeile in der Datentabelle eindeutig identifizieren zu können, verwendet das AD als eindeutige Kennung das Distinguished Name Tag (DNT). Bei dem DNT handelt es sich um einen vier Byte (32Bit) Integer Wert und dieser wird zum internen Verweis auf Attribute und Objekte verwendet. Der Distinguished Name Tag ist eine lokale Kennung der nicht zwischen den DCs repliziert wird und lautet bei jedem DC anders.
Der DNT gibt die Zeile in der AD-Datenbank an, in der das Attribut bzw. Objekt gespeichert ist. Jedes Objekt das erstellt wird erhält im DNT eine fortlaufende Nummer. Oder wenn z.B. ein Benutzer einer Gruppe hinzugefügt wird, speichert das AD den DNT des Benutzerobjekts im member Attribut der Gruppe und nicht den Distinguished Name (DN). Dadurch das sich der DNT selbst beim Umbenennen eines Objekts nicht ändert kann ein Benutzerobjekt umbenannt werden, ohne dass das AD alle Gruppen durchsuchen muss um den DN des Benutzers in jedem member Attribut der Gruppe aktualisieren zu müssen.
Im AD hat jedes Objekt genau ein übergeordnetes Objekt und ein Verweis auf das übergeordnete Objekt ist mit dem Objekt selbst gespeichert. Für die Beziehung zwischen den über- und untergeordneten Objekten speichert das AD in einer zusätzlichen Spalte innerhalb der Datentabelle den Parent Distinguished Name Tag (PDNT). In dieser Spalte wird der DNT vom übergeordneten Objekt gespeichert. Die Auflösung der Beziehung zwischen den über- und untergeordneten Objekten ist optimiert, da der DNT und PDNT indizierte Felder in der AD-Datenbank sind.
Um sich das genauer vor Augen zu führen empfiehlt es sich einen Export der AD-Datenbank mit LDP zu generieren. Diese Möglichkeit, einen Export der AD-Datenbank und das sogar im laufenden Betrieb durchzuführen, existiert seit Windows 2000 und ist dank des speziellen Attributs dumpdatabase möglich, das nur für diesen Zweck existiert. Nach dem man LDP gestartet hat, muss man sich zunächst mit einem DC verbinden. Dazu wählt man in LDP unter dem Menüpunkt Remotedesktopverbindung die Option Verbinden… und gibt den gewünschten DC an, von dem aus ein Export der lokalen AD-Datenbankkopie durchgeführt werden soll. Danach muss man ebenfalls unter dem Menüpunkt Remotedesktopverbindung die Option Gebunden… wählen, um sich mit dem AD zu binden. Anschließend gilt es unter dem Menüpunkt Durchsuchen die Option Ändern aufzurufen. Nun muss im Feld Attribut das Attribut dumpdatabase eingetragen werden. Im Feld Werte können die gewünschten Attribute angegeben werden die mit exportiert werden sollen. Das Feld darf dabei nicht leer bleiben und es muss mindestens ein Attribut angegeben werden. Standardmäßig werden unter Windows Server 2008 R2 bereits diese Werte exportiert: DNT - PDNT - CNT - NCDNT - OBJ – DelTime - RecTime - INST - RDNTyp – RDN. Hat man die entsprechenden Attribute eingegeben, muss im Bereich Vorgang die Option Hinzufügen gewählt und mit einem Klick auf Eingabe die getätigten Einträge in die Eingabeliste übernommen werden. Mit einem Klick auf Ausführen wird der Export dann durchgeführt.
Je nach Anzahl der Attribute, Objekte und Größe der AD-Datenbank kann der Export einige Zeit in Anspruch nehmen. Daher ist es empfehlenswert, den Export auf einem DC zu einem Zeitpunkt zu generieren, wenn gerade keine größere Last auf dem DC besteht!
Die exportierte Datei mit dem Dateinamen NTDS.dmp kann mit einem Texteditor geöffnet werden (z.B. Notepad) und wird im gleichen Verzeichnis erstellt, in der sich auch die AD-Datenbank NTDS.dit befindet (standardmäßig %windir%\NTDS).
Was passiert denn nun in der AD-Datenbank wenn ein Objekt, z.B. ein Benutzer gelöscht wird?
Es heißt wenn ein Objekt, z.B. ein Benutzer gelöscht wird, wandert es in den versteckten Container Deleted Objects das sich in der Domänenpartition befindet.
Näheres zum Container Deleted Objects liefert der folgende Artikel:
Der Container Deleted Objects
Doch bevor das Objekt überhaupt gelöscht wird, findet anhand bestimmter Kriterien eine Überprüfung statt, ob das Objekt auch tatsächlich gelöscht werden darf.
Welche Kriterien das hauptsächlich sind, steht im diesem Artikel:
Active Directory Wiederherstellung
Wenn die Kriterien erfüllt und das Objekt gelöscht werden darf, werden folgende Änderungen am dem gelöschten Objekt vorgenommen:
Lingering Objects (veraltete Objekte)
In Wirklichkeit wird in der AD-Datenbank das Objekt das gelöscht wurde, also z.B. ein Benutzer nicht verschoben. Stattdessen bleibt das Objekt nach dem Löschen weiterhin in der AD-Datenbank an seinem Platz bestehen! Lediglich die Beziehung zu dem übergeordneten Objekt, also der PDNT im gelöschten Objekt ändert sich. Das gelöschte Objekt erhält in der Spalte PDNT den DNT vom Container Deleted Objects.
Im Übrigen trifft das nicht nur auf das Löschen von Objekten zu. Auch wenn ein Objekt in eine andere OU verschoben wird, bleibt das Objekt weiterhin an seinem Ursprungsort in der AD-Datenbank bestehen. Das Einzige was sich auch hier ändert, ist die Beziehung zum übergeordneten Objekt, also der Wert in der Spalte PDNT.
Schauen wir uns das im folgenden Beispiel an:
Das Benutzerobjekt Yusuf Dikmenoglu enthält in der Spalte DNT den Wert 3702. Das Objekt befindet sich also in der Zeile 3702. In der Spalte PDNT ist als Wert 3697 eingetragen. Im PDNT ist der DNT vom übergeordneten Objekt gespeichert. Schaut man sich nun in der Spalte DNT die Zeile 3697 an wird schnell klar, das sich der Benutzer Yusuf Dikmenoglu in der OU „IT“ befindet.
Löscht man jetzt das Benutzerobjekt Yusuf Dikmenoglu, bleibt das Objekt weiterhin in der Zeile 3702 bestehen. Der Wert in der Spalte PDNT, sprich die Beziehung zum übergeordneten Objekt ändert sich jedoch! Das übergeordnete Objekt des gelöschten Benutzerobjekts Yusuf Dikmenoglu ist jetzt nicht mehr die OU „IT“, sondern der Container Deleted Objects in der Domänenpartition.
Wie zu erkennen ist wurde der Wert in der Spalte PDNT im gelöschten Benutzerobjekt Yusuf Dikmenoglu, von 3697 auf 1802 geändert.
Was an dieser Stelle auch zu erkennen ist, der Relative Distinguished Name (RDN) des gelöschten Benutzerobjekts hat einen eindeutigen Namen erhalten. Das gelöschte Objekt erhält intern den Namen <alterRDN>DEL:<objectGUID>. Durch das Hinzufügen der objectGUID ist sichergestellt, dass das Objekt auch im gelöschten Status einen einmaligen Namen innerhalb der AD-Datenbank besitzt und somit eindeutig zu identifizieren ist. Das ist auch notwendig, denn wenn es ein zweites Benutzerobjekt Yusuf Dikmenoglu geben würde das ebenfalls gelöscht wird, müssen beide Objekte im Container Deleted Objects identifiziert werden können. Diese Vorgehensweise ist insbesondere für das wiederherstellen des Tombstones oder aus dem AD-Papierkorb zwingend notwendig!
Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
Phantome im Active Directory
Anlässlich des Erscheinens der aktuellen ADMT Version 3.2 findet ihr hier eine Übersicht die aufzeigt:
- Welche ADMT Version sich auf welchem Serverbetriebssystem installieren lässt.
- Mit welcher ADMT Version man von welcher Quell-Domäne zu welcher Ziel-Domäne migrieren kann.
- Auf welchen Systemen sich der ADMT Agent installieren lässt.
|
ADMT Version |
OS |
Kann installliert werden auf |
Quell-Domäne |
Ziel-Domäne |
ADMT Agent kann installiert werden auf |
|
ADMT 3.2 |
Windows Server 2008 R2 |
ü (nicht auf RODC und Server Core) |
ü |
ü |
ü |
|
Windows Server 2008 |
X |
ü |
ü |
ü |
|
Windows Server 2003 |
X |
ü |
ü |
ü |
|
Windows 2000 Server |
X |
X |
X |
X |
|
Windows NT Server 4.0 |
X |
X |
X |
X |
|
Windows 7 |
X |
X |
X |
ü |
|
Windows Vista |
X |
X |
X |
ü |
|
Windows XP |
X |
X |
X |
ü |
|
Windows 2000 Professional |
X |
X |
X |
X |
|
|
|
|
|
|
|
ADMT Version |
OS |
Kann installliert werden auf |
Quell-Domäne |
Ziel-Domäne |
ADMT Agent kann installiert werden auf |
|
ADMT 3.1 |
Windows Server 2008 R2 |
X |
X |
ü |
ü |
|
Windows Server 2008 |
ü (nicht auf RODC und Server Core) |
ü |
ü |
ü |
|
Windows Server 2003 |
X |
ü |
ü |
ü |
|
Windows 2000 Server |
X |
ü |
ü |
ü |
|
Windows NT Server 4.0 |
X |
X |
X |
X |
|
Windows 7 |
X |
X |
X |
ü |
|
Windows Vista |
X |
X |
X |
ü |
|
Windows XP |
X |
X |
X |
ü |
|
Windows 2000 Professional |
X |
X |
X |
ü |
|
|
|
|
|
|
|
ADMT Version |
OS |
Kann installliert werden auf |
Quell-Domäne |
Ziel-Domäne |
ADMT Agent kann installiert werden auf |
|
ADMT 3.0 |
Windows Server 2008 R2 |
X |
X |
X |
X |
|
Windows Server 2008 |
X |
X |
X |
X |
|
Windows Server 2003 |
ü |
ü |
ü |
ü |
|
Windows 2000 Server |
X |
ü |
ü |
ü |
|
Windows NT Server 4.0 |
X |
ü |
X |
ü |
|
Windows 7 |
X |
X |
X |
X |
|
Windows Vista |
X |
X |
X |
X |
|
Windows XP |
X |
X |
X |
ü |
|
Windows 2000 Professional |
X |
X |
X |
ü |
|
|
|
|
|
|
|
ADMT Version |
OS |
Kann installliert werden auf |
Quell-Domäne |
Ziel-Domäne |
ADMT Agent kann installiert werden auf |
|
ADMT 2.0 |
Windows Server 2008 R2 |
X |
X |
X |
X |
|
Windows Server 2008 |
X |
X |
X |
X |
|
Windows Server 2003 |
ü |
ü |
ü |
ü |
|
Windows 2000 Server |
ü |
ü |
ü |
ü |
|
Windows NT Server 4.0 |
X |
ü |
X |
ü |
|
Windows 7 |
X |
X |
X |
X |
|
Windows Vista |
X |
X |
X |
X |
|
Windows XP |
X |
X |
X |
ü |
|
Windows 2000 Professional |
X |
X |
|
X |
Weitere Informationen:
Eine Domänenmigration durchführen
Einen Domänensplitt durchführen
ADMT Version 3.1
Benutzermigration mit ADMT v3: How-To
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Active Directory Migration Tool v.2.0
Password Export Server version 3.1 (x86)
Password Export Server version 3.1 (x64)
Seit der Veröffentlichung von Windows Server 2008 R2 konnte die bis dahin aktuelle ADMT Version 3.1 nicht auf einem Windows Server 2008 R2 installiert werden. Möchte man die bestehende Windows 2000, Windows Server 2003 oder Windows Server 2008 Umgebung mit ADMT in eine Windows Server 2008 R2 Domäne migrieren, muss dazu die ADMT Version 3.1 auf einem Windows Server 2008 installiert werden.
Nun hat aber Redmond die ADMT Version 3.2 veröffentlicht. Diese Version lässt sich ausschließlich auf einem Windows Server 2008 R2 installieren.
Active Directory Migration Tool version 3.2
Das aktualisierte ADMT-Handbuch findet man hier:
Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains
Mit ADMT 3.2 können Migrationen von folgenden Quell-Domänen durchgeführt werden:
- Windows Server 2003
- Windows Server 2008
- Windows Server 2008 R2
Als Ziel-Domänen werden ebenfalls diese unterstützt:
- Windows Server 2003
- Windows Server 2008
- Windows Server 2008 R2
Wie unschwer zu erkennen ist, kann man ADMT 3.2 nicht für eine Migration von Windows 2000 verwenden!
Wer eine Windows 2000 Domäne migrieren möchte, der muss ADMT 3.1 verwenden.
ADMT 3.2 lässt sich wie schon ADMT 3.1 nicht auf einem Server Core oder RODC installieren!
Wer eine Migration mit diesem Werkzeug durchgeführt hat, weiß es zu schätzen! Vor allem da es kostenlos von Microsoft zur Verfügung gestellt wird.
Viel Erfolg bei euren Migrationen! 
Weitere Informationen:
Eine Domänenmigration durchführen
ADMT Version 3.1
Einen Domänensplitt durchführen
Seit längerer Zeit befasse ich mich schon mit dem Gedanken, eine deutschsprachige Active Directory (AD) Mailingliste zu erstellen. Nun ist es soweit. Die AD Mailingliste ist erstellt!
Das ist die erste deutschsprachige geschlossene Diskussionsgruppe zu dem Dachbegriff "Active Directory" und den verwandten Themen. Unter dem Dachbegriff "Active Directory" fallen die Technologien: AD DS (AD Domain Services), AD CS (AD Certificate Services), AD LDS (AD Lightweight Directory Services, ehemals ADAM), AD FS (AD Federation Services) und AD RMS (AD Rights Management Services).
Verwandte Themen sind allgemeine Fragen bzw. Probleme im "Windows Server" Bereich mit allen Infrastrukturdiensten bzw. Funktionen wie z.B. DNS und GPO.
Was ist eine Mailingliste (ML)?
Eine ML kann man mit einer E-Mail Verteilergruppe vergleichen. Alle Benutzer die an der ML angemeldet sind, können Beiträge schreiben und jeder der an der ML angemeldet ist erhält jeden Beitrag.
Jeder der angemeldet ist kann Fragen stellen sowie Antworten versenden. Der Vorteil einer Mailingliste gegenüber einem Forum ist, dass die Beiträge offline gelesen und geschrieben werden können!
Wie kann man sich an der Mailingliste anmelden?
Wer sich an der ML anmelden möchte, muss lediglich eine Mail an adde-request[at]freelists.org mit dem Betreff subscribe senden. Weiterer Text in der Mail ist nicht notwendig. Danach erhält man eine Mail von "FreeLists Mailing List Manager" worauf man unbedingt antworten muss. Erst wenn eine Antwort versendet wurde, ist die Anmeldung abgeschlossen. Danach erhält man eine zweite System-Mail die vom ML-Provider automatisch verschickt wird.
Oder man trägt seine Mailadresse auf der folgenden Seite ein und wählt die Aktion Subscribe.
Die erste deutschsprachige "Active Directory" Mailingliste
Wie kann man sich von der ML abmelden?
Dazu muss man auch nur eine Mail an adde-request[at]freelists.org mit dem Betreff Unsubscribe senden. Eine Textnachricht in der Mail ist nicht notwendig. Anschließend erhält man eine Bestätigungsmail, auf die zwingend geantwortet werden muss.
Oder man trägt seine Mailadresse auf der folgenden Seite ein und wählt die Aktion Unsubscribe.
Die erste deutschsprachige "Active Directory" Mailingliste
Wie kann man eine Frage bzw. einen Beitrag an die ML senden?
Um eine Frage an die ML zu senden, muss lediglich eine E-Mail an die Adresse adde[at]freelists.org gesendet werden. In der Mail sollte ein aussagekräftiger Betreff gewählt werden, eine Begrüßung gehört ohnehin dazu und als Nachricht natürlich die Frage. Jeder andere in der ML kann dann auf diese Frage die als Mail an jeden ML-Teilnehmer versendet wird antworten.
Da jede Nachricht an die ML im Betreff mit [adde] gekennzeichnet wird, sind alle Mails die von der ML verschickt werden leicht zu identifizieren.
Was ist nicht erwünscht?
Was nicht gerne gesehen wird sind Wörter wie „Dringend“, „Hilfe“, „Notfall“, „Schnell“ oder ähnliches, mit vielleicht auch noch jeder Menge Ausrufezeichen im Betreff! Die ML ist eine nicht kommerzielle Plattform. Alle Teilnehmer bekommen keinen Cent und helfen Hilfesuchenden kostenlos und in ihrer Freizeit! Wenn sofortige (ich schreibe bewusst nicht zusätzlich „professionelle“, denn die Teilnehmer der ML sind größtenteils Experten!) Hilfe benötigt wird, sollte man sich an seinen Dienstleister seines Vertrauens wenden.
Hat man seine Frage bereits in einem Forum gestellt, sollte man nicht nach fünf Minuten die gleiche Frage in der ML stellen! Erst wenn der erste Versuch erfolglos war (und das kann mehrere Tage in Anspruch nehmen), sollte man sich an die ML wenden. Denn viele Teilnehmer der ML sind auch in den einschlägigen Foren unterwegs.
Keiner der ML-Teilnehmer darf direkt angemailt werden. Alle Nachrichten sind stets und ausschließlich an die ML adde[at]freelists.org zu senden!
Kommerzielle Werbung wird keineswegs geduldet (Hinweise auf Werkzeuge ausgenommen)!
Gibt es auch ein Archiv, um ältere Diskussionen zu durchforsten?
Ja, es existiert auch ein Archiv worin man unter der folgenden Adresse stöbern kann.
adde Mailingliste Archiv
Wenn es Probleme bei der Anmeldung oder beim Senden eines Beitrags gibt?
Falls es bei der Anmeldung oder beim Senden eines Beitrags wieder Erwartens zu Problemen kommen sollte, schickt mir bitte über meinen Blog eine Mail und ich kümmere mich darum.
Ich lade jeden herzlich dazu ein, an der AD Mailingliste teilzunehmen und sich daran zu beteiligen!
Auf interessante und knifflige Diskussionen!
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|