Groupe Pre-Windows 2000 Compatible Access Active Directory

Qu’est-ce que le groupe Pre-Windows 2000 Compatible Access ?

Le groupe Pre-Windows 2000 Compatible Access dans Active Directory peut accorder un accès étendu en lecture à l’annuaire, mais les attributs qu’un appelant peut lire dépendent des ACE de l’objet. « Lecture à l’échelle de l’annuaire » ne signifie pas que tous les secrets sont lisibles, et l’appartenance au groupe ne garantit pas l’énumération LDAP anonyme. Microsoft documente à la fois les contrôles d’accès aux objets et une restriction LDAP distincte. Conditions d’accès des fonctions de gestion réseau, restrictions LDAP anonymes.

Pre-Windows 2000 Compatible Access est le groupe de sécurité intégré identifié par S-1-5-32-554, situé sous CN=Builtin dans le domaine. Microsoft le décrit comme un mécanisme de compatibilité pour les clients Windows NT 4.0 et antérieurs, donnant accès en lecture aux informations sur les utilisateurs et les groupes. Il n’est pas protégé par AdminSDHolder, et le tableau des groupes de Microsoft indique qu’il ne peut pas être déplacé hors de son conteneur par défaut. Examinez ses membres plutôt que de supprimer ou de déplacer le groupe. Groupes de sécurité Active Directory.

Une investigation utile répond à quatre questions : quels principaux sont membres, quelles autorisations ils reçoivent, quelle interface accepte leurs requêtes et quelles applications ont encore besoin de ces lectures. Consignez ces réponses séparément dans le dossier de changement. Le nombre de membres fournit un premier indice ; il ne répond pas aux trois autres questions.

Définissez les critères de réussite de la revue avant de modifier les accès. Pour un chemin anonyme inutile, le résultat attendu est une réduction documentée de ce chemin, tandis que les fonctions authentifiées nécessaires continuent de fonctionner. Pour un compte de service, il peut s’agir de remplacer des autorisations de compatibilité étendues par un accès vérifié aux attributs qu’il demande réellement. Pour une dépendance non résolue, le résultat peut être une exception avec un responsable désigné et un plan de test. Ce sont des résultats opérationnels proposés, pas des observations sur votre domaine ni une affirmation selon laquelle toute appartenance serait exploitable.

L’appartenance initiale dépend de la création du domaine

La spécification du protocole lie l’appartenance initiale au système d’exploitation du premier contrôleur de domaine et au mode d’autorisations choisi par l’administrateur. Elle documente les cas suivants. MS-ADTS 6.1.1.4.12.14.

Dire « Everyone est toujours le membre par défaut » efface cette distinction. Les recommandations Microsoft sur l’accès des applications expliquent aussi que l’ajout d’un DC Windows Server 2003 à un domaine Windows 2000 existant ne modifie pas le choix de compatibilité antérieur. Un domaine mis à niveau peut donc conserver un ancien choix. KB331951 : applications et informations d’autorisation.

Utilisez cet historique pour interpréter un état de référence, pas pour approuver chaque membre actuel. Un membre par défaut historique peut ne plus répondre à un besoin métier, tandis qu’un ajout ultérieur peut servir une application. La liste actuelle ne permet pas de savoir qui a ajouté une entrée ni pourquoi. Consignez « origine inconnue » lorsque les dossiers de déploiement et les journaux de changement conservés ne répondent pas à cette question.

Fonctionnement : appartenance, ACE et contrôles de protocole

Everyone seul n’est pas Anonymous

Les conditions NetAPI de Microsoft exigent explicitement l’appartenance d’Anonymous pour accéder anonymement aux informations de groupe : le jeton anonyme normal n’inclut pas le SID Everyone. Le comportement de Windows 2000 et la dérogation EveryoneIncludesAnonymous=1 sont des exceptions documentées sur la même page. Sur un système moderne utilisant le comportement normal des jetons, Everyone seul n’équivaut pas à Anonymous Logon. L’appartenance explicite d’Anonymous fournit un chemin d’autorisation, sous réserve des autres restrictions de l’interface. Conditions d’accès des fonctions de gestion réseau.

