WIN – ADDS & Temporary Group Membership

Il n’est jamais trop tard pour parler de sécurité et de découvrir des fonctionnalités existantes sur lesquelles je suis passé allégrement à côté et ce depuis 2016… Comme quoi, il n’est jamais trop tard.

Alors de quel mécanisme de sécurité vais-je aborder ?

Dans l’ère du temps, nous parlons sans cesse de PAM¹, PIM², ZTNA³, termes qui jusqu’il y a quelques années étaient obscurs et commençaient tous justes à émerger. Si aujourd’hui ces termes sont incontournables, je m’interroge à implémenter ces derniers dans un environnement OnPremise (pour ne pas dire mon environnement) en tenant compte :

• Du modèle de tiering de l’infrastructure
• De la segmentation en place des rôles et permissions
• Du durcissement de sécurité

Toutefois et encore une fois, comme le disait un ancien collègue la sécurité ce n’est pas pratique et je souhaite mettre en place une certaine souplesse à certains comptes utilisateurs bien identifiés.

Pif, PAM, Pouf, Je suis informaticien ; Pif, PAM, Pouf ça c’est vraiment trop bien !

Donc me voilà parti pour l’étude et l’implémentation d’une des fonctionnalités PAM fournit par Windows, l’appartenance temporaire à un groupe ou Temporary Group Membership (TGM⁴).

Avant-Propos

Je pars du principe que nous avons un environnement Windows avec un contrôleur ADDS⁵. Ce dernier est OnPremise est non hybride (pas de jonction avec AAD⁶).

Notre architecture se base sur la segmentation en tiering de notre SI⁷ et notre ADDS est durci selon les préconisations de l’ANSSI⁸.

L’objectif que je me fixe est donc de mettre en place la fonctionnalité d’attribution de droit d’administration temporairement à un utilisateur sans à avoir de :

• Créer un compte d’administration dédié à un usage ponctuel
• D’attribuer les droits d’administration (domaine ou local) permanent

Comme d’accoutumé (car nous ne changeons pas les bonnes vieilles habitudes) l’environnement Windows sera durci selon les bonnes pratiques et j’utiliserai mes deux contrôleurs de domaine 2025 en CORE.

Prérequis

• SE :
  • Windows Server : 2k16 et version ultérieures
• Apps :
  • ADDS
• Autres :
  • Non applicable

Théorie

Il est important de comprendre comment fonctionne et ce qu’apporte l’ajout de la fonctionnalité « Privileged Access Management Feature ».

Il est impératif et primordial que l’ensemble des serveurs AD soit au minima en version WS 2k16 et donc que le schéma de la forêt soit en version 2016.

Au vu des derniers propos énoncés, nous pouvons nous douter que nous allons altérer le schéma de notre AD. Ce qui est implicite (mais enfonçons une porte ouverte), l’installation de cette fonctionnalité sera irréversible (oui c’est une extension du schéma… La base j’en encore envie d’écrire. Oups c’est fait).

Extension du schéma Active Directory

Je juge important de savoir ce qui va être ajouté. C’est pourquoi une sous partie va être nécessaire pour regarder plus en détail la liste des nouveaux objets et attributs.

La liste n’est pas longue. Toutefois il convient de rappeler que « ce n’est pas le nombre d’objet qui fait la force » mais leur usage.

