Les articles publiés sur ce blog, ont pour but de partager des connaissances/concepts techniques et sont tous réalisés dans un environnement de test. Par conséquent, les auteurs dégagent toute responsabilité, de quelque ordre que ce soit, quant aux dommages directs, indirects ou consécutifs résultant de l’utilisation des informations contenus dans ceux-ci.
Introduction
La réalisation des actions indiquées dans cet article, nécessite que PAM soit configuré et installé comme décrit dans l’article sur l’installation de PAM.
Rappel du contexte
Relation d’approbation entre une forêt d’administration (red.lab) et une forêt de « production » (corp.lab) ayant les caractéristiques suivantes :
- Type : Forêt
- Direction : red.lab approuvée par corp.lab
- Authentification : sélective
L ‘exercice consiste à autoriser un compte de red.lab à devenir domain admins sur corp.lab.
Les demandes d’élévation de privilèges nécessitent l’installation du module PowerShell MIMPAM présent dans l’ISO de MIM 2016 SP1 (Drive>\Add-ins and extensions\x64\ Add-ins and extensions.msi). Lors de l’installation, il faudra :
- Choisir l’extension PAM Client
- indiquer l’URL de l’API :
- PAM Server Address : mimportal.red.lab
- Port: 5725
Configuration de l’élévation de privilèges dans PAM
L’élévation de privilèges temporaire à la demande dans PAM nécessite la configuration des objets suivants dans FIMService :
- PAM User : compte utilisateur/candidat à l’éligibilité autorisé à faire une demande d’élévation de privilèges.
- PAM Group : groupe de sécurité permettant d’accéder à la ressource.
- PAM Role : Contient le(s) candidat(s) éligible(s) à l’élévation de privilèges (groupe de sécurité). Cet objet fait le lien entre le(s) candidat(s) et le PAM Group.
Le compte qui va créer le PAM User, Group et role doit être administrateur du portail MIM et avoir la permission Allow To Authenticate sur corp.lab. Dans le contexte de l’article, nous utilisons le compte d’installation de PAM.
Création d’un PAM User
Depuis le serveur MIMPAM, ouvrez un prompt PowerShell runas admin et tapez les cmdlet suivantes :
Import-Module MIMPAM
Import-Module ActiveDirectory
New-PAMUser -SourceDomain red.lab -SourceAccountName VentDuNord -PrivOnly
Le switch PrivOnly, indique d’utiliser un compte existant dans red.lab
Afin de valider que le compte a bien été créé, tapez :
Get-PAMUser
Vous pouvez aussi, vérifier la création du nouveau PAM User dans le portail MIM
Création d’un PAM Group
Pour créer un PAM Group, ouvrez un prompt PowerShell en runas admin et tapez :
Import-Module MIMPAM
Import-Module ActiveDirectory
New-PAMGroup -SourceGroupName “Domain admins” -SourceDomain corp.lab -SourceDC dc-corp.corp.lab
Afin de valider la création du PAM Group, lancez adsiedit.msc, et sélectionnez la partition de configuration (Services, Shadow Principal Configuration)
Vous pouvez aussi vérifier la création du nouveau PAM Group dans le portail MIM
Création d’un PAM Rôle
Pour créer un PAM Role, tapez dans un prompt powershell runas admin:
Import-Module MIMPAM
Import-Module ActiveDirectory
$pg=Get-PAMGroup -PrivDisplayName “CORP.Domain admins”
$sj=Get-PAMUser -PrivDisplayName Ventdunord
New-PAMRole -DisplayName “CORP\Domain Admins” -Privileges $pg -Candidates $sj -TTL “00:45:00”
Le switch TTL, en secondes, indique la durée de l’élévation de privilèges (45 min dans notre exemple) par défaut la valeur est d’1 heure.
Afin de valider la création du PAM Role, tapez :
Get-PAMRole -DisplayName “CORP\Domain Admins”
Vous pouvez aussi vérifier la création du nouveau PAM Role dans le portail MIM
Demande d’élévation de privilèges
Comme nous pouvons le voir le compte red\VentDuNord ne peut pas ouvrir de session sur le contrôleur de domaine de corp.lab :
Activation du PAM Role
Pour activer le PAM Role :
- Loguez-vous sur une machine avec le compte éligible (red\VentDuNord)
- Ouvrez un prompt powershell runas admin:
$req= Get-PAMRoleForRequest -DisplayName “CORP\Domain Admins”
New-PAMRequest -Role $req
En tant qu’administrateur du domaine, red\VentDuNord est en mesure d’ouvrir une session sur le contrôleur de domaine de corp.lab.
Explication/Description du background
Comme nous pouvons le voir ci-dessous, le compte red\VentDuNord est vu comme étant membre du groupe CORP\Domain Admins et pourtant, dans la console ADUC (Active Directory User and Computers), il n’apparaît pas comme membre du groupe domain admins, d’autant plus que le groupe domain admins est d’étendue groupe global (donc ne peut contenir que des objets de son domaine) :
Vous vous rappelez du Shadow Principal et de son SID créé dans red.lab, au moment de la création du PAM Group?
Hé bien, c’est lui qui rentre en jeu. En fait, lors de l’élévation de privilèges le compte red\VentDuNord a été rajouté en tant que membre du Shadow Principal red\CORP.Domain admins pour une durée de 45 minutes:
Comme nous l’avons vu dans les rubriques précédentes, le SID du Shadow Principal CORP.Domain admins correspond au SID du groupe CORP\Domain admins. Aussi, si vous avez lu la rubrique sur la configuration de la relation d’approbation entre red.lab et corp.lab, nous avons activé le fait que les SID History traverse la trust (enablesidhistory:yes).
Finalement, on comprend que l’ajout du compte red\VentDuNord dans le Shadow Principal red\CORP.Domain admins, dont le SID correspond à celui du groupe CORP\dom admins, est ajouté au SID History du jeton Kerberos de red\VentDuNord. Ce qui explique comment red\VentDuNord peut devenir domain admins et se loguer sur le contrôleur de domaine de corp.lab sans être membre explicite du groupe domin admins, ni avoir la permission Allow To Authenticate (nécessaire dans le cas d’une trust avec authentification sélective).
Pour rappel, le role domain admins de corp.lab n’est actif/présent dans le jeton kerberos de red\VentDuNord que pendant la durée du TTL (dans notre cas 45 minutes)
Le détail des actions est accessible dans les Search Requests sur le portail MIM.
A ciao & have fun !!!