L’accès en lecture et l’énumération ont leurs propres conditions. NetQueryDisplayInformation renvoie les informations que l’appelant peut lire ; la fonction exige List Contents sur l’objet Domain et Enumerate Entire SAM Domain sur l’objet SAM Server du conteneur System. C’est un chemin d’autorisation concret à examiner, pas une garantie que tout client réseau puisse lister tous les objets. NetQueryDisplayInformation.

LDAP possède un contrôle distinct

Windows Server 2003 a introduit un blocage par défaut des opérations LDAP anonymes au-delà des liaisons et des recherches rootDSE. Le septième caractère de dsHeuristics, défini sur 2, lève ce blocage ; les opérations nécessitent toujours les autorisations ACL. Ajouter Anonymous à ce groupe ne modifie pas cet attribut. Inversement, vérifier le contrôle LDAP ne démontre pas qu’une autre interface d’énumération est sûre. KB326690 : opérations LDAP anonymes.

Pour ce mécanisme distinct, consultez l’accès LDAP anonyme et le contrôle dsHeuristics. Cet article porte sur le paramètre LDAP et la vérification des liaisons et recherches. Ici, le sujet est le chemin d’autorisation du groupe de compatibilité. Utilisez l’article lié pour examiner ce contrôle, tout en validant les décisions techniques à partir de la documentation Microsoft.

Origine des autorisations de lecture héritées

Le descripteur de sécurité par défaut de Domain-DNS publié contient des autorisations pour RU. La référence Microsoft des chaînes SID définit RU comme l’alias de Pre-Windows 2000 Compatible Access. Cet extrait provient de la section Windows 2000 Server de la page. Il montre des autorisations à la racine et transmissibles par héritage ; comparez la version pertinente et la DACL réelle de votre domaine avant de vous y fier. Classe Domain-DNS, chaînes SID.

(A;CI;LC;;;RU)
(A;;RC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)

En SDDL, A et OA sont des formes d’ACE d’autorisation ; CI indique l’héritage des conteneurs et IO l’héritage uniquement. RP signifie Read Property, LC List Children, LO List Object et RC Read Control. Le masque de droits et les indicateurs d’héritage sont des champs distincts : une entrée héritée propre à un type d’objet ne doit donc pas être interprétée comme une autorisation sans restriction sur la racine elle-même. Chaînes ACE.

Les deux GUID de classes héritées identifient User et Group. Computer est une sous-classe de User : incluez les ordinateurs dans la revue, sans inventer une ACE visant séparément Computer dans cet extrait. Les références des classes publient des descripteurs par défaut versionnés ; l’ancienne entrée User ne prouve pas que tous les utilisateurs actuels possèdent une DACL identique. Classe User, classe Group, classe Computer.

Le descripteur Domain-DNS complet inclut aussi des ACE de lecture de jeux de propriétés User. La référence Sam-Server montre séparément une entrée RU avec RPLCLORC. Ces valeurs par défaut expliquent les chemins à mesurer ; elles ne remplacent pas l’examen de l’héritage, des entrées explicites et des objets protégés d’un domaine réel. Descripteur Domain-DNS, classe Sam-Server.

Mesurer le groupe réel et les autorisations de lecture

Les exemples ci-dessous adaptent les paramètres documentés des cmdlets et la syntaxe de dsacls. Ils n’ont pas été exécutés sur un domaine. Remplacez le serveur et les noms distinctifs fictifs par des valeurs résolues dans votre environnement. Exécutez-les depuis un poste d’administration approprié, doté des outils et des autorisations de lecture nécessaires. Conservez séparément la sortie et les erreurs de chaque commande, afin qu’une recherche infructueuse ne puisse pas passer pour un résultat sans anomalie.

Étape 1 : capturer les membres directs

Commencez par le nom anglais connu lorsqu’il existe. Cet exemple adapte les paramètres Identity et Server documentés de la cmdlet d’appartenance. Get-ADGroupMember.

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" -Server "dc01.contoso.com"

Identifiez ensuite le groupe intégré par son SID stable et demandez la propriété brute member. L’exemple Microsoft de Get-ADGroup utilise ce modèle avec un autre SID intégré ; cette adaptation lui substitue le SID 554. Get-ADGroup.

Get-ADGroup -Identity "S-1-5-32-554" -Properties member -Server "dc01.contoso.com"

