Top 10 des erreurs de configuration Active Directory à corriger en premier

Pourquoi cette liste ne ressemble pas à celle du cloud

Sur un tenant, le risque est que quelqu'un se connecte en se faisant passer pour un autre. Sur un annuaire, le risque est que quelqu'un déjà connecté comme utilisateur parfaitement ordinaire trouve une chaîne de droits qui aboutit à un contrôleur de domaine. D'où une liste qui parle de chemins plutôt que de réglages : prises isolément, la plupart de ces situations se défendent ; ensemble, elles font une route.

1. Un droit détenu par « Utilisateurs du domaine » sur un objet privilégié

Le pire constat qu'un audit puisse remonter. Un droit GenericAll, WriteDACL ou WriteOwner sur un groupe privilégié, détenu par un principal auquel tous les comptes du domaine appartiennent, signifie que chaque utilisateur est à une commande de l'administration du domaine. Ce n'est presque jamais délibéré : c'est le résidu d'une migration ou d'un outil qui a demandé le « contrôle total » une fois.

Correction : retirer l'ACE. Puis chercher ses voisines — ce genre de droit apparaît rarement seul.

2. Des comptes de service dans les groupes d'administration

Un compte de service dans les administrateurs du domaine, c'est un identifiant privilégié permanent, généralement avec un mot de passe inchangé depuis des années, souvent porteur d'un nom principal de service — ce qui le rend kerberoastable : n'importe quel utilisateur peut demander un ticket pour lui et casser le mot de passe hors ligne, tranquillement, sans déclencher la moindre tentative de connexion en échec.

Correction : sortir les comptes de service des groupes d'administration, utiliser des comptes de service gérés de groupe quand c'est possible, et traiter tout compte à SPN restant comme un identifiant à renouveler.

3. Des droits de réplication hors des contrôleurs de domaine

Les deux droits de réplication qui, ensemble, permettent le DCSync autorisent leur détenteur à demander à un contrôleur de domaine les empreintes de mots de passe de tout le domaine, krbtgt compris — c'est-à-dire la clé d'un Golden Ticket, donc d'une persistance qui survivra à toutes les réinitialisations de mots de passe que vous ferez ensuite.

Correction : les seuls principaux qui ont besoin de ces droits sont les contrôleurs de domaine eux-mêmes. Tout le reste est un constat.

4. La délégation non contrainte

Une machine autorisée à la délégation non contrainte met en cache les tickets de tous ceux qui s'y connectent. Compromettez ce serveur, attendez qu'un administrateur s'y connecte, et vous avez son ticket. C'est une conception d'une autre époque, qui tourne pourtant en production bien plus souvent qu'on ne l'imagine.

Correction : passer à la délégation contrainte, et marquer les comptes privilégiés comme sensibles pour qu'ils ne puissent pas être délégués du tout.

5. Des modèles de certificat permissifs (AD CS)

Un modèle qui laisse le demandeur fournir son propre nom de sujet, publié à un groupe large, permet à n'importe quel utilisateur de demander un certificat au nom d'un administrateur du domaine, puis de s'authentifier comme lui. La famille de techniques ESC a transformé une PKI discrète et vieille de dix ans en l'un des chemins d'escalade les plus fiables qui soient.

Correction : revoir qui peut s'inscrire sur chaque modèle, désactiver l'option de nom fourni dans la requête là où elle n'est pas nécessaire, et exiger l'approbation d'un gestionnaire sur les modèles sensibles.

6. AdminSDHolder et les groupes protégés

Les droits posés sur AdminSDHolder se propagent à tous les comptes protégés, par minuterie, silencieusement. Un attaquant qui obtient un accès en écriture à cet objet n'a plus besoin de conserver son point d'appui : l'annuaire lui-même rétablira son accès chaque heure.

Correction : auditer son ACL spécifiquement, et traiter toute entrée non standard comme un indice de compromission plutôt que comme une erreur de configuration.

7. Des approbations sans filtrage des identifiants de sécurité

Une approbation entrante depuis une forêt que vous n'administrez pas, sans filtrage SID, permet à l'autre côté d'affirmer des identifiants privilégiés de votre domaine. La compromission d'un partenaire devient la vôtre. Ajoutez une délégation TGT sur l'approbation et le problème cesse d'être théorique.

Correction : activer le filtrage des identifiants de sécurité et l'authentification sélective, et relire la liste des approbations — il y en a généralement une plus ancienne que tout le monde dans la pièce.

8. LAPS déployé « presque partout »

La couverture de LAPS est un pourcentage, et les machines qui manquent sont rarement aléatoires : ce sont les anciennes, celles auxquelles personne n'ose toucher. Un mot de passe d'administrateur local partagé entre ces machines offre le déplacement latéral gratuitement.

Correction : mesurer la couverture au lieu de la supposer, et traiter les machines non couvertes comme une liste à solder, pas comme un reliquat acceptable.

9. Des mots de passe qui n'expirent jamais sur des comptes privilégiés

Comptes de secours, comptes applicatifs, le compte créé pour un projet en 2016. Chacun est un identifiant exposé depuis des années à tous les enregistreurs de frappe, à toutes les sauvegardes fuitées et à tous les administrateurs partis.

Correction : les inventorier, justifier par écrit chaque survivant, renouveler le reste, et surveiller l'usage de ceux que vous gardez.

10. Des protocoles hérités encore actifs sur les contrôleurs

SMBv1, la résolution de noms LLMNR et NetBIOS, le LDAP non signé : la plomberie qui fait fonctionner les attaques par relais et par empoisonnement. Aucun n'est exploité seul — ce sont eux qui transforment un point d'appui en identifiant.

Correction : les désactiver, dans cet ordre, après avoir mesuré ce qui en dépend encore.