In diesem Teil unserer ESAE-Serie beschreiben wir näher den technischen Kern der ESAE-Umgebung, der die Just-in-Time-Administration möglich macht. Dieser Kern besteht aus den Shadow Principals, temporären Gruppen-Mitgliedschaften und dem Privileged Access Management (PAM) des Microsoft Identity Manager (MIM).
Ein Gastbeitrag der TEAL Technology Consulting
Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie alle Teile nacheinander lesen.
-
- Teil 1: Basics & Architekturplanung
- Teil 2: Privileged Access Management & Shadow Principals (dieser Beitrag)
- Teil 3: Schutzmaßnahmen für die Umgebung
- Teil 4: Windows IPSec im Detail erklärt
- Teil 5: Die ESAE-Architektur von Microsoft
- Teil 6: ESAE ist tot, lang lebe SAE!
Das bietet dieser Teil der ESAE-Serie:
Konzeptionelle Funktionsweise
Zunächst beschreiben wir die Funktionsweise von temporären Gruppen-Mitgliedschaften und Shadow Principals, bevor wir die Funktionsweise im Zusammenspiel mit MIM genauer erklären.
Temporäre Gruppen-Mitgliedschaften
Temporäre Gruppen-Mitgliedschaften sind ein Teil des optionalen AD-Features „Privileged Access Management“ von Windows 2016. Es erlaubt, wie es der Name schon sagt, dass Benutzerkonten nur für eine gewisse Zeit Mitglied einer Gruppe sind.
Das Active Directory stellt sicher, dass die Gruppen-Mitgliedschaft genau zu dem gewünschten Zeitpunkt abläuft, indem es die Kerberos Ticket Granting Ticket (TGT) Lifetime auf die gleiche Laufzeit setzt wie die kürzeste time to live (ttl) einer Gruppen-Mitgliedschaft.
Ein Beispiel: Der Benutzer René hat beim Log-on eine Restlaufzeit in der Gruppe Domain Administratoren von 5 Minuten und eine Restlaufzeit in der Gruppe Enterprise Administratoren von 10 Minuten. Der Domain Controller stellt daraufhin ein TGT mit einer Laufzeit von 5 Minuten aus.
Temporäre Gruppen-Mitgliedschaften könnten auch eigenständig, ohne Shadow Principals und MIM-PAM verwendet und per PowerShell konfiguriert werden (siehe unten).
Shadow Principals
Ein Shadow Principal ist ein Objekt, das einen Benutzer, eine Gruppe oder ein Computerkonto aus einem anderen Forest repräsentiert. Die Shadow Principals sind ebenfalls Teil des PAM-Features. Um ein Shadow Principal für den Zugriff auf Ressourcen nutzen zu können, ist eine neue Art der Vertrauensstellung notwendig: der PAM Trust. Beim PAM Trust handelt es sich um eine Erweiterung des bekannten Forest Trusts.
Um die Shadow Principals für unsere Zwecke nutzen zu können, wird neben dem Produktions-Forest ein sogenannter Admin Forest (oder auch Red Forest) aufgebaut und ein PAM Trust eingerichtet. Dabei vertraut der Produktions-Forest dem Admin Forest.
Anschließend können Shadow Principals im Admin Forest angelegt werden, die die SID von Gruppen, zum Beispiel die Domain-Administratoren-Gruppe, im Produktions-Forest innehaben. Im nächsten Schritt werden Benutzer im Admin Forest dem „memberof“-Attribut der Shadow Principals hinzugefügt.
Meldet sich nun der Benutzer des Admin Forest aus dem Beispiel an einer Ressource im Produktions-Forest an, führt er die SID der Domain-Admin-Gruppe im Ticket mit und kann entsprechend privilegierte Tätigkeiten, bspw. DCPromo oder Schema-Erweiterungen, durchführen.
Shadow Principals können ebenfalls ohne temporäre Gruppen-Mitgliedschaften und MIM-PAM verwendet und mittels PowerShell konfiguriert werden.
MIM-PAM
Wenn man sich vor Augen hält, dass man durch die Shadow Principals die Privilegien im Produktions-Forest erhalten kann, ohne ein Benutzerkonto in diesem Forest zu haben, hat das einige Vorteile. Zum Beispiel gibt es für Tools wie Bloodhound keinen Weg, Benutzer mit diesen Rechten zu identifizieren.
Allerdings birgt diese Technik auch Gefahren. Es ist mit Active-Directory-Bordmitteln nur sehr schwer zu überwachen, wer wann die erhöhten Rechte verwendet hat. Hier kommt der MIM mit der PAM-Funktionalität ins Spiel, um die beiden anderen Technologien für die Just-in-Time- Administration mit entsprechender Governance zusammen zu bringen.
Wenn MIM-PAM implementiert ist, ist kein Benutzerkonto im Admin Forest per se Mitglied eines Shadow Principals. Mittels MIM-PAM werden Rollen definiert. Diese regeln, wer sich wann welche Privilegien für wie lange anfordern darf. Ein Genehmigungs-Workflow kann ebenfalls definiert werden.
Als Beispiel könnte es eine Rolle „Domain Admin“ geben, welche die Benutzer zum Shadow Principal „Domain Administratoren“ hinzufügt. Die Rolle darf von den Benutzern Fabian und Manuel zwischen 8 und 16 Uhr angefordert werden. Der Benutzer Alexander muss die Anfrage genehmigen. Die Rolle hat eine Laufzeit von 60 Minuten.
Die Rollen können entweder durch PowerShell oder durch ein optionales Portal angefordert werden. Die Anforderung und Vergabe der Rollen wird entsprechend geloggt.
So setzt man es um
Und nun von der Theorie zur Praxis:
Temporäre Gruppen-Mitgliedschaften
Für temporäre Gruppen-Mitgliedschaften muss, wie oben erwähnt, das optionale Feature „Privileged Access Management“ aktiviert werden. Dazu ist es erforderlich, dass das Forest Functional Level mindestens auf 2016 steht.
Das Feature kann mit folgendem Befehl aktiviert werden:
Enable-ADOptionalFeature ‘Privileged Access Management Feature’-Scope ForestorconfigurationSet -Target corp.customer.de
Anschließend können wir einen Benutzer für eine begrenzte Zeit einer Gruppe hinzufügen:
Add-ADGroupMember -Identity ‘Domain Admins’ -Members ‘Rene’ -MemberTimeToLive (New-TimeSpan -Days 5)
Um die TTL von Gruppen-Mitgliedschaften anzuzeigen, kann folgender Befehl verwendet werden:
Get-ADGroup ‘Domain Admins’ -Property member -ShowMemberTimeToLive
Shadow Principals
Auch hier muss das optionale Feature „Privileged Access Management“ aktiviert werden.
Enable-ADOptionalFeature ‘Privileged Access Management Feature’-Scope ForestorconfigurationSet -Target red.customer.local
Der vertrauende Produktions-Forest muss ebenfalls das Forest Functional Level 2016 haben oder Windows Server 2012 R2 mit dem Patch KB3156418.
Nach der Aktivierung des Features gibt es einige relevante Objekte und Klassen:
msDS-ShadowPrincipalContainer
In diesem Container werden alle Shadow Principals gespeichert. Der default-Container wird hier angelegt:
CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=customer,DC=de
Prinzipiell können weitere Container angelegt werden, diese funktionieren dann aber nicht mit Kerberos.
msDS-ShadowPrincipal
Diese Klasse repräsentiert ein Objekt aus einem externen Forest. Objekte dieser Klasse können nur in einem Shadow Principal Container erstellt werden, und das Attribut msDS-ShadowPrincipalSid muss einen Wert besitzen.
Ein Shadow Principal kann einen beliebigen Benutzer, eine Sicherheitsgruppe oder einen Computer repräsentieren. Ebenso wie bei temporären Gruppen kann man beim Member Attribut eine time to live setzen.
Wenn der Shadow Principal im Standardcontainer CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=customer,DC=de angelegt wurde, wird die Mitgliedschaft eines Benutzers in diesem Shadow Principal in das Kerberos-Ticket eingefügt, wie bei jeder anderen Gruppen-Mitgliedschaft auch. Allerdings gilt die Einschränkung, dass nur Benutzer des gleichen Forest Mitglied eines Shadow Principals sein können.
msDS-ShadowPrincipalSid
Dieses Attribut enthält die SID des Objekts aus dem externen Forest. Man kann keine SID aus der gleichen Domain oder dem gleichen Forest hinzufügen. Natürlich muss ein entsprechender Trust vorhanden sein, um die SID hinzufügen zu können.
Nutzung der Shadow Principals
Bevor die Shadow Principals sinnvoll verwendet werden können, muss zunächst ein entsprechender Trust angelegt werden (Voraussetzung: funktionierende Namensauflösung zwischen den Forests). Dabei müssen die Trust-Attribute „SIDHistory“ auf „Yes“ und „Quarantine“ auf „No“ konfiguriert werden.
Folgende Befehle sind in der produktiven Domäne auszuführen:
netdom trust corp.customer.de /Domain:red.customer.local /Add /UserD:administrator@red.customer.local /PasswordD:* /UserO:administrator@corp.customer.de /PasswordO:*
netdom trust corp.customer.de /domain:red.customer.local /ForestTRANsitive:Yes
netdom trust corp.customer.de /domain:red.customer.local /EnableSIDHistory:Yes
netdom trust corp.customer.de /domain: red.customer.local /EnablePIMTrust:Yes
netdom trust corp.customer.de /domain: red.customer.local /Quarantine:No
Im Red Forest ist folgender Befehl auszuführen:
netdom trust red.customer.local /domain:corp.customer.de /ForestTRANsitive:Yes
Anschließend können wie in nachfolgendem Beispiel die Shadow Principals mittels PowerShell verwendet werden. So wird ein Shadow Principal für die Domain-Admin-Gruppe aus dem Produktions-Forest angelegt:
$CORPPrincipal = “Domain Admins”
$CorpDC = “corpdc02.corp.customer.de”
$ShadowSuffix = “CORP-“
$CorpShadowPrincipal = Get-ADGroup -Identity $CORPPrincipal -Properties ObjectSID, SamAccountName -Server $CorpDC
$ShadowPrincipalContainer = “CN=Shadow Principal Configuration,CN=Services,”+(Get-ADRootDSE).configurationNamingContext
New-ADObject -Type “msDS-ShadowPrincipal” -Name “$ShadowSuffix$($CorpShadowPrincipal.SamAccountName)” -Path $ShadowPrincipalContainer -OtherAttributes @{‘msDS-ShadowPrincipalSid’= $CorpShadowPrincipal.ObjectSID}
Jetzt können wir einen Benutzer aus dem Admin Forest zum Member-Attribut hinzufügen und ihm so – wenn gewünscht – temporäre Rechte im Produktions-Forest geben:
Set-ADObject -Identity “CN=CORP-Domain Admins, CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=red,DC=customer,DC=local” -Add @{‘member’=”<TTL=3600, CN=Manuel,CN=Users,DC=red,DC=customer,DC=local>”}
MIM-PAM
Die Darstellung der Installation von MIM-PAM würde den Rahmen dieses Beitrags deutlich sprengen, weshalb wir an dieser Stelle auf die Dokumentation von Microsoft verweisen. Allerdings möchten wir gerne zeigen, wie sich Rollen anlegen und anfordern lassen, sowie die oben genannten Log-Einträge aufzeigen.
Zuerst den User zu PAM hinzufügen:
$user = New-PAMUser -PrivOnly -SourceDomain red.customer.local -SourceAccountName “Manuel”
$user
Dann die Gruppe zu PAM hinzufügen:
$cred = Get-Credential
$group = New-PAMGroup -SourceGroupName “Server Admins” -SourceDomain corp.customer.de -SourceDC corpdc02.corp.customer.de -Credentials $cred
Abschließend die neue Rolle definieren:
$role = New-PAMRole -DisplayName “CorpAdmins” -TTL 00:03:00 $group -Candidates $user
Nun kann der Benutzer die Rolle wie folgt anfordern:
New-PAMRequest -RoleDisplayName “CorpAdmins”
Folgendes ist im MIM-Log zu sehen:
Die Rolle läuft automatisch ab:
Die Rechte können aber auch wie folgt vorzeitig zurückgegeben werden:
Close-PAMRequest -RoleDisplayName “IT”
Versucht ein Benutzer, der nicht berechtigt ist, die Rolle anzufordern, erhält man die folgende etwas irreführende Fehlermeldung:
Fazit
Zusammenfassend kann man sagen, dass uns Microsoft mit den Shadow Principals ein mächtiges Werkzeug in die Hand gegeben hat, um Credential-Theft-Attacken zu erschweren. Allerdings muss der Red Forest besonders geschützt werden, um Missbrauch zu verhindern. Was wir in unserem konkreten Kundenszenario dafür getan haben, beschreiben wir im kommenden Beitrag.
Hier noch ein paar weiterführende Links:
Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie auch die folgenden Teile lesen:
Über den Autor:
Die TEAL Technology Consulting GmbH ist spezialisiert auf Infrastruktur-Security-Projekte im On-Premises- und Cloud-Umfeld. Zudem gehört TEAL zu den führenden Anbietern für die Adaption des Microsoft ESAE-Modells zur sicheren Infrastruktur-Administration. Als Partnerfirma ergänzt TEAL sinnvoll das Portfolio der FB Pro GmbH.
Bilder: Pixabay, TEAL / Microsoft