Mots de passe dans les attributs Active Directory : le champ Description lisible par tous

Pourquoi ces attributs sont lisibles par tous

Active Directory est conçu comme un annuaire : par défaut, les utilisateurs authentifiés peuvent lire la plupart des attributs des objets utilisateurs, groupes et ordinateurs. C'est ce qui permet aux carnets d'adresses, aux applications et aux outils d'administration de fonctionner. La contrepartie est simple : tout ce qui est écrit dans un attribut non protégé est à la portée de n'importe quel compte du domaine, y compris un compte de stagiaire ou un compte d'ordinateur compromis.

Les attributs à surveiller

Le cas de userPassword mérite une précision. Selon un paramètre de la forêt (dans l'attribut dSHeuristics), cet attribut est soit traité comme un alias du vrai mot de passe et alors non lisible, soit traité comme un attribut ordinaire. Dans ce second cas, qui est la situation par défaut des forêts récentes, une application qui y écrit un mot de passe le stocke tel quel, lisible par ceux qui ont le droit de lecture. Des connecteurs d'annuaire et d'anciennes applications LDAP le font encore.

Il faut aussi garder en tête d'autres emplacements classiques : les anciennes préférences de stratégie de groupe contenant un mot de passe dans SYSVOL, les scripts d'ouverture de session, ou les attributs de l'ancien LAPS mal protégés.

Trouver les secrets

La recherche se fait avec les outils d'administration habituels. Une requête PowerShell du module Active Directory qui récupère les attributs description, info et comment de tous les utilisateurs et ordinateurs, puis filtre sur des mots-clés (« mdp », « pwd », « pass », « mot de passe », « motdepasse »), suffit à révéler la plupart des cas. Pour userPassword et unixUserPassword, le simple fait qu'ils soient renseignés est un signal : ils ne devraient pas l'être.

Ne vous limitez pas aux comptes actifs : les comptes désactivés sont souvent réactivés, et un mot de passe noté il y a des années peut encore être valide sur un autre compte ou un autre système.

Nettoyer correctement

1. Considérez chaque mot de passe trouvé comme compromis : il a pu être lu par n'importe qui, depuis n'importe quand.
2. Changez-le sur le compte concerné et sur tous les systèmes où il a pu être réutilisé.
3. Videz l'attribut, puis vérifiez que l'application ou le script qui l'y écrivait ne va pas le remettre.
4. Pour les comptes de service, migrez vers des comptes de service administrés de groupe (gMSA) lorsque c'est possible, ce qui supprime le besoin de connaître le mot de passe.
5. Stockez les secrets restants dans un coffre-fort de mots de passe avec des accès tracés.

Et les attributs confidentiels ?

Active Directory permet de marquer un attribut comme confidentiel (indicateur dans searchFlags) : sa lecture exige alors un droit de contrôle d'accès spécifique, que les utilisateurs ordinaires n'ont pas. C'est utile pour des attributs personnalisés contenant des données sensibles. En revanche, les attributs du schéma de base, dont description, ne peuvent pas être rendus confidentiels. La solution n'est donc pas de cacher le mot de passe, mais de ne jamais l'écrire dans l'annuaire.

Ce qu'un audit vérifie

• la présence de mots-clés évoquant des mots de passe dans description, info et comment ;
• les objets dont userPassword ou unixUserPassword est renseigné ;
• la configuration de dSHeuristics relative à userPassword ;
• la présence de mots de passe dans SYSVOL et les scripts de connexion ;
• la rotation effective des mots de passe découverts lors d'un précédent audit.