Il n'a jamais été facile de sécuriser correctement votre Active Directory (AD). Il en va de même pour l'octroi de droits de modification dans l'AD. Après tout, vous ne voulez pas que vos comptes d'administration les plus privilégiés (par exemple, les administrateurs de domaine) effectuent des opérations quotidiennes sur l'annuaire, mais le fait d'accorder trop de privilèges menace votre position en matière de sécurité AD. C'est là qu'intervient la délégation des autorisations aux objets AD.
La granularité des autorisations dans Active Directory est puissante, mais peut s'avérer écrasante. Au fil des ans, Microsoft a ajouté quelques options et droits pour permettre aux administrateurs d'accorder des capacités à un niveau plus granulaire. Toutefois, les efforts déployés pour assurer la rétrocompatibilité avec les autorisations déléguées existantes ont également rendu la sécurisation de votre AD encore plus délicate. J'ai déjà écrit sur certaines des conséquences potentielles pour la sécurité de l'AD. Malheureusement, ces problèmes subsistent dans la version la plus récente du système d'exploitation, Windows Server 2025.
Voici comment vous pouvez utiliser les options de mot de passe Windows avec la gestion par délégation pour soutenir votre structure de gestion des utilisateurs sans sacrifier la sécurité de votre Active Directory.
Délégation de la gestion des utilisateurs et principe du moindre privilège
Lors de la conception d'un modèle de délégation AD, les administrateurs doivent soigneusement différencier qui peut voir ou faire quoi dans quelle partie de l'annuaire. Les administrateurs délégués ne doivent se voir accorder que le minimum de privilèges dont ils ont besoin pour effectuer les tâches administratives qui leur incombent, ni plus ni moins.
Par exemple, supposons que le rôle d'un opérateur du service d'assistance consiste à réinitialiser les mots de passe des utilisateurs. Les opérateurs n'ont pas besoin du contrôle total de l'unité d'organisation (OU) contenant tous les comptes d'utilisateurs. Cela permettrait aux opérateurs du service d'assistance d'apporter de nombreuses autres modifications aux comptes d'utilisateurs et à d'autres objets de cette unité d'organisation. Même si vous souhaitez accorder aux opérateurs régionaux des autorisations allant jusqu'au contrôle total pourgérer davantage d'aspects liés aux utilisateurs, vous souhaitez qu'ils respectent vos règles de sécurité générales, en particulier en ce qui concerne les différentes options de mot de passe pour les utilisateurs qu'ils gèrent.
Gestion des options de mot de passe vs politique de mot de passe
Le modèle de permissions original que Microsoft a publié avec Windows Server 2000 était remarquablement complet et permettait aux administrateurs d'accorder des capacités jusqu'à l'attribut d'un objet (par opposition à l'objet lui-même). Cependant, les limitations concernant la définition d'options de mot de passe spécifiques risquaient d'entrer en conflit avec la politique de l'entreprise en matière de mot de passe.
Le problème de la version originale d'AD est qu'elle ne pouvait pas faire la distinction entre les options suivantes de gestion des mots de passe sensibles à la sécurité(figure 1) :
- Stocker le mot de passe à l'aide d'un cryptage réversible
- Le mot de passe n'expire jamais
- Mot de passe non requis Bit
Le bit Password Not Required n'est pas disponible dans les interfaces utilisateur natives de Windows. Mais il peut être activé par programme, par exemple via PowerShell :
Get-ADUser -Identity Bob | Set-ADUser -PasswordNotRequired $true
Ces options, lorsqu'elles sont utilisées, peuvent facilement saper la politique de mot de passe de votre entreprise et la mettre en danger. Les options n'ont pas leur propre attribut où elles sont stockées, mais font partie de l'attributuserAccountControl d'un utilisateur dans AD. Cet attribut est un ensemble de paramètres divers qui contrôlent de nombreux aspects d'un compte d'utilisateur en plaçant un interrupteur binaire dans la bonne position.
Malheureusement, toute autorisation déléguée qui accorde à un opérateur le contrôle total sur les utilisateurs d'une OU - ou même simplement le droit d'écrire des restrictions de compte sur ces objets utilisateur - permet également à l'opérateur de définir ces options de mot de passe sensibles sur tous les comptes qu'il contrôle.
Permettre aux administrateurs délégués de choisir ces options de mot de passe pour les comptes qu'ils gèrent conduit souvent à des résultats désagréables. Par exemple, les administrateurs délégués qui ne sont pas sensibilisés à la sécurité peuvent configurer un pourcentage élevé de leurs utilisateurs avec l'option Mot de passe n'expirant jamais, simplement pour éviter les problèmes lorsque les utilisateurs changent leurs mots de passe. Naturellement, une telle pratique sape toute politique d'ancienneté des mots de passe définie au niveau du domaine ... même celles définies pour les groupes par le biais de politiques de mot de passe à grain fin.
Le problème des utilisateurs authentifiés
Microsoft n'a pas tardé à lutter contre ce problème. Avec la sortie de Windows Server 2003, Microsoft a introduit trois nouveaux droits d'accès au contrôle, également appelés droits étendus:
- Activer le cryptage réversible du mot de passe par utilisateur
- Expiration du mot de passe (qui permet d'activer l'indicateur " Le mot de passe n'expire jamais" )
- Mise à jour du mot de passe non requise Bit
Contrairement aux droits étendus tels que Reset-Password, qui doivent être définis directement pour les objets utilisateurs, ces trois droits étendus ont été mis en œuvre pour s'appliquer au niveau du domaine. Avec ces droits, seuls les opérateurs ayant obtenu le contrôle total ou des restrictions d'écriture sur un ensemble d'utilisateurs (par exemple, dans une OU) en combinaison avec l'une de ces autorisations de mot de passe spéciales sur la racine du domaine pouvaient effectivement définir ces options de mot de passe sensibles sur les comptes qu'ils contrôlaient.
Toutefois, Microsoft étant Microsoft, la nécessité d'assurer la rétrocompatibilité avec les autorisations déléguées existantes et de faire en sorte que "les choses fonctionnent comme avant" a eu la priorité sur le fait d'encourager les clients à améliorer la sécurité AD dans leurs modèles de délégation.
Pour résoudre ce dilemme, Microsoft a choisi d'accorder au groupe des utilisateurs authentifiés ces droits à la racine du domaine lors de la mise à niveau de Windows Server 2003 des domaines et forêts AD existants. Malheureusement, il a également défini ces droits pour tout nouveau domaine AD déployé.
Cela vous semble-t-il familier ? Oui, les utilisateurs authentifiés apparaissent un peu partout... et pas toujours en votre faveur(Figure 2).
C'est le statu quo depuis la mise à jour de Windows Server 2003 ... et c'est toujours le cas dans les nouveaux déploiements AD basés sur Windows Server 2022 et même Windows Server 2025. Cela signifie que vous trouverez très certainement ces autorisations par défaut toujours actives dans votre déploiement AD et qu'elles vous empêcheront probablement de renforcer la sécurité des mots de passe dans votre Active Directory.
Comment améliorer la sécurité des mots de passe AD
Alors, comment pouvez-vous améliorer la sécurité de votre mot de passe AD ? Tout d'abord, vous devez supprimer l'autorisation par défaut des utilisateurs authentifiés pour ces trois droits étendus à la racine de vos domaines. Ensuite, vous devrez choisir des remplaçants appropriés - si vous décidez de déléguer ces autorisations. N'oubliez pas : Ces trois droits étendus doivent être définis au niveau du domaine. Les accorder au niveau de l'OU n'a aucun effet.
Ma recommandation :
- Créez un groupe distinct pour chacun de ces droits étendus sensibles.
- Accordez à chaque groupe l'autorisation correspondante à la racine du domaine. Ces groupes appartiennent à votre OU de niveau 0, où seuls les administrateurs de domaine peuvent apporter des modifications.
- Dans une forêt multidomaine, créez les groupes en tant que groupes universels dans votre domaine racine. De cette façon, vous pouvez ajouter des utilisateurs sélectionnés de chaque domaine aux groupes, qui seront alors en mesure d'accorder les autorisations respectives dans n'importe quel domaine.
Par exemple, vous pouvez créer les trois groupes suivants :
- SVC-ADconfig-PerUserReversiblyEncryptedPwd (mot de passe de l'utilisateur)
- SVC-ADconfig-UnexpirePassword
- SVC-ADconfig-PwdNotRequiredBit (bit)
Ensuite, remplacez les droits étendus accordés aux utilisateurs authentifiés par chaque groupe correspondant(Figure 3).
Supposons maintenant que vous souhaitiez qu'un opérateur, Fred, ait le droit de gérer un utilisateur. Vous pouvez toujours accorder à Fred le contrôle total ou l'écriture des restrictions de compte pour tous les utilisateurs de l'OU dont il est responsable. Mais Fred ne pourra pas définir l'une des trois options de mot de passe sensible sur ces comptes d'utilisateur.
Maintenant, si vous ajoutez Fred au groupe SVC-ADconfig-UnexpirePassword, il pourra définir l'option Mot de passe n'expirant jamais pour les utilisateurs qu'il gère. Il est probablement préférable de ne pas donner cette option à Fred, mais vous pourriez le faire si le besoin s'en faisait sentir.
Si tout va bien, vous disposez déjà de plans de test et d'une liste de personnes chargées de valider les applications, les outils et les processus de gestion des utilisateurs et des clients les plus critiques, ainsi que d'un processus de collecte de commentaires après avoir effectué ces changements de permissions. Bien entendu, avant d'effectuer de tels changements dans votre environnement AD de production, vous devez enregistrer les autorisations actuelles et tester vos nouveaux paramètres avant de déployer les changements.
Idéalement, vous disposez d'une solution qui enregistre toutes les modifications dans votre Active Directory, y compris l'attribut nTsecurityDescriptor, qui stocke essentiellement l'autorisation de l'objet concerné. Il serait encore mieux de disposer d'une solution capable d'annuler ces modifications dans l'Active Directory.
Oui, je vous le dis franchement : Semperis Directory Service Protector (DSP) peut faire ces deux choses. Il existe également des scripts accessibles au public que vous pouvez utiliser avec vos propres captures d'écran pour documenter votre travail.
Principaux enseignements concernant les options de mots de passe sensibles dans Windows Server 2025 et versions antérieures
Active Directory est plein de surprises en matière de sécurité. Pour identifier les failles de sécurité potentielles dans votre environnement, téléchargez Purple Knightun outil gratuit d'évaluation de la sécurité d'Active Directory qui identifie plus de 150 indicateurs d'exposition et de compromission et fournit des conseils sur la manière d'y remédier.
Sachez toutefois que l'adoption de Windows Server 2025 ne signifie pas nécessairement que vous abandonnez les paramètres hérités problématiques. Pensez notamment à modifier les paramètres de configuration relatifs à la délégation des options de mot de passe sensibles.
- Si vous avez délégué l'administration des objets utilisateur à des personnes qui ne sont pas des administrateurs de domaine, déterminez si ces personnes ont besoin de pouvoir définir des options sensibles telles que le mot de passe n'expire jamais pour les comptes utilisateur qu'elles gèrent.
- Remplacez les autorisations par défaut pour les utilisateurs authentifiés à la racine du domaine pour les trois droits étendus discutés dans cet article par des groupes que seuls les administrateurs de domaine peuvent gérer.
- Ajoutez sélectivement des administrateurs délégués aux groupes nouvellement créés, mais uniquement s'il est réellement nécessaire qu'ils gèrent l'une de ces options de mot de passe sensibles.
Ces changements présentent peu de risques et de grands avantages pour la sécurité de l'Active Directory et la gestion efficace des délégations.
Besoin d'aide avec AD Security ?
Profitez de l'expertise de Semperis. Demandez un examen de la configuration de la sécurité et notre équipe utilisera des outils automatisés et des méthodes manuelles pour trouver les mauvaises configurations et les voies d'attaque qu'un pirate pourrait utiliser pour compromettre votre environnement.
Pour en savoir plus
