7 minutes reading time (1497 words)

ESAE Serie Teil 3 – Privileged Access Management und Shadow Principals Feature

cyber-security-600_360

Wie bereits im letzten Artikel (LINK) zur ESAE Serie angekündigt, möchten wir in diesem Artikel den technischen Kern der an ESAE orientierten Umgebung, der die Just-in-Time-Administration möglich macht, näher beschreiben. Dieser Kern besteht aus den Shadow Principals, temporären Gruppenmitgliedschaften und dem neuen Microsoft Identity Manager (MIM) Modul „Privileged Access Management (PAM)".

Konzeptionelle Funktionsweise

Zunächst möchten wir kurz die Funktionsweise von temporären Gruppenmitgliedschaften und Shadow Principals beschreiben, bevor wir die Funktionsweise im Zusammenspiel mit MIM genauer erklären.

Temporäre Gruppenmitgliedschaften

Temporäre Gruppenmitgliedschaften sind ein Teil des optionalen AD Features „Privileged Access Management" von Windows 2016. Es erlaubt, wie der Name schon sagt, dass Benutzerkonten nur für eine gewisse Zeit Mitglied einer Gruppe sind.

Das Active Directory stellt sicher, dass die Gruppenmitgliedschaft 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 Gruppenmitgliedschaft.

Ein Beispiel: Der Benutzer René hat beim Logon 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 Gruppenmitgliedschaften könnten auch eigenständig, ohne Shadow Principals und MIM-PAM verwendet werden 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, z.B. 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, wie z.B. DCPromo, Schemaerweiterungen etc. durchführen.

Shadow Principals können ebenfalls ohne temporäre Gruppenmitgliedschaften und MIM-PAM verwendet und mittels PowerShell konfiguriert werden.

MIM-PAM

Wenn man sich vor Augen hält, dass man durch die Shadow Principals Privilegien im Produktions-Forest erhalten kann, ohne ein Benutzerkonto in diesem Forest zu haben, hat das einige Vorteile. Z.B. 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 zusammenzubringen.

Wenn MIM-PAM implementiert ist, ist kein Benutzerkonto im Admin Forest per se Mitglied eines Shadow Principals. Mittels MIM-PAM werden Rollen definiert, die regeln wer sich wann welche Privilegien für wie lange anfordern darf. Ein Genehmigungsworkflow 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 gelogged. 

Technische Funktionsweise

Temporäre Gruppenmitgliedschaften

Für temporäre Gruppenmitgliedschaften muss, wie oben erwähnt, das optionale Feature „Privileged Access Management" aktiviert werden. Dazu muss das Forest Functional Level mindestens 2016 sein.

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 Gruppenmitgliedschaften 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 2012R2 mit dem Patch KB3156418 (https://support.microsoft.com/en-us/help/3156418/may-2016-update-rollup-for-windows-rt-8-1-windows-8-1-and-windows-serv ).

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 Gruppenmitgliedschaft 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: Namensauflösung zwischen den Forests muss funktionieren). Dabei müssen die Trust-Attribute „SIDHistory" auf „Yes" und „Quarantine" auf „No" konfiguriert werden:

Folgende Befehle müssen in der produktiven Domäne ausgeführt werden:

netdom trust corp.customer.de /Domain:red.customer.local /Add /UserD:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! /PasswordD:* /UserO:Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! /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.

Mit den nachfolgenden Befehlen 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 des Artikels deutlich sprengen, weshalb wir an dieser Stelle nur auf die Dokumentation von Microsoft verweisen wollen (https://docs.microsoft.com/de-de/microsoft-identity-manager/pam/configuring-mim-environment-for-pam) .

Allerdings möchten wir gerne zeigen, wie sich Rollen anlegen und anfordern lassen, sowie die oben genannten Logeinträ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" 

Die Rechte können aber auch wie folgt vorzeitig zurückgegeben werden:

Close-PAMRequest -RoleDisplayName "CorpAdmins" 

Versucht ein Benutzer, der nicht berechtigt ist, die Rolle anzufordern erhält man die folgende etwas irreführende Fehlermeldung:  

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 im konkreten Kundenszenario dafür getan haben, möchten wir im nächsten Artikel beschreiben.

Ein besonderer Dank gilt Holger für die MIM-PAM Screenshots ????.

Nachfolgend noch einige Quellen und weiterführende Links:

https://secureidentity.se/msds-shadowprincipal/

https://blogs.technet.microsoft.com/fieldcoding/2017/05/09/privileged-access-management-demystified/

https://blogs.technet.microsoft.com/askds/2016/03/09/previewing-server-2016-tp4-temporary-group-memberships/

https://docs.microsoft.com/de-de/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services

https://docs.microsoft.com/en-us/powershell/module/mimpam/?view=idm-ps-2016sp1

ESAE Serie Teil 4 – Schutzmaßnahmen für die Umgebu...
Hybrid Container deployment mit Jenkins

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Guest
Dienstag, 20. August 2019