Utilisez aussi cette identité pour la vue de l’appartenance directe. La cmdlet accepte un SID comme Identity. Options d’identité de Get-ADGroupMember.

Get-ADGroupMember -Identity "S-1-5-32-554" -Server "dc01.contoso.com"

Comparez les membres résolus aux références brutes, en particulier lorsque la résolution d’identités spéciales ou de principaux de sécurité étrangers échoue. Consignez le DN et le SID du groupe, le DC contacté et l’identité de chaque membre. Une erreur de résolution ne signifie pas que le groupe est vide. Examinez l’objet référencé avant de tirer une conclusion ou de préparer un retrait.

Conservez cette vue directe pour la comparer au nombre de membres du collector. -Recursive répond à une autre question : la cmdlet parcourt la hiérarchie du groupe pour renvoyer les membres sans objets enfants. Une revue récursive consignée séparément peut aider à examiner les principaux imbriqués, mais elle ne doit pas remplacer silencieusement l’état de référence direct. Comportement récursif de Get-ADGroupMember.

Dans le dossier de preuves proposé, distinguez explicitement la recherche réussie, la recherche échouée et la référence non résolue. Conservez les valeurs brutes d’origine à côté de vos annotations. La comparaison ultérieure pourra ainsi être examinée : la disparition d’un nom d’affichage peut provenir d’une différence de résolution, tandis qu’une valeur brute d’appartenance modifiée mérite une investigation. Évitez de ne conserver qu’un rapport mis en forme par commodité, surtout lorsqu’un autre relecteur devra reproduire la décision.

Étape 2 : examiner la racine et des descendants représentatifs

Avec le DN d’un objet et sans option de modification, dsacls affiche les ACE de l’objet. L’outil peut aussi modifier les autorisations : conservez donc la forme en lecture seule présentée ici. La référence Microsoft exige une invite de commandes avec élévation et l’autorisation Read sur l’objet cible. Ces quatre commandes sont des adaptations utilisant des objets fictifs. Référence Dsacls.

dsacls "DC=contoso,DC=com"

dsacls "CN=Alice,OU=Users,DC=contoso,DC=com"

dsacls "CN=AppReaders,OU=Groups,DC=contoso,DC=com"

dsacls "CN=PC01,OU=Computers,DC=contoso,DC=com"

Pour chaque échantillon, consignez le bénéficiaire, le type d’autorisation ou de refus, les droits, l’héritage, le périmètre de classe et celui des jeux de propriétés. Identifiez les entrées du SID 554 même lorsque le nom affiché est localisé. Incluez les objets utilisés par les applications examinées et des exemples aux paramètres d’héritage différents. Un seul objet utilisateur ordinaire est un échantillon, pas un résultat d’accès effectif à l’échelle du domaine.

Cette distinction compte pour la réécriture des mots de passe : Microsoft documente les autorisations nécessaires à la racine et les autorisations héritées des descendants, puis demande aux administrateurs d’examiner les autorisations effectives du compte connecteur. Lire une DACL et tester l’opération d’un appelant répondent à deux questions différentes. Utilisez les deux pour valider une dépendance. Autorisations de réécriture des mots de passe.

Étape 3 : construire un dossier de dépendances

Pour chaque principal conservé, proposez une fiche contenant son responsable, l’application et sa version, l’identité appelante, les attributs demandés, le protocole, les objets cibles et le test fonctionnel. Incluez l’échec qui justifierait un retour arrière. Un nom de compte évoquant un produit est une piste d’investigation, pas la preuve d’une action de son installateur.

Cette revue diffère aussi de celle sur Everyone et Authenticated Users dans les groupes AD privilégiés. Cet article examine les identités larges placées directement dans des groupes privilégiés et l’appartenance privilégiée permanente. Ici, le rôle documenté du groupe est l’autorisation de lecture pour la compatibilité ; ne transformez pas son nombre de membres en affirmation d’appartenance administrative directe.

Détection : établir l’état et surveiller les changements d’appartenance

