Accès LDAP anonyme dsHeuristics énumération Active Directory : comment un attribut faible expose tout votre domaine

Accès LDAP anonyme dsHeuristics énumération Active Directory expliqué

Accès LDAP anonyme dsHeuristics énumération Active Directory — si cette expression vous a mené ici, vous soupçonnez déjà ce que cet article confirme : un seul caractère dans un seul attribut réactive silencieusement les opérations LDAP non authentifiées sur toute une forêt Active Directory, et presque rien dans la boîte à outils d'administration standard ne vous signalera que c'est arrivé.

Les contrôleurs de domaine Active Directory acceptent les connexions LDAP non authentifiées dans exactement deux cas précis : la négociation de la liaison elle-même, et l'interrogation de rootDSE (les données de capacité et de configuration propres au serveur). Les recommandations de Microsoft sont explicites sur cette limite : « les opérations LDAP (Lightweight Directory Access Protocol) anonymes vers Active Directory, autres que les recherches et liaisons rootDSE, ne sont pas autorisées » sur les contrôleurs de domaine Windows Server 2003 et versions ultérieures. Tout ce qui va au-delà — parcourir l'arborescence de l'annuaire elle-même, lire des objets utilisateur, groupe ou OU — nécessite un client authentifié.

Ce comportement par défaut est plus récent que ne le pensent la plupart des administrateurs. Les contrôleurs de domaine basés sur Windows 2000 ne prennent pas du tout en charge cette restriction : s'ils sont présents dans une forêt basée sur Windows Server 2003, ils n'appliquent tout simplement pas le blocage des opérations anonymes. Ce comportement de blocage a été introduit avec Windows Server 2003 et dépend du niveau fonctionnel du contrôleur de domaine, pas uniquement de la version du système d'exploitation. Tout contrôleur de domaine fonctionnant en dessous du niveau fonctionnel Windows Server 2003 autorise par défaut les opérations anonymes ; tout contrôleur de domaine à ce niveau ou au-dessus les bloque par défaut.

Le blocage est le comportement par défaut. dsHeuristics est l'unique attribut capable de le désactiver silencieusement — pour toute la forêt, sur chaque contrôleur de domaine, sans la moindre case à cocher dans une interface graphique pour prévenir qui que ce soit.

Comment ça fonctionne — l'attribut dsHeuristics

dsHeuristics est un attribut de type chaîne Unicode stocké sur l'objet CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration sous le domaine racine de la forêt. Chaque position de caractère dans la chaîne correspond à une heuristique indépendante, et l'ordre est fixe — les caractères ne peuvent être omis qu'en tronquant la chaîne depuis la fin. Selon la spécification du protocole [MS-ADTS], par défaut cet attribut n'existe pas du tout, et la valeur par défaut de chaque caractère qu'il pourrait contenir est "0".

Le septième caractère — fLDAPBlockAnonOps

Le septième caractère est fLDAPBlockAnonOps : s'il est positionné à "2", l'heuristique de blocage des opérations anonymes est FALSE, ce qui signifie que les opérations LDAP anonymes sont autorisées. Toute autre valeur — ou l'absence pure et simple de ce caractère — laisse le blocage actif sur les contrôleurs de domaine au niveau fonctionnel Windows Server 2003 ou supérieur.

dSHeuristics: 0000002
              ^      ^
              caractères 1-6 à leur valeur par défaut (0)
                     caractère 7 = 2 -> opérations LDAP anonymes autorisées

Cet attribut n'a aucun panneau dédié dans Utilisateurs et ordinateurs Active Directory, aucun paramètre de stratégie de groupe, et aucune bannière d'avertissement nulle part dans les outils d'administration par défaut. Les seuls moyens de le consulter sont ADSI Edit (adsiedit.msc) ou ldp.exe, connectés au contexte de nommage Configuration. Un environnement peut cocher toutes les cases d'une checklist qui ne regarde que les paramètres GPO et avoir malgré tout l'accès LDAP anonyme grand ouvert, parce que rien dans la boîte à outils standard ne fait remonter cette valeur, sauf si quelqu'un va spécifiquement la chercher.

Le huitième caractère — fAllowAnonNSPI

Une heuristique voisine, souvent négligée, se trouve un caractère plus loin : la position 8, fAllowAnonNSPI, contrôle si des appelants anonymes peuvent utiliser la méthode de liaison RPC NSPI — le protocole derrière le carnet d'adresses Outlook/Exchange. C'est une surface d'accès anonyme distincte, sans rapport direct avec LDAP, mais qui mérite d'être vérifiée dans la même passe puisqu'elle vit dans le même attribut et dans le même angle mort.

Ne pas confondre avec RestrictAnonymous

Il convient également de distinguer ceci d'un contrôle que la plupart des checklists de durcissement couvrent déjà : la valeur de registre RestrictAnonymous et la stratégie de sécurité « Accès réseau : ne pas autoriser l'énumération anonyme des comptes et partages SAM ». Ces paramètres régissent l'énumération anonyme SAM/RPC — un chemin de code entièrement différent. Les équipes qui ont verrouillé RestrictAnonymous et sont passées à autre chose supposent souvent que LDAP est couvert par ce même réglage. Ce n'est pas le cas ; dsHeuristics est le contrôle qui régit réellement LDAP, et il doit être vérifié indépendamment — aux côtés des autres réglages réseau des contrôleurs de domaine couverts dans Audit TLS Faible LDAPS, Spouleur Impression, Synchronisation Horaire du Contrôleur de Domaine : Checklist d'Hygiène Réseau.