Et avec tous les points, quand est-il des risques ? Oh quasi rien (#MDR)

Risques

Recommandations

Les objectifs sont de pouvoir garantir AUCUN accès administrateur permanent afin d’obtenir une élévation temporaire, traçable et approuvée (je reviendrai sur ces points dans la partie pratique). Tout cela afin de contenir et maitrisé en cas de compromission l’impact ainsi que la surface d’exposition.

Il est également primordial de comprendre que l’usage du PAM au sens windows du terme ne doit servir que pour :

• Admin du Domaine
• Administrateur de l’entreprise
• Administrateur du schéma
• Administrateurs DC¹⁶
• Autres (Comptes ADCS¹⁷, ADFS¹⁸, AAD Connect)

L’usage pour du helpdesk ou pour des serveurs applicatifs doit être proscrit. Ce qui est logique car il revient à Services Informatiques d’arbitrer sur les demandes utilisateurs. Néanmoins, pour octroyer des droits d’administrateur à un stagiaire ou prestataire ça fonctionne très bien mais encore une fois sous réserve DE certains mécanismes.

Cela passe donc par plusieurs axes.

Bien je pense qu’avec tout ça nous en savons assez pour passer à la pratique non ?

Pratique

Installation

Commençons par vérifier le niveau fonctionnel de notre forêt. Nous retrouvons la commande qui devient normalement un automatisme maintenant 🙂

> Get-ADForest

La preuve à l’appui, ci-contre la preuve que pour l’attribut ForestMode la valeur Windows2016Forest est présente. Donc les prérequis sont atteints. Néanmoins, je recommande un petit contrôle de santé de l’AD par précaution et actions avant de poursuivre.

Vérifions maintenant si la fonctionnalité est déjà présente ou non sur notre SI.

> Get-ADOptionalFeature -Filter "name -eq 'Privileged Access Management Feature'"

Si la valeur de l’attribut EnabledScopes est vide, la fonctionnalité n’est pas déployée sur le système. Sinon ba elle l’est déjà. Evident Cap’taine Obvious !

Activons alors cette fonctionnalité.

/!\Attention : C’est à ce moment que l’opération devient irréversible. Et deuxième point de vigilance il faut que nous soyons administrateur du schéma temporairement

> Enable-ADOptionalFeature 'Privileged Access Management Feature' -Scope ForestOrConfigurationSet -Target ronelab.lan

Il suffira de valider le déploiement en activant la touche T pour oui pour tout. Et quelques secondes plus tard, c’est terminé. Oui tous ces mots pour ça… Il faut bien faire durer le plaisir non ? <3

Si nous voulons vraiment valider le bon déploiement de notre fonctionnalité, nous pouvons rappeler la seconde commande ci-haut pour vérifier les paramètres d’activation de notre scope.

Nous constatons donc que cette dernière n’est plus vide ou $null. Nous pourrions également aller nous balader dans la configuration de notre AD pour trouver notre container.

Place à l’assignation temporaire des droits 🙂

Attribution temporaire

Bhin alors comment qui font qu’on fait pour assigner des droits temporaires ?

De la manière la plus simple du monde gazier, même si au passage il faudrait parler un langage au minima courant plutôt que familier.

Pour se faire, un compte admin et un accès à l’un de nos DCs en powershell (où au DC en lui même). Je proscris volontairement les RSATs. Pourquoi ? Parce qu’un DC doit être le plus isolé possible.

# Définir notre TTL en secondes en tant que variable de type Timespan
> $ttl=New-TimeSpan -Hours 1 -Minutes 15
# Ajouter notre utilisateur temporairement au groupe
> Add-ADGroupMember -Identity "GGS_PAM_AdminDomain_Elevation" -Members "john.doe" -MemberTimeToLive $ttl

Et c’est tout. Je vous l’avais dit, rien de bien difficile. Un peu de RTFM et de ligne de commande… Ce qui est intéressant c’est de s’attarder sur les événements de sécurité. Nous retrouvons avec exactitude ce que nous avons énoncé dans la partie théorie concernant le périmètre d’audit.

Ouai mais alors comment vérifier que notre utilisateur à bien des droits qui court dans le temps ?

Vérifications et Analyses

Soyons un peu curieux et penchons nous dans les attributs de notre objets utilisateurs, groupe d’élévation (auquel appartient notre utilisateur) et notre groupe final.

No Surprise ! Il n’y a rien !

Etonnant non ? 🙂 J’ai été surpris et j’ai donc reparcouru la documentation en long, large diagonale… Pourquoi pouvons nous obtenir l’information en powershell (oups j’ai divulgâché la suite) et pas en GUI ?

C’est là que c’est malin. La durée de vie se trouve sur le lien entre l’objet utilisateur et le groupe d’appartenance (rien sur le groupe cible ce qui est logique).

> Get-ADGroup -Filter * -Properties members -ShowMemberTimeToLive | Where-Object {$_.members -match "TTL*"}

Et donc côté Kerberos qu’est ce qui se passe ? La documentation en parle et nous invite à être vigilant sur ces événements (4768 et 4769). Naturellement comme tout ajout à un groupe, il est nécessaire de fermer et d’ouvrir de nouveau la session pour prendre en compte le changement.

#Dans le contexte de l'utilisateur
> klist

Nous pouvons donc constater (modulo mon temps d’ouverture de session) que notre TGT20 à une durée de 1h11 / 1h15. Ce qui correspond à la durée définit dans notre délégation. Une fois le temps imparti passé, le ticket sera renouvelé et donc les droits temporaires d’administrations retirés.

Et alors côté journaux d’événements qu’elles sont les nouvelles ma sœur Anne (#BARBEBLEU) ?

J’ai envie de dire il suffit de parcourir les journaux d’évènement de sécurité.

Bon par contre ne nous cachons pas c’est un peu pénible pour ne pas dire casse-cou***e de taper les requêtes powershell. Il faut définir le TTL, connaitre les SAMs des utilisateurs, connaitre les groupes. Bref, source d’erreur à gogo. Alors à votre avis en tant que fainéant qu’ais je bien pu faire ? 🙂

Applications

Oui, cela peut paraitre étrange, mais j’ai réalisé une application GRAPHIQUE. Un jour à marquer dans les calendriers FOR SURE d’une bière blanche !

J’ai commencé à faire l’outil en PS CLI, mais j’ai vite trouvé que cela n’était pas ergonomique. Alors je me suis demandé pourquoi ne pas réaliser une application en VB.NET ? Flemme monstrueuse. Puis pourquoi pas reprendre une frustration passé du GUI en powershell ?

Hé bien voilà, que je réouvre une vieille blessure et alors quel pied put**n ! Je me suis éclaté.

Bon il reste quelques points à améliorer :

• Multitâche pour retourner les valeurs de l’AD
• Ajouter des petites icones sympas
• Ajouter un petit About (j’ai droit à mes droits d’auteur)
• Publier l’application en certifiant cette dernière
• Quelques contrôles d’erreurs ? :p

Bref pas mal de petite chose mais rien de bien méchant.

Démonstration

Rien de telle qu’une petite démonstration en images successives pour comprendre, aussi appelé vidéo.

Github

Miaou

Conclusion

Je mettais attaqué à ce morceau en ne pensant à la base ne pas y consacrer autant de temps. Je me suis rendu compte une nouvelle fois que ce sont les choses les plus simples qui requiert davantage de recul et de réflexion.

Je lutte encore entre les bonnes pratiques et recommandations contre mon usage et le périmètre d’applicabilité. Dans un certaine mesure PAM, PAM, PAM je me mettrai bien une cartouche pour ne pas avoir connu plus tôt cette fonctionnalité. Bref, il est nécessaire d’étudier avec sérieux son implémentation et son usage.

Je n’ai volontairement pas abordé le système de délégation des droits AD et sur les GPOs. Mais cela reste un impondérable car tout va reposer sur cette base. Ouvrir d’un côté pour mieux fermer de l’autre, dilemme cornélien que la sécurité. Et honnêtement si j’avais traité ce point, l’article serait insoutenable (comme la poitrine de PAMELA dans Alerte à Malibu ; Franchement tu devais la faire celle-là espèce de 90tard, tu ne pouvais pas t’en empêcher ?).

Je suis conscient qu’il reste des axes d’améliorations (notamment sur le code). Toutefois, je pense que si suite il doit y avoir cela plus sur PIM ce qui ouvrira la voie vers l’environnement Azure.

Le mot de la fin :

Si je PAM sur PAMELLA ? J’offre un CADEAU en infogérance ? Malheureusement vous ne pouvez pas Jean-Pat il y a une « couille dehors » en diagonale. Vous retournez en case magouille. Un partout PAM au centre…

Erwan GUILLEMARD

Sources

• Microsoft : Fonctionnalités WS 2k16
• Microsoft : PAM
• Microsoft : Class ShadowPrincipal
• Microsoft : Class Container ShadowPrincipal

1. PAM : Privilege Access Manager ↩︎
2. PIM : Privilege Identity Manager ↩︎
3. ZTNA : Zero Trust Network Access ↩︎
4. TGM : Temporary Group Membership ↩︎
5. ADDS : Active Directory Domain Service ↩︎
6. AAD : Azure Active Directory ↩︎
7. SI : Système d’Information ↩︎
8. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
9. SID : Security IDentifier ↩︎
10. AD : Active Directory ↩︎
11. TTL : TimeToLive ↩︎
12. MIM : Microsoft Inditity Manager ↩︎
13. PIM : Privileged Identity Manager ↩︎
14. SIEM : Security Information Event Management ↩︎
15. SOC : Security Operation Center ↩︎
16. DC : Domain Controler ↩︎
17. ADCS : Active Directory Certificates Services ↩︎
18. ADFS : Active Directory Federation Services ↩︎
19. GGS : Groupe Global de Sécurité ↩︎
20. TGT : Ticket Granting Ticket ↩︎