Bonjour à tous,
Je vous propose un petit article sur un cas que j'ai rencontré récemment.
Imaginez : Vous avez mis en place des Fine-Grained Password Policies (FGPP) pour vos comptes d'administration et vos comptes de service. Les FGPP sont bien configurées et appliquées, tout va bien dans le meilleur des mondes. Puis vous décidez de faire un audit sur vos comptes Active Directory, et là, vous vous apercevez que certains comptes de service et d'administration ont un mot de passe qui n'expire jamais ... Ils ne respectent donc pas la politique de mot de passe que vous avez définie avec vos FGPP.
Nous allons donc voir pourquoi il est possible d'outrepasser la politique de mot de passe que vous avez définie via vos FGPP et comment éviter ce type de transgression.
On va commencer par parler tout d'abord des droits étendus.
Extended Rights
La délégation d'administration Active Directory consiste à donner à un utilisateur ou un groupe de sécurité des accès en lecture ou en écriture à un objet ou à une propriété de cet objet.
Par exemple, vous pouvez donner à un groupe le droit de modifier le numéro de téléphone d'une population d'utilisateur sans pour autant lui donner le droit de modifier d'autres attributs de ces comptes.
Il existe d'autres droits, appelés droits étendus, qui consistent en l'exécution de tâches spécifiques, telles que changer le mot de passe d'un utilisateur.
Ces droits étendus sont visibles dans le conteneur "Extended Rights" de la partition de Configuration.
Si vous voulez plus de détails sur les droits étendus vous pouvez consulter le lien suivant : Extended Rights Reference
Pour notre problématique, nous allons nous intéresser aux 3 droits étendus suivant :
Le droit Enable-Per-User-Reversibly-Encrypted-Password permet d'activer ou de désactiver le "Stockage les mots de passe en utilisant un chiffrement réversible" pour les objets utilisateur et ordinateur.
Le droit Unexpire-Password permet de restaurer un mot de passe expiré pour les objets utilisateur. Il permet aussi de configurer un mot de passe qui n'expire jamais.
Le droit Update-Password-Not-Required-Bit permet d'activer ou de désactiver le "mot de passe n'est pas nécessaire" pour les objets utilisateur. Ce droit permet d'utiliser un mot de passe vide.
Lorsque vous configurez ces paramètres pour un compte utilisateur, vous modifiez certains flags de l'attribut UserAccountControl.
Si vous voulez plus d'informations sur les différentes valeurs que peut prendre l'attribut UserAccountControl : How to use the UserAccountControl flags to manipulate user account properties
Ces droits étendus sont configurés à la racine du domaine. Il faut savoir que par défaut ces droits sont autorisés pour le groupe 'Utilisateurs Authentifiés" mais qu'il faut bien évidemment les droits de modification de l'attribut UserAccountControl pour les configurer.
On va voir maintenant comment on peut interdire ce genre de modifications.
Démonstration
J'ai un domaine avec la politique de mot de passe par défaut et utilisateur standard (test-user-001).
Cet utilisateur a les propriétés AllowReversiblePasswordEncryption, PasswordNeverExpires et PasswordNotRequired à la valeur "False"
Un utilisateur qui a les droits de modification de l'attribut UserAccountControl sur le compte de cet utilisateur peut modifier ces paramètres et donc transgresser la politique de mot de passe définie pour cet utilisateur.
Avec la propriété PasswordNotRequire configurée à la valeur "True", on peut désormais renseigner un mot de passe vide pour le compte. On a donc complètement outrepasser la politique de mot de passe ...
On va maintenant interdire la possibilité de faire ces modifications.
Pour cela, j'ai créé 3 groupes de sécurité (un pour chaque droit étendu, on aurait pu aussi créer un seul groupe, tout dépend de ce que vous souhaitez faire). On positionne ensuite les permissions en Deny pour ces groupes au niveau du domaine.
Désormais, les membres de ces groupes ne peuvent plus modifier les 3 flags de l'attribut UserAccountControl.
On reprend notre utilisateur de test.
On prend un compte d'administrateur (Admin001) qui a les droits de modification sur les comptes utilisateurs (et qui peut donc outrepasser la politique de mot de passe) et on l'ajoute au 3 groupes que l'on a créés précédemment.
On va maintenant modifier un des flags de l'attribut UserAccountControl de l'utilisateur en le désactivant. Notre administrateur a donc bien les droits de modification sur l'attribut.
On essaie maintenant de modifier nos 3 paramètres.
Notre administrateur ne peut plus modifier ces flags de l'attribut UserAccountControl.
Je ne vais pas aller plus loin dans la démonstration je pense que vous avez compris le concept.
La stratégie à adopter concernant ces 3 droits étendus dépend de la stratégie de mot de passe que vous avez définie et si vous voulez la verrouiller complètement.
Attention toutefois si vous utilisez des comptes configurés avec le paramètre PasswordNeverExpires (compte de service par exemple, même si ce n'est pas une bonne pratique), vous ne pourrez plus configurer ce paramètre.
Vous pouvez commencer par vérifier si vous avez des comptes avec ces flags configurés dans vos environnements.
On peut utiliser des commandes Powershell avec le filtre LDAP suivant en remplaçant XXX par la valeur décimale du flag (voir : How to use the UserAccountControl flags to manipulate user account properties) :
(&(objectCategory=person)(userAccountControl:1.2.840.113556.1.4.803:=XXX))
J'espère que cet article vous a intéressé et que vous avez appris quelque chose.
Merci de m'avoir lu et à très bientôt.