Si votre organisation a déjà verrouillé la signature LDAP, notez que la signature et dsHeuristics protègent contre des choses différentes : la signature empêche l'altération et le relais sur une connexion authentifiée ; dsHeuristics détermine si une connexion doit s'authentifier ou non. Corriger l'un ne change rien pour l'autre.

Ce qu'un attaquant en retire

Quand fLDAPBlockAnonOps est désactivé, un client LDAP anonyme peut effectuer toute opération que la liste de contrôle d'accès (ACL) d'un objet autorise pour le principal « Anonymous Logon » / « Everyone » — sans identifiants requis, pas même un compte invité à faibles privilèges. En pratique, ce sont les ACL d'objet par défaut de la plupart des domaines sur les utilisateurs, groupes et unités d'organisation, ce qui suffit à parcourir l'intégralité de l'arborescence : noms d'utilisateur, appartenances aux groupes, structure des OU, et souvent des attributs descriptifs comme les intitulés de poste ou les champs de description en texte libre qui finissent par contenir plus qu'ils ne le devraient.

C'est exactement le profil que les recommandations conjointes de la CISA, de la NSA et de partenaires internationaux sur la détection et l'atténuation des compromissions Active Directory soulignent à répétition : l'énumération non authentifiée de l'annuaire est une étape standard de reconnaissance pré-compromission, parce qu'elle livre à un attaquant la liste des utilisateurs du domaine, les appartenances aux groupes et la structure des OU avant même une seule tentative d'authentification — et avant qu'une seule alerte d'échec de connexion n'ait la moindre raison de se déclencher. Des outils publics conçus spécifiquement pour cela, comme Windapsearch, partent exactement de ce scénario : viser un contrôleur de domaine sans identifiants et voir ce qu'une liaison anonyme révèle, avant même de tenter un seul mot de passe deviné. C'est un vecteur d'exposition non authentifiée parmi d'autres dans Active Directory — voir aussi Transfert de Zone DNS Active Directory Mise à Jour Dynamique Non Sécurisée : Détection et Remédiation pour un chemin d'exposition comparable côté DNS.

Confirmer l'exposition avec un test de liaison direct

Le moyen direct de confirmer l'exposition consiste à l'essayer :

# Pas de -D (bind DN) ni de -w (mot de passe) => liaison simple anonyme
ldapsearch -x -H ldap://dc01.corp.local -b "DC=corp,DC=local" \
  "(objectClass=user)" sAMAccountName

Si cela retourne des objets utilisateur au lieu d'une réponse d'erreur d'opération / de droits d'accès insuffisants, l'accès LDAP anonyme est activé sur ce contrôleur de domaine.

Détection

Lire directement l'attribut est la vérification la plus fiable, car elle ne dépend d'aucune journalisation d'audit activée où que ce soit. Le test de liaison est la deuxième vérification la plus fiable, car il reflète ce qu'un client expérimente réellement plutôt que ce que la configuration prétend. Les signaux issus des journaux d'événements sont complémentaires, pas primaires : ils aident à confirmer que l'exposition a été utilisée, pas seulement qu'elle est présente.

Si la journalisation d'audit de ces catégories n'est pas déjà activée sur vos contrôleurs de domaine, c'est une lacune préalable à combler en priorité — voir Lacunes de configuration de la politique d'audit Active Directory pour les catégories que la plupart des environnements laissent désactivées avant même d'avoir besoin des journaux.

Remédiation

Étape 1 — Lire avant d'écrire

Notez d'abord la chaîne dsHeuristics complète existante — la modifier à l'aveugle risque de faire basculer une heuristique sans rapport dont dépend peut-être une autre application ou un autre processus.

Étape 2 — Corriger le septième (et le huitième) caractère

Positionnez le septième caractère à 0 (ou supprimez-le entièrement s'il s'agit du caractère final) pour rétablir le blocage par défaut des opérations anonymes. Le changement se réplique sur tous les contrôleurs de domaine de la forêt et prend effet sans redémarrage. Pendant que vous y êtes, vérifiez le huitième caractère (fAllowAnonNSPI) et réinitialisez-le, sauf s'il existe une dépendance documentée à un ancien carnet d'adresses Exchange/Outlook qui nécessite réellement des liaisons NSPI anonymes. Ne présumez pas que RestrictAnonymous couvre déjà l'un ou l'autre — c'est un contrôle différent pour un chemin protocolaire différent, donc vérifiez dsHeuristics indépendamment, même dans des environnements qui se considèrent déjà durcis.

Étape 3 — Retester

Relancez le même test de liaison ldapsearch / ldp.exe anonyme utilisé pour la détection. Il devrait maintenant retourner une erreur d'opération ou une réponse de droits d'accès insuffisants, et non des objets de l'annuaire. Si l'accès LDAP anonyme est réellement nécessaire pour une application héritée spécifique, cantonnez-le au niveau réseau (une règle de pare-feu vers la source spécifique) plutôt que de laisser la valeur dsHeuristics ouverte, pour toute la forêt, à n'importe quel client non authentifié.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec lit directement l'attribut dsHeuristics depuis le contexte de nommage Configuration et signale deux contrôles liés : ANONYMOUS_LDAP_ACCESS quand les opérations LDAP anonymes sont confirmées accessibles, et DS_HEURISTICS_LDAP_SECURITY quand l'attribut lui-même est positionné à une valeur qui affaiblit la sécurité LDAP — de sorte que la mauvaise configuration est détectée à la source plutôt qu'après coup, une fois que du trafic d'énumération apparaît dans les journaux. Pour une couverture plus large des réglages que la plupart des environnements devraient vérifier en premier, voir Durcissement Active Directory : quoi verrouiller d'abord et comment le valider et Quelles sont les mauvaises configurations de sécurité Active Directory les plus courantes ?