Combinez l’inventaire fondé sur les SID avec une trace des changements. La documentation des événements de sécurité Microsoft place 4732 et 4733 dans Audit Security Group Management, avec un événement par membre ajouté ou retiré. Ils peuvent être générés sur les contrôleurs de domaine, les serveurs membres et les postes de travail ; sélectionnez les événements des DC pertinents pour le groupe du domaine. Événement 4732, événement 4733.

Une règle de surveillance proposée devrait faire correspondre TargetSid à S-1-5-32-554, conserver MemberSid et les champs du sujet, puis comparer les changements aux travaux approuvés. La correspondance des SID évite de dépendre d’un nom de groupe traduit. Testez la correspondance des champs dans votre chaîne de collecte avant de considérer la règle comme une couverture effective. Les noms des champs proviennent des exemples XML des événements ; cette règle est une proposition opérationnelle, pas une détection SIEM déployée. Champs de l’événement 4732.

Ces événements consignent les changements d’appartenance. Ils ne montrent pas quels attributs ont été lus, ne découvrent pas toutes les dépendances applicatives et ne confirment pas une énumération anonyme réussie. L’absence d’événements ne permet pas de conclure sans stratégie d’audit, collecte et rétention fonctionnelles. Associez les journaux à l’état sauvegardé et aux tests fonctionnels autorisés, plutôt que de considérer l’un ou l’autre comme une évaluation complète des accès.

Remédiation : retirer les accès inutiles par étapes (Remediation)

Il s’agit d’un processus de changement proposé à partir des mécanismes documentés, pas d’une instruction universelle de Microsoft demandant de vider le groupe. Conservez l’état antérieur, testez les dépendances et modifiez les membres sélectionnés. L’appartenance concerne un groupe du domaine : parler de « pilote sur une OU » ne limite pas l’effet du retrait d’un membre à une seule OU.

Étape 1 : distinguer les valeurs historiques par défaut de la dérive ultérieure

Utilisez l’inventaire par SID et les valeurs brutes de member ci-dessus. Comparez-les aux dossiers disponibles de création et de mise à niveau, puis classez les entrées en valeurs par défaut expliquées, ajouts applicatifs documentés ou appartenances inexpliquées. Soumettez chaque catégorie à la même revue du besoin actuel. Le tableau d’appartenance initiale explique l’origine ; il ne dispense pas de cette revue. Spécification MS-ADTS de l’appartenance.

Étape 2 : résoudre les dépendances documentées avant le retrait

Les sources suivantes fournissent des dépendances précises et des alternatives à examiner. Respectez leur périmètre plutôt que de les étendre à tous les déploiements d’accès distant ou de synchronisation.

Sources : dépannage VPN NT4, enregistrer un NPS, accès TGGAU, autorisations de réécriture des mots de passe.

L’enregistrement NPS ne prouve pas un besoin d’Anonymous. Pour TGGAU, l’alternative Windows Authorization Access nécessite sa propre vérification des autorisations : les recommandations Microsoft distinguent les nouveaux domaines des domaines en mode mixte ou mis à niveau, où le groupe n’a pas reçu automatiquement l’accès nécessaire. Ne lui substituez pas un groupe privilégié simplement pour faire disparaître une erreur d’accès refusé. TGGAU et WAA.

Les recommandations Entra Connect signalent explicitement des problèmes de réécriture lorsque Authenticated Users manque, surtout avec les anciennes versions. Leur section SAM-server distingue aussi les autorisations directes d’Authenticated Users de l’accès obtenu par ce groupe. Cette dépendance documentée empêche de recommander systématiquement le retrait de toutes les identités larges. Dépannage de la réécriture.

Exchange reste non démontré comme source automatique d’appartenance ici. L’annexe B indique que l’installation d’Exchange peut créer des comptes et groupes supplémentaires dans Builtin et Users ; elle n’établit pas d’ajouts automatiques au SID 554 ni de versions concernées. Traitez les entrées portant un nom Exchange et les appliances comme des questions nécessitant des preuves propres au produit et des tests fonctionnels. Annexe B.

Étape 3 : simuler un retrait sélectionné

Examinez en priorité Anonymous, puis Everyone avec le comportement réel des jetons, et les comptes sans besoin confirmé. Conservez Authenticated Users jusqu’à ce que ses dépendances soient comprises. Choisissez le membre résolu exact et répétez l’opération dans un domaine de test représentatif avant de planifier le changement du domaine de production.

