Metadaten im Active Directory
Basierend auf einer wahren Geschichte.
Es war einmal, vor langer Zeit, ein Active Directory.
In diesem Active Directory lebten viele glückliche User zusammen mit ihren Devices.
Die User und Devices konnten sich nach Lust und Laune anmelden, erforderliche Daten teilen, zusammenarbeiten, chatten und sich elektronische Briefe schicken. Besonders brave User und Devices wurden mit der Wolke, dem EntraID und dem M365 von Microsoft, abgeglichen. Hier konnten diese sich noch viel mehr anmelden, Daten teilen, zusammenarbeiten, chatten und sich elektonische Briefe schicken. Zusammen mit ihren Gruppen lebten die User und Devices glücklich und zufrieden.
Das Leben war wunderbar!
Doch die bösen, unnützen oder administrativ* tätigen User und Devices durften nicht in die Wolke. Sie waren nicht geeignet um im EntraID und im M365 zu existieren.
NoSync, die Gruppe der Verdammten, achtete darauf, dass diese User und Devices nicht in die Wolke kamen.
*das ist quasi „böse“ + „unnütz“ + „mächtig“ zusammen, so ein bisschen wie ein orangener Präsident.
Doch Langeweile, Unwissenheit und Übermut hatten einen Plan
Wird ein User oder Device böse, unnütz oder administrativ, so wird diese in die Gruppe der Verdammten, in „NoSync„, aufgenommen. Mitglieder von „NoSync“ existieren nicht mehr in der Wolke. Zeitgleich dazu werden zusätzliche regionale Gruppenmitgliedschaften aufgehoben.
Ob ein User oder Device böse, unnütz oder administrativ wird, unterliegt dem großen Zyklus des Lebens im Active Directory. Wenn die Zeit für einen User oder ein Device gekommen ist, wird es in die Unterwelt geschickt. Beraubt von seiner Identätit in der Cloud, beschnitten um seine Fähigkeiten im Active Directory wird das Objekt, mahnend für die Braven, vorgehalten.
Doch Langweile, Unwissenheit und Übermut fingen an, die User und Devices im großen Maße und vollkommen willkürlich zu behandeln!
Metadaten
Sehr viele User und Devices verschwinden jetzt aus der Wolke. Die Auswirkungen sind sehr schnell sehr deutlich spürbar:
- Non delivery reports (NDR) bei E-Mails
- Authentifizierungsprobleme: sobald EntraID als IDP verwendet wird
- Funktionseinschränkungen bei allen Cloud-Produkten von Microsoft
Jetzt ist guter Rat teuer, denn das Ziel ist klar gesetzt: die ursprüngliche Situation mit den verschachtelten Usern und Devices muss wiederhergestellt werden.
Welche Optionen habe ich hierzu?
- Autorisierende Wiederherstellung des Baumes „OU=Happy,DC=CLOUD-HYBRID,DC=DE“ und des Objekts „CN=NoSync,OU=Groups,OU=ADDS,OU=Tier0,OU=ESAE,DC=CLOUD-HYBRID,DC=DE“?
- Forest-Restore?
- Arbeitgeber wechseln?
Alles nicht so berauschend…
Das große Problem: welcher User war in welcher ursprünglichen Gruppe?
Was einem jetzt wirklich hilft sind die Metadaten der problematischen Objekte im Active Directory.
Kurzer Auszug aus meinen Kursunterlagen:
Jedes Attribut, ab 2003 Forest Modus auch jeder Value, besitzt sog. Replication Metadata. Diese enthält Informationen, um eine konsistente Replikation zu gewährleisten. Die Metadaten werden im Attribut replPropertyMetaData des jeweiligen Objekts gespeichert, die mit Repadmin /showobjmeta gut betrachten werde können.
Metadaten sind Steuerdaten aufgrund derer die Objekte mit ihren Attributen und Werten im Active Directory zwischen den Domain Controllern abgegelichen werden.
Werden die Spalten von rechts nach links betrachet, haben wir folgende Zuordnung:
- Attribute: replikationsfähige Attribute, welche Werte aufweisen
- Ver: kurzform von Version. Wie häufig wurde der Attributwert bisher iteriert.
- Org. Time/Date: wann erfolgte die letzte Änderung (Zeiten immer local)
- Originating DSA: an welchem Domain Controller wurde die Änderung durchgeführt.
Metadaten einer Gruppe
Wie sehen die Metadaten einer Gruppe aus?
Die Metadaten einer Gruppe enthalten zusätzlich die aktuellen Mitglieder (PRESENT) und die ehemaligen Mitglieder (ABSENT).
Die ehemaligen?
Ja, wie sollte sonst das Verlieren einer Gruppenmitgliedschaft in der verteilten Datenbank kommuniziert werden?
Vorgehen
Wie wäre es also mit folgendem Vorgehen:
- Wir lesen alle betroffenen Gruppen im AD aus und untersuchen diese auf das Flag „ABSENT“.
- Pro Gruppe erstellen wir eine Textdatei (Grund: siehe unten), welche die abwesenden User und Devices beinhaltet. Über den Namen der Textdatei haben wir einen Bezug zum Gruppennamen
- Die Inhalte der Textdateien werden mit der Gruppe „NoSync“ verglichen. Ist der User oder das Device in „NoSync“ wird die ursprüngliche Gruppenmitgliedschaft wiederhergesetllt und die Gruppenmitgliedschaft in „NoSync“ beendet.
PowerShell oder repadmin.exe?
Erstaunlicher Weise ist hier ausnahmsweise eine cmd.exe mit repadmin.exe besser geeignet.
Das hat mit der banalen Tatsache zu tun, dass das Flag „ABSENT“ oder „PRESENT“ nicht von der PowerShell aufgebaut wird.
(Get-ADReplicationAttributeMetadata -Object "CN=Bayreuth,OU=Groups,OU=Happy,DC=CLOUD-HYBRID,DC=DE" -Server ch-vdc01 -Properties * -ShowAllLinkedValues).where{ $_.AttributeName -eq "member" } | Format-List -Property *
Wo hingegen die repadmin.exe kein Problem hat:
repadmin /showobjmeta CH-VDC01 ""CN=Bayreuth,OU=Groups,OU=Happy,DC=CLOUD-HYBRID,DC=DE""
Repadmin? Programmatisch?
Wenn man mit repadmin.exe programmatisch vorgehen will, programmatisch im Sinne der PowerShell, kann es hilfreich sein den Umweg über Textdokumente zu nehmen. Das grundlegende Problem ist es, dass repadmin.exe nur ein String-Objekt zurück liefert. Es ist daher sehr mühsam dieses String-Objekt in eine strukturierte Datenform wie JSON oder CSV zu bringen.
Zudem können diese banalen Textdateien für die Rolle rückwärts (fall back) genutzt werden und dienen noch zur Dokumentation.
$exUser = Get-ADGroupMember -Identity "NoSync"
$FilePath = "C:\temp"
$groups = Get-ADGroup -Filter { name -like "*" } -SearchBase "OU=Groups,OU=Happy,DC=CLOUD-HYBRID,DC=DE"
$groups.ForEach{
$hit = repadmin /showobjmeta $((Get-ADDomain).PDCEmulator) $_.DistinguishedName | Select-String -Pattern "ABSENT" -Context 0,2
if ($hit)
{
$hit | Out-File -FilePath $FilePath\$($_.sAMAccountName).txt
}
}
Aus den Textdateien müssen die überflüssigen Informationen entfernt werden, damit am Ende ein DistinguishedName drin steht. Der Name der Textdatei besagt noch immer welche Gruppe betroffen ist, der neue Inhalt tut kund, dass folgende User und Devices vielleicht wieder hinzugefügt werden müssen.
$FilesInPath = (Get-ChildItem -Path $FilePath -Include *txt -Recurse).FullName
$FilesInPath.foreach{
$DN = Get-Content -Path $_ | Select-String -Pattern "CN=" | Out-String
$DN = $DN.Replace(" ","").Trim()
$DN | Out-File -FilePath $_ -Force
}
Fast am Ziel
Der dritte und letzte Schritt. Die Textdateien werden ausgewertet und mit den Gruppenmitgliedern der Gruppe „NoSync“ verglichen. Ist der Vergleich positiv, wird der User oder das Device in die ursprüngliche Gruppe wieder verschachtelt und aus der Gruppe „NoSync“ entfernt. Zusätzlich wird ein Textdokument erstellt, welches diesen Vorgang dokumentiert.
$GroupFiles = (Get-ChildItem -Path C:\Temp -Include *.txt -Recurse).FullName
$GroupFiles.ForEach{
$SingleGroupFile = Get-Content -Path $_
$SingleGroupName = ($_).Replace("C:\Temp\","").Replace(".txt","")
foreach ($name in $SingleGroupFile)
{
if ($exUser.DistinguishedName -contains $name)
{
try { Add-ADGroupMember -Identity $SingleGroupName -Members $name
Add-Content -Path C:\Temp\GroupAdd.txt -Value "Added $($name) to $($SingleGroupName)."
Remove-ADGroupMember -Identity "NoSync" -Members $name -Confirm:$false }
catch { Write-Host -ForegroundColor Yellow -BackgroundColor Black "Error adding $($name) to $($SingleGroupName)." }
}
}
}
Und die Welt war wieder ganz!
Die User und die Devices freuten sich! Die Welt war wieder heile, man war wieder in der Wolke und konnte sich nach Lust und Laune anmelden, Daten teilen, zusammenarbeiten, chatten und sich elektonische Briefe schicken. Man war der Gruppe der Verdammten, „NoSync„, entronnen und trollte sich durch die diversen Rechnenzentren des Microsoft-Universums.
Bis, ja bis:
- der gleiche Mist nochmal passiert,
- die Lizenzen entzogen werden,
- der orangene Präsident die Wolke vaporisiert und die Welt gleich mit.
Aber ansonsten lebten sie glücklich bis ans Ende ihrer Tage (siehe oben).
ComputerLogbuch der IQunit, Sternzeit -297667.7092846271, Captian Handl
Der „call to action“ wird in meinen Artikeln vermisst, so teilte es mir die Admiralität der Vertrieb mit.
„Call to action“ heißt, ich soll auf den Kurs hinweisen, in dem man die obige Angelgenheit vermittelt bekommt.
Bitteschön: „Essential Active Directory 2025“ in dem Kapitel Replication Internals