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

Structurels

L’un des premiers risques seraient lors du déploiement de la fonctionnalité. Il est important de bien prendre en compte le côté irréversible de l’opération. Je recommanderai de vérifier en amont l’état de santé des DCs et de la topologie souhaitée. L’objectif étant de ne pas se coltiner une dette technique des familles à la suite d’une mauvaise conception.

Délégations

Attention à la délégation sur notre container (CN=Shadow Principal Configuration). Si ces derniers sont trop larges un type comme Waldo peut se définir Admin du Domain en créant un ShadowPrincipal. Et hop ! Une escalade invisible…

Sécurités

Continuons de parler d’escalade (perso, moi c’est le bloc jusqu’à ce que je ni**e deux ménisques), le risque d’une escalade furtive et temporaire…

Les mécanismes PAM octroyant des droits temporaires, l’usage d’un compte admin temporaire serait peu visibles dans les journaux d’audit et sont souvent peu, voire mal surveillés. Ainsi, un attaquant peut devenir Admin du Domain pour 1 heure réaliser une opération de type DCsync plus la création d’une backdoor et ce je la jouer à la David Copperfield…

Une attaque directe par ShadowPrincipals à travers un compte compromis ayant les droits PAM. De cette manière, notre Charlie ou Waldo peut créer un ShadowPrincipal ajoutant un TTL à un groupe d’administration (Tiers 0) sans à avoir besoin de modifier directement le groupe. Cette méthode permettrait de contourner un grand nombre de mécanisme de sécurité en place.

L’attaque par SID, le classique des classiques. Comme vu précédemment, l’attribut msDS-ShadowPrincipalSid accepte des SID internes et externes (dans le cas de forêt approuvé). Ainsi, une mauvaise gestion des relations d’approbations ou la compromission d’une forêt externe donnerait automatiquement un accès privilégié au SI local.

Opérationnels

La perte d’un accès administrateur qui aurait été délégué sur une mauvaise évaluation de la durée du TTL pourrait être lourd de conséquence. Risque de ne plus être administrateur durant une opération critique nécessitant les droits d’administrations par exemple et donc de se retrouver totalement bloqué.

Une complexité trop élevée peut également relever d’un frein. Cela peut rendre les débogages longs et fastidieux (un peu comme ma b**e… Très très drôle M’sieur…) ainsi que des comportements inattendus. La pire chose possible reste la mauvaise formation des équipes et le risque d’erreurs fréquentes par les équipes de Niveau 0 ou 1.

Gouvernances et Humains

De la mauvaise formation des équipes relèvent souvent de processus non définis ou totalement ignoré. Ainsi il ne serait pas rare d’assigner des TTLs trop longs dans le temps pour avoir la paix (qu’est-ce que la sécurité peut être pénible) ou de définir des TTLs trop courts et d’enchainer les élévations temporaires.

Se pose alors la question de « Mais à quoi sert le PAM finalement ? »

L’excès de confiance et son mauvais usage peut entrainer un faux sentiment de sécurité. Le PAM a été implémenté, nous ne risquons rien. Sauf que les comptes d’administrations ne sont pas protégés correctement et dans le cas de compromission d’un poste admin… Je ne fais pas de dessin hein ?

Audits et Conformités

Comme inscrit précédemment, les journaux d’évènements sont assez difficiles à identifier et à corréler dans le cadre d’attribution temporaire des droits. Ainsi, l’expiration d’un TTL n’est pas un évènement clair pour l’audit. Ce qui peut facilement limiter l’analyse et le diagnostic de la part des équipes.

C’est pourquoi il va être nécessaire de porter une vigilance particulière sur les événements suivants :

Event ID	Description / Rôles / Types
4728	Ajout à un groupe global
4732	Ajout à un groupe local
4756	Ajout à un groupe universel
4729	Expiration ou Suppression à un groupe global
4733	Expiration ou Suppression à un groupe local
4757	Expiration ou Suppression à un groupe universel
5137	Création d’un objet
5136	Modification d’un objet
5141	Suppression d’un objet
4672	Attribution de privilège élevés
4624	Logon d’un compte ayant des droits d’administration
4634	Logoff d’un compte ayant des droits d’administration
4648	Logon explicite d’un compte ayant des droits d’administration
4662	Accès d’objets AD sensibles
4719	Modification audit policy
1102	Effacement des journaux
4768/4769	Kerberos (corrélation des TTLs)

A cela s’ajoute les diverses solutions du marché qui viennent auditer la santé des SIs et notamment celui des AD. Ces derniers ne prennent pas en compte l’attribut member;TTL et ShadowPrincipal. Les SIEMs¹⁴ valant paroles d’évangiles pour les SOCs¹⁵, hop ni une ni deux l’informations passent à la trappe.

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.

Architecture

Il est important de noter qu’avant toutes choses, les serveurs en Tiers 0 ne doivent pas avoir accès à internet en dehors des URLs approuvés (et c’est non négociable) et ne doivent contenir QUE les logicielles d’architecture et de sécurité (donc vous me virez vos salop***ies de NinjaRMM, LogMeIn, TeamViewer et compagnie).

• URLs des serveurs antivirus (genre TrendMicro etc)
• URLs des serveurs de mises à jour Microsoft

Il va de soi qu’étant en Tiers 0, le réseau est isolé et filtré en entrée et sortie. Il n’y a pas d’administration direct depuis une ressources de Tiers 1 ou 2.

Ci-contre, la topologie comme cette dernière devrait l’être avec MIM et PAM. Le fait d’intercaler un server MIM-PAM entre notre ADDS et nos postes clients permettent d’user comme dit précédemment des mécanismes d’approbations de workflow et d’automatisation. Le serveur PAM doit être vu comme un bastion dans un réseau isolé de niveau T0.

La mise place d’une telle architecture va être relativement complexe pour moi au vu des ressources disponibles niveau homelab. Je vais donc me passer du serveur intermédiaire MIM PAM.

Cette topologie est compatible et valide bien qui moins recommandée quant aux risques accrus relatif à l’audit et d’un contrôle moins efficace. Cela nous demandera donc en contrepartie d’être irréprochable sur les groupes, droits et permissions lié à la délégation. Il sera nécessaire d’avoir un regard et contrôle réguliers des scripts Powershell.

Donc me concernant je resterai sur mon modèle en place de tiering T0-T1-T2 avec segmentation et contrôle des flux.

Comptes & IDs

Cela me semble logique, mais important de le répéter il ne faut en aucun cas user d’authentification interactif et de ne pas utiliser de compte administrateur. Et cherry on the cake, les comptes sont TOUJOURS nominatifs (oui même pour vous les éditeurs).

Ainsi, pas de compte admin permanent. 🙂

Néanmoins, il est important d’avoir des comptes brises-glaces afin de ne pas se couper l’herbe sous le pied. Dans la logique il en faudrait minimum deux et selon l’ANSSI maximum deux (Décidemment la sécurité c’est borderline). Naturellement ces comptes doivent être utilisés en cas d’extrême urgence et lors de leurs usages une alerte doit être notifiée.

Ce qu’il faut comprendre avec PAM, nous ne mettons pas tous nos œufs dans le même panier.

Nomenclatures des groupes

Après ce qui a été dit dans le volet ci-haut, il est nécessaire de définir des GGS¹⁹ propres au PAM et d’ajouter ces derniers en tant que membre des groupes adéquates.

Ainsi pour ma part j’userai de la nomenclature suivante :

GGS_PAM_NOM_Elevation

Simple et efficace.

Durée de vie

Crucial dilemme de la définition de la durée de l’élévation de droit temporaire… Dans la logique une intervention standard est de 30 à 60 minutes en cas de crise nous pourrions définir 120 minutes maximum. Toute durée supérieure à 2 heures et donc interdit.

Oui mais voilà, je dois faire une opération sensible en tant que SysAdmin sur un SI sur la journée comment je fais ?

Excellente question à laquelle je répondrai, nous sommes SysAdmin et donc nous avons l’accréditation pour intervenir sur notre SI. Donc je n’utiliserai pas PAM mais le système classique de mon compte utilisateur avec élévation de droit avec mon compte administrateur délégué ou super administrateur.

Mon presta doit faire une montée de version de la solution applicative sur l’un de nos serveurs pour la journée soit 7 heures de boulot. Comment tu réponds à ça Monsieur jesaistout ?

J’ai pour habitude de ne jamais laissé un prestataire intervenir seul sur mon SI ou un SI sous ma responsabilité. Donc je passe ma journée à surveiller d’un coin de l’œil ces actions. Et dans son cas, je me note de renouveler personnellement toutes les deux heures ça durée de vie. Généralement il n’y a pas trop besoin car le prestataire est administrateur local du serveur mais certaines fois il est nécessaire de lui octroyer les droits d’administrations du domaine (et ça, ça fait froid dans le dos et en dit long sur la topologie de la solution applicative…).

En complément, il en va de soi mais la tacite reconduction des renouvellements des TTLs et à bannir et encore une fois pas de TTL trop long par ne pas être emme**é toutes les deux minutes.

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 ↩︎