ADMPWD une solution de gestion du mot de passe administrateur local de vos systèmes Windows

Voilà un challenge que je retrouve dans beaucoup de projets de déploiement de poste de travail : Comment gérer le sacro-saint mot de passe administrateur local du poste de travail. C’est un sujet qui occupe toujours beaucoup et qui oppose :

  • La sécurité qui veut pouvoir le changer aussi souvent que possible et se parer contre la problématique Pass-The-Hash
  • L’exploitant qui en a besoin en cas de problème
  • Le support qui peut en avoir besoin lorsque le poste est dans la nature

Une recherche rapide chez le maitre Mark Russinovich et on trouve PsPasswd. L’avantage de sa solution, c’est qu’elle sûr à la base :

clip_image001

Certains pourront être tenté d’utiliser les GPO de préférence pour gérer le mot de passe Administrateur. Cependant, le mot de passe est-il chiffré ou juste dissimulé? Je vous laisse deviner la réponse (sic) :http://msdn.microsoft.com/en-us/library/cc422924.aspx.

Bref, on peut passer beaucoup de temps sur le sujet, mettre en œuvre différents processus pour invariablement arriver à avoir un mot de passe administrateur qui circule sous le manteau. Le problème, c’est que bien souvent, il est commun à une grande partie du parc de station, voire de serveur (ce qui est encore pire).

Pourtant ADMPWD existe depuis pas mal de temps et disponible sur CodePlex est l’une d’entre elle. Elle présente l’avantage de répondre à la majorité de nos problématiques tout en proposant un mode de fonctionnement que nous utilisons tous déjà beaucoup : BitLocker.

Pour rappel, BitLocker peut être configuré pour stocker la clé de recouvrement de chaque poste de travail dans l’annuaire Active Directory grâce à une extension de schéma. ADMPWD propose le même mode de fonctionnement mais avec sa propre extension de schéma (deux attributs en fait).

Dans le principe, chaque système configuré avec ADMPWD va générer son propre mot de passe administrateur et le stocker dans l’annuaire Active Directory avec pour instruction de revenir le changer selon une périodicité établie. On y voit tout de suite des avantages certains :

  • Plus personne ne connait le compte administrateur local
  • Chaque système génère son mot de passe administrateur propre
  • Même si on communique le mot de passe administrateur, ce n’est que pour un système donné et sa durée d’utilisation est limitée dans le temps.

Stocker un mot de passe dans l’annuaire Active Directory peut paraitre étrange quand on sait que l’information n’est pas chiffrée. Cependant, il y a une astuce. Par défaut, les attributs tous les attributs sont accessibles dès lors qu’on est authentifié, à l’exception des attributs confidentiels. Les attributs confidentiels ont été introduits avec Windows 2003 (KB922836). Cela permet de s’assurer que leur contenu ne sera accessible qu’à une population limitée. Dans le cas d’ADMPWD, ce sera à nous de fournir des groupes de sécurité pour définir :

  • Qui peut accéder au mot de passe Administrateur du système d’exploitation
  • Qui peut reconfigurer la durée de vie du dit mot de passe

Après cette rapide introduction, voyons comment le mettre en œuvre.

 

Etapes préparatoires

ADMPWD est disponible sous forme d’un package Windows Installer contenant tous les composants nécessaires. Avant de pouvoir l’installer, il conviendra de s’assurer que le Framework Dot.Net 4.0 minimum est installé. Si ce n’est pas le cas, c’est par ici que cela se passe. Dans le cas de mon contrôleur de domaine Windows Server 2012, le Framework est déjà installé. On peut donc commencer avec notre extension de schéma.

Dans sa forme pré-packagée, tout est disponible dans l’installer disponible à la fois pour la plateforme X86 et X64.

clip_image002

Pour les plus curieux, ADMPWD repose dur une Client-Side Extension (CSE) qui est un composant intégré aux stratégies de groupe. C’est ce composant qui va récupérer sa configuration dans une stratégie de groupe et réaliser le changement de mot de passe.

Sur notre contrôleur de domaine, le composant CSE n’est pas nécessaire. Les contrôleurs de domaines RWDC n’ayant pas de pas SAM, il n’y a pas de mot de passe administrateur local à maintenir (cela ne veut pas dire qu’il ne faut pas changer le mot de passe administrateur du domaine de temps en temps). Par contre, on va installer :

  • l’interface graphique pour relever/réinitialiser un compte administrateur
  • Le module Powershell
  • Le fichier modèle d’administration pour créer/gérer le paramétrage d’ADMPWD dans les GPO

clip_image003

Une fois installé, c’est maintenant que cela se complique. Si on tente d’importer le module ADMPWD.PS, on obtient l’erreur suivante.

clip_image004

Comme indiqué, ADMPWD requiert la présence du Framework Dot.Net 4.0 car on l’utilise bien. Par contre, l’installer ne veut pas dire qu’on l’utilise bien avec Powershell. Regardons un peu l’environnement d’exécution avec la variable $PSVersiontable.

clip_image005

Effectivement, notre moteur Powershell utilise le Framework Dot.Net 2.0. Aidons le un peu en créant le fichier de configuration "PowerShell.Exe.Config"

clip_image006

Et en plaçant celui-ci dans le répertoire c:\Windows\System32\WindowsPowershell\V1\".

clip_image007

Lorsqu’on relance une nouvelle invite de commande Powershell, la version du Framework Dot.Net utilisée est maintenant la bonne.

clip_image008