L’adaptation suivante utilise les identifiants SID documentés et -WhatIf. Elle simule le retrait d’Anonymous ; ce n’est pas une commande exécutée pour cet article. Validez d’abord le principal résolu. Remove-ADGroupMember.

Remove-ADGroupMember -Identity "S-1-5-32-554" -Members "S-1-5-7" -Server "dc01.contoso.com" -WhatIf

Après les tests et la décision de changement de l’administrateur, effectuez uniquement le retrait sélectionné avec la confirmation normale. La cmdlet documente le comportement de confirmation ; évitez une boucle qui vide le groupe ou supprime l’examen de chaque membre. Un aperçu -WhatIf n’effectue pas le retrait et ne prouve pas qu’il réussirait ; il ne peut pas prévoir le comportement des applications après un changement réel. Paramètres de retrait et de confirmation.

Étape 4 : vérifier le fonctionnement, les autorisations et la trace du changement

Proposez une fenêtre de changement du domaine, un membre à la fois, avec un responsable nommé pour le retour arrière. Relisez l’appartenance sur les DC utilisés par les services concernés après réplication, puis répétez les opérations autorisées de l’application dans le contexte de sécurité pertinent. Les recommandations Microsoft sur la réécriture abordent précisément les délais de réplication et l’utilisation d’un DC préféré pendant la correction des autorisations. Considérations de réplication.

Examinez les erreurs d’accès applicatif et l’événement 4733 pour le retrait prévu ; surveillez 4732 pour les ajouts, y compris un retour arrière contrôlé. Si le fonctionnement régresse, rétablissez uniquement l’appartenance modifiée au moyen du processus de récupération approuvé et examinez la dépendance. Ne prescrivez pas de durée de surveillance arbitraire ni de redémarrage universel des DC : l’instruction de redémarrage du document VPN NT4 appartient à son scénario historique précis. 4733, 4732, scénario NT4.

Comment EtcSec détecte cette configuration

Le contrôle etc-collector PRE_WINDOWS_2000_ACCESS est implémenté dans ad/groups/membership/pre-windows-2000-access.go:24. Le Detect() examiné convertit en minuscules les CN et SAMAccountName de chaque groupe, puis sélectionne le premier groupe dont le nom contient pre-windows 2000 compatible access. Son Count vaut len(targetGroup.Members) : tous les membres collectés sont comptés, y compris Authenticated Users et les comptes applicatifs. Le catalogue examiné lui attribue le niveau Medium et un poids de 1.

La fonction renvoie un constat même lorsqu’aucun groupe correspondant n’est trouvé ou que le nombre est nul. Les détails et le groupe concerné ne sont inclus que si IncludeDetails est activé, qu’un groupe a été trouvé et que le nombre est positif. Ces énoncés décrivent l’implémentation examinée, pas un audit exécuté sur votre domaine.

Le contrôle ne vérifie pas les SID du groupe ou des membres, n’examine pas les ACE, ne lit pas dsHeuristics, ne développe pas les appartenances imbriquées dans cette fonction et ne teste pas l’accès d’une application. La correspondance sur une sous-chaîne anglaise peut manquer des noms localisés et sélectionner un nom correspondant non souhaité ; des données d’entrée manquantes peuvent aussi produire zéro. Utilisez les mesures fondées sur les SID pour qualifier le signal. Un nombre positif ne prouve pas l’appartenance d’Anonymous, et zéro ne prouve pas que tous les chemins de lecture sont restreints.

COMPUTER_PRE_WINDOWS_2000 est explicitement hors du périmètre et des tags de cet article. Son Detect() examiné séparément dans ad/computers/other/pre-windows-2000.go:43 compare les valeurs non vides d’OperatingSystem au motif Windows 95|Windows 98, sans tenir compte de la casse. Il n’examine ni les membres ni les autorisations de ce groupe.

Clôturez la revue avec les faits établis : identités résolues, chemins ACL examinés, restrictions de protocole vérifiées, dépendances testées et changements sélectionnés surveillés. Le détecteur d’appartenance aide à prioriser ce travail ; les preuves déterminent quels accès peuvent être retirés sans compromettre le fonctionnement.