Wussten Sie, dass die Standardberechtigungen des AD jedem Benutzer den Zugriff auf alle Benutzer-, Gruppen- und Computerobjekte erlauben? Natürlich ist dieser Zugriff eingeschränkt - sensible Informationen sind weder einseh- noch änderbar. Nichtsdestotrotz kann diese Funktion sehr hilfreich sein, da es einem Benutzer so z.B. ermöglicht wird, nach e...
Sie hätten gerne Informationen über Ihre Benutzerkonto, wie Gruppenmitgliedschaften, SID usw? Wenn Sie Informationen über den gerade angemeldeten Benutzer haben möchten, wie z.B., ob der User als Gastkonto angemeldet ist, den Benutzernamen, die Domäne oder die Gruppenmitgliedschaften, hilft Ihnen die Funktion getcurrent() aus der Klasse [system.security.principal.windowsidentity] weiter.
[system.security.principal.windowsidentity]::getcurrent()
liefert folgende Properties zurück:
Name
----
Actor
AuthenticationType
BootstrapContext
Claims
DeviceClaims
Groups
ImpersonationLevel
IsAnonymous
IsAuthenticated
IsGuest
IsSystem
Label
Name
NameClaimType
Owner
RoleClaimType
Token
User
UserClaims
Eine Variante, die Ihnen entweder den Benutzer oder die Benutzermitgliedschaften zurückliefert, ist das Kommandozeilentool whoami. Mit den Parameter /User erhalten Sie Ihre SID, mit /Groups Ihre Gruppenmitgliedschaften. Alle wichtigen Informationen inklusive der Benutzerrechte spuckt der Parameter /all aus. Mit dem Parameter /Fo können Sie auch die Ausgabe im CSV-Format erzwingen, so dass Sie die Ausgabe mit Powershell direkt in Objekte konvertieren können:
Whoami.exe /groups /fo csv | ConvertFrom-CSV | Out-Gridview
Wenn Sie mit Powershell überprüfen möchten, ob eine gegebene Kombination aus einem AD-Benutzernamen und Kennwort korrekt ist (z.B. aus einer GUI-Eingabe), hilft Ihnen die .NET-Assembly System.Directore.Accountmanagement weiter (mind. .NET-Framwork 3.5). Die Klasse "PrincipalContext" enthält eine Methode ValidateCredentials, die die Überprüfung übernimmt. Die Funktion check_AdUserPassword liefert True oder False zurück und kann z.B. direkt in einem IF-Statement weiter genutzt werden.
Function Test-AdUserPassword
{
param (
[string]
$UserName,
[string]
$Password,
[string]
$UserDomain)
# Lädt die Assembly "System.DirectoryServices.AccountManagement" in Powershell
$Null = Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$ContextType = [System.DirectoryServices.AccountManagement.ContextType]::Domain
$PrincipalContext = New-Object System.DirectoryServices.AccountManagement.PrincipalContext($ContextType, $UserDomain)
$PrincipalContext.ValidateCredentials($UserName,$Password)
}
Wenn ein Domänen-Computer gestartet wird, sucht er im Netzwerk zuerst nach einem Domänen-Controller, indem der den DNS-Server nach den LDAP-Service-Records seiner Domäne fragt. Anschließend versucht er, mit dem Domänencontroller einen Secure Channel, also eine verschlüsselte, sichere Datenverbindung aufzubauen. Dies geschieht über einen RPC Netlogon. RPC ist ein Challenge-Response-Protokoll, bei dem der Client und der Server sich gegenseitig einen zufälligen 64 Bit-Zufallswert, den Client- bzw. Server Challenge, zuschicken, aus denen mit Hilfe des Computerkennworts (wegen gegenseitige Authentifizierung sowohl auf dem Client als auch auf dem Server) ein Session-Key berechnet wird. Das funktioniert, weil sowohl der Client als auch der Domänencontroller über das Computerkennwort des Clients verfügen. Wenn der Domänencontroller und der Client nicht das gleiche Kennwort gespeichert haben, schlägt die Erstellung des Secure Channels allerdings fehl und dem Client wird die Verbindung zum Domänencontroller verweigert. Stattdessen wird eine Fehlermeldung angezeigt, die vermutlich jeder Administrator schon einmal gesehen hat: „The trust relationship between this workstation and the primary domain failed” bzw. "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".
Der Client generiert beim Aufnehmen in die Domäne ein komplexes Kennwort, dass er ab Windows 2000 alle 30 Tage automatisch ändert. Da Computerkonten sind von den Kennwortrichtlinien der Domäne ausgenommen sind, können Sie auch nicht gesperrt werden, wenn sie länger offline sind.
Die Kennwortänderung führt der Client zuerst zuerst lokal aus. Danach ändert er sein Kennwort im AD. Schlägt die Aktualisierung im AD fehl, setzt er wieder das alte Kennwort. Das aktuelle Kennwort und sein Vorgänger werden im geschützten Kennwortschlüssel HKLM\SECURITY\Policy\Secrets\$machine.ACC gespeichert. Im AD sind die Kennwörter in den Attributen unicodepwd und lmpwdHistory abgelegt.
Ob und wie oft der Client sein Kennwort ändert, kann in der Systemregistrierung unter HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters konfiguriert werden. Für die Konfiguration sind drei Schlüssel verantwortlich:
MaximumPasswordAge: Der Eintrag MaximumPasswordAge legt fest, nach welchem Zeitraum der Netlogon-Dienst versucht, das Kennwort zu ändern. Der Standardwert ist 30 (Tage).
ScavengeInterval: Das Scavengeinterval legt fest, wie häufig der Computer prüfen soll, ob das maximale Kennwortalter erreicht ist. Der Standardwert beträgt 900 (Sekunden), also 15 Minuten. Der Eintrag ist nicht in der Registry hinterlegt, kann hier aber geändert werden. Der Typ des Eintrags ist REG_DWORD.
DisablePasswordChange: Sie können die Kennwortänderung des Computers mit diesem Schlüssel auch komplett deaktivieren, indem Sie den Wert auf 1 setzen.
Heute habe ich das neue Kapitel über Group Policy Preferences für die Neuauflage meines Gruppenrichtlnienbuchs beendet. Dabei habe ich ein sehr schönes Beispiel für den Einsatz der Registry-Einstellungen gefunden.
Die Sprachleiste ist in den meisten Fällen ein sehr überflüssiges Feature, denn sie erlaubt das Umschalten zwischen verschiedenen Tastaturlayouts. Welchen Sinn das haben soll, ist mir bis heute verborgen geblieben, denn ich wechsel eigentlich nie mal zwischendurch für ein frischeres Erlebnis auf eine chinesische Tastatur. Trotz allem dürfen wir dieses tolle Feature seit vielen Windows-Generationen genießen. Wenn die Funktion einfach nur da wäre, wäre das ja nicht weiter schlimm, aber dummerweise implementiert Sie auch noch die unseelige Tastenkombination Shift+Alt, die das Tastaturlayout automatisch umschaltet. Wie viele Helpdesk-Tickets aufgrund eines versehentlich aktivierten englischen Tastaturlayouts aufgemacht wurden, möchte ich nicht wissen. Glücklicherweise hat Microsoft in der aktellen Version 1803 von Windows 10 zumindest eine Option vorgesehen, das hinzufügen weiterer Layouts zu überspringen.
Die Sprachleiste wird über die Registry gesteuert, und zwar über den Schlüssel HKEY_CURRENT_USER\Keyboard Layout\Preload. Hier ist für jede Sprache ein Werte hinterlegt, wobei der Wertname der Priorität entspricht, und der Wert selber den Sprachcode bestimmt. Bei ITProToday finden Sie eine Liste der Sprachcodes. Bei mir finden sich zwei Einträge in der Liste:
| Name | Typ | Daten |
| 1 | REG_SZ | 00000407 |
| 2 | REG_SZ | 00000409 |
Der Wert 407 entspricht dem deutschen Layout, 409 ist das US-Englische Tastaturlayout.
Um die Sprachleiste zu entfernen, müssen Sie lediglich den kompletten Schlüssel Preload entfernen. Dies kann mit einem Powershell-Skript einfach erledigt werden, oder mit Gruppenrichtlinen-Einstellungen.
Die Active Directory Domänen-Funktionsebene (Domain Functional Level, DFL) und die Forest-Funktionsebene (Forest Functional Level) sind zwei Begriffe, die oft missverstanden werden. Ich werde hier versuchen, ein wenig Licht ins Dunkel zu bringen.
Die Funktionsebene einer Domäne bzw. eines Forest bestimmt, welche AD-Funktionen genutzt werden können. Mit jeder neuen Version von Windows wurden auch neue AD-Funktionalitäten implementiert, von denen einige durch eine Schemaerweiterung aktiviert werden können, während andere voraussetzen, dass alle Domänencontroller des AD sich auf dem gleichen oder einem höheren Betriebssystemstand befinden. Um sicherzustellen, dass alte und neue DCs miteinander kommunizieren können, muss das System sich auf den kleinsten gemeinsamen Nenner einigen. Daher werden neue Funktionen nicht automatisch freigeschaltet, sondern müssen nach dem Herunterstufen aller alten Domänencontroller manuell aktiviert werden. Dabei unterscheidet man zwischen der Funktionsebene einer einzelnen Domäne - um sie zu ändern, müssen alle Domänencontroller der Domäne auf dem gleichen minimalen Stand sein - und der Funktionsebene des Forest, für dessen Änderung alle Domänencontroller des Forest (also alle Domänen) den Versionsstand erreicht haben müssen, der aktiviert werden soll. Um die aktuellen Funktionsebenen abzufragen, öffnen Sie auf einem Computer, auf dem die AD-Verwaltungstools installiert sind, eine Powershell-Konsole und geben folgende Befehle ein:
(Get-ADDomain).DomainMode
(Get-ADForest).ForestMode
Um sich alle Domänencontroller Ihrer Domäne mit Betriebssystemversion ausgeben zu lassen, verwenden Sie
Get-ADDomainController -Filter * | Select-Object Hostname,Operatingsystem
Für alle Domänencontroller aller Domänen verwenden Sie
Das Cmdlet Search-ADAccount ist das Schweizer Messer des AD-Administrators. Es zeigt gesperrte Konten genauso an wie deaktiviert Konten, ablaufende Konten und Konten, deren Kennwort niemals abläuft. Der vielleicht hilfreichste Parameter ist aber -AccountInactive, der Konten anzeigt, die sich schon lange nicht mehr in der Domäne angemeldet haben. Grundsätzlich kann man dieses auch mit Get-ADUser und Get-ADComputer lösen, aber das ist aufwändiger und außerdem muß man auch darauf achten, welches AD-Attribut man auswertet, denn es gibt mehrere Eigenschaften, die die letzte Anmeldung speichern, aber nicht alle sind gleich gut geeignet. Eine gute Auflistung der Attribute und deren Unterschiede finden Sie im Technet-Wiki.
Um inaktive Konten anzuzeigen, nutzen Sie einfach
Search-ADAccount -AccountInactive
Der Parameter findet sowohl Benutzer- als auch Computerkonten, die sich seit 60 Tagen nicht mehr angemeldet haben. Wenn Sie nur Benutzer suchen, verwenden Sie den Parameter -Usersonly, wenn Sie die Zeitspanne angeben wollen, benutzen Sie den Parameter Timespan, gefolgt von den Tagen seit dem letzten Login:
Search-ADAccount -AccountInactive -TimeSpan 90 -UsersOnly
Leider bietet das Powershell AD-Modul keine Möglichkeit, auf das Vorhandensein einer Organizational Unit zu testen. Diese Funktion lässt sich aber einfach nachrüsten.
Grundsätzlich kann man die Existenz einer OU testen, indem man einfach das Cmdlet Get-OrganizationalUnit verwendet. Prüft man die Abfrage in einer IF-Bedingung, wird der Scriptblock des IF ausgeführt, wenn die OU existiert. Das Ganze hat allerdings einen Haken, denn Get-ADOrganizationalUnit bricht die Skriptverarbeitung mit einem unbehandelten Fehler ab, wenn die OU nicht existiert.
If ( Get-ADOrganizationalUnit -Identity "OU=test,DC=Netz-Weise,DC=DE" ) { $true }
get-adorganizationalUnit : Directory object not found
Dieses Verhalten kann man sich zunutze machen, indem man die Ausführung des Get-ADOrganizationalUnit mit Try-Catch ausführt. Wird ein unbehandelter Fehler ausgeführt, wird die Catch-Block aufgerufen und ausgeführt. In diesem muß man jetzt nur noch einen $False zurück liefern.
function Test-ADOrganizationalUnit
So konfigurieren Sie die AD-Replikation zwischen Standorten.
Wenn Sie eine größere Active-Directory Infrastruktur verwalten, verfügen Sie vermutlich auch über mehrere Standort. Diese Infrastruktur kann man zur effizienteren Nutzung der Netzwerkresourcen mit dem Tool Active Directory Sites and Services (Standort und Dienste) abbilden. Hierfür erstellt man IP-Subnetze, die Standorten zugewiesen werden - dadurch kann das AD anhand der IP den Standort des Servers feststellen. Die Standort werden über sogenannte Site-Links verbunden. Sie entsprechen den Netzwerkverbindungen (Standleitungen) zwischen den Standorten.
Während ein Domänencontroller innerhalb eines Standortes jede Änderung im AD innerhalb von 15 Sekunden an seine Replikationspartner versendet, wird zwischen Standorten ein anderes Replikationsintervall gewählt, das einstellbar ist, aber standardmäßig 180 Minuten (3 Stunden) beträgt. Änderungen werden nur in diesem Zeitrahmen repliziert - auch Kontosperrungen, die innerhalb eines Standortes als "urgent replication" augenblicklich repliziert werden.
Es ist mit einer kleinen Änderungen an den AD-Attributen des Site-Links jedoch möglich, Change-Notifications (also Update-Änderungen) zu aktivieren, so dass die Replikation im normalen Replikationsintervall durchgeführt wird. Davon sind dann entsprechend auch urgent Replications betroffen. Öffnen Sie hierzu Active Directory Standort und Dienst, wählen Sie Sites->Inter-Site-Transports-IP und dann den Site-Link, den Sie konfigurieren möchten. Im Kontext-Menü wählen Sie Properties, wechseln in den Reiter "Attribute Editor" und suchen das Attribut "Options". Wenn Sie Options auf 1 setzten, aktivieren Sie die Change-Notifications. Die Replikation findet dann, wie zwischen Standorten üblich, komprimiert statt. Wählen Sie 5, findet eine unkomprimierte Replikation statt. Sollte hier bereits ein Wert stehen, müssen Sie die Werte XOR verrechnen - es handelt sich um eine Bitmaske, die hier verwendet wird.
Links:
Active Directory Replication: Change Notification and you
https://blogs.msdn.microsoft.com/canberrapfe/2012/03/25/active-directory-replication-change-notification-you/
Advanced Replication Management
https://technet.microsoft.com/en-us/library/cc961787.aspx