Note : c’est uniquement nécessaire pour utiliser le module Powershell.

Nous pouvons donc réaliser l’extension de schéma à l’aide de la commande Powershell "Update-ADMPWDADSchema" qui fonctionnera tant qu’on aura les privilèges nécessaires, …

clip_image009

Premier constat, deux attributs ont été ajoutés à la classe "Computers". Le premier désigne la date d’expiration du mot de passe administrateur et le second pour le mot de passe administrateur.

Maintenant rentrons un peu dans le cœur du sujet. Le premier besoin est que chaque système puisse mettre à jour son propre mot de passe Active Directory et inscrire la date d’expiration associée. Pour cela il faut s’assurer que la permission SELF dispose bien des privilèges nécessaires. La commande "Set-ADMPwdComputerSelfPermission" fait cela très bien. On peut même spécifier sur quel conteneur mettre en place la permission (pour les objets computers) de manière récursive. Dans mon cas, j’ai choisi les serveurs composant la fabric de mon cloud privé .

clip_image010

Second besoin, identifier qui pourra lire le mot de passe Administrateur des serveurs de ma fabric. On dispose de la commande "Set-AdmPwdReadPasswordPermission" pour accorder le privilège de lecture à un groupe donné (ADMPWD-Read dans mon cas). ADMPWD est assez souple pour permettre de proposer des permissions différentes en fonction des périmètres (station de travail, serveurs, …).

clip_image011

Même principe avec la commande "Set-ADMPwdResetPasswordPermission" pour réinitialiser ou modifier la date d’expiration du mot de passe et donc forcer son changement immédiatement ou à la date indiquée pour un périmètre donné (toujours les serveurs composants la Fabric de mon cloud prive) et une population donnée (le groupe de sécurité ADMPWD-Reset)

clip_image012

Maintenant, cela se complique. Comme le composant que nous allons installer sur nos système est une client-side extension de GPO, il va récupérer ces paramètres dans la clé de registre "HKLM\Software\Policies\Microsoft Services\AdmPwd". De ce fait, il faut l’enregistrer en conséquence. Cet emplacement est un peu particulier car même l’administrateur du système n’y a pas accès. C’est quelque peu logique que l’on ne puisse pas changer le paramétrage d’ADMPWD dans le registre. Ça aurait fait désordre. C’est aussi pour s’assurer du bon déclenchement du CSE lorsqu’un rafraichissement de stratégie de groupe surviendra. Par défaut, cela survient :

  • Au démarrage du système
  • Cycliquement avec une périodicité comprise entre 90 et 120 minutes
  • Toutes les 11 heures
  • Lors de l’exécution de la commande GPUPDATE /Force ou son équivalent Powershell

Pour cela, il est nécessaire de préalablement créé une stratégie de groupe avec la commande "New-GPO" qui sera utilisée pour propager le paramétrage d’ADMPWD.

clip_image013

Puis d’utiliser la commande "Register-ADMPwdWithGPO" pour réaliser la liaison avec la stratégie de groupe.

clip_image014

Dès lors, on peut prendre l’éditeur de stratégie de groupe (GPMC) et configurer les deux seuls paramètres.

clip_image015

Le premier permet de désigner le compte dont il faut changer le mot de passe. ADMPWD est intelligent car si on ne lui dit rien, il va automatiquement identifié le compte avec son well-known SID. C’est quand même super-pratique avec des systèmes installés en plusieurs langues. Avec cette approche, on retrouve toujours le compte administrateur, même si celui-ci a été renommé.

clip_image016

Pour la stratégie de mot de passe, c’est ici que cela se passe :

  • Majuscules
  • Majuscules + Minuscules
  • Majuscules + Minuscules + Chiffres
  • Majuscules + Minuscules + Chiffres + Caractères spéciaux

clip_image017

Reste plus qu’à lier la stratégie de groupe au conteneur contenant tous les serveurs de ma fabric.

 

Mise en place

Maintenant, y a plus qu’à installer l’extension CSE sur tous les serveurs de ma fabric.

clip_image018

Et lier la stratégie de groupe avec une petite commande “New-GPLINK”.

clip_image019

Et forcer une actualisation des stratégies de groupe (Depuis Windows 2012, on a Invoke-GPupdate )

 

Révélons le mot de passe

Déjà, on peut constater que le mot de passe est bien visible en clair dans l’AD. C’est normal que je puisse le voir, mon compte a été positionné comme membre des groupes “ADMPWD-Read” et “ADMPWD-Reset”. Si ce n’était pas le cas, je ne pourrais pas accéder à l’information.

clip_image020

Si on a pas le module Active Directory, on peut aussi utiliser la commande Get-AdmPwdPassword du module ADMPWD.PS

clip_image021

Ou bien utiliser l’interface graphique mise à disposition dans le package MSI

clip_image022

Au final, la solution ne présente que des avantages. Il devient criminel de s’en passer. C’est un excellent pour répondre à la problématique des attaques ciblant nos comptes BUILTIN qui ne sont pas soumis à la politique de verrouillage de mot de passe.

Pour ceux qui ne sont pas encore convaincus par la solution, le dernier commentaire de l’auteur devrait pouvoir rassurer les sceptiques.

clip_image023

Voilà pour la technique. Maintenant, il manque un peu de processus autour de cela. La sécurité, c’est pas que de la technique mais aussi du process. Donc, un prochain billet dur ADMPWD.

 

BenoîtS – Simple and Secure by design but business compliant

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.