Les risques de l’approbation

votre domaine puissent accéder à une ressource. Cependant, la composition du groupe Utilisateurs Authentifiés change quand on ajoute un domaine approuvé. Si notre domaine A n’en approuve aucun autre, le groupe Utilisateurs Authentifiés se limite aux utilisateurs du domaine A et, quand on évalue l’accès aux objets sur les serveurs et stations de travail membres, aux utilisateurs locaux de ces ordinateurs. Cependant, si le domaine A approuve le domaine B, le groupe Utilisateurs Authentifiés s’étend soudainement pour englober aussi tous les utilisateurs du domaine B. Par conséquent, les éventuels fichiers ou autres objets qui ont des entrées ACL accordant l’accès aux Utilisateurs Authentifiés, étendront désormais cet accès aux utilisateurs du domaine B également. (Si l’approbation du domaine A avec domaine B était transitive, l’accès serait également étendu aux utilisateurs de tous les domaines approuvés par le domaine B.)

Selon le genre de relation d’approbation, Windows pourrait utiliser Kerberos ou NTLM (NT LAN Manager) comme protocole d’authentification pour traiter les requêtes de logon entre les deux domaines. Bien qu’il soit possible de « renifler » les paquets de l’un ou l’autre des protocoles et de les utiliser pour deviner un mot de passe utilisateur, il est plus facile et plus rapide de deviner l’information NTLM. Si vous mettez à niveau les DC et stations de travail dans le domaine approuvé et tous les ordinateurs dans le domaine approuvant pour les faire passer à NTLMv2, vous pouvez boucher les plus gros trous dans NTLM, mais Kerberos reste plus puissant.

Ces risques techniques sont plutôt faciles à contrôler, par rapport au risque principal que constitue l’approbation d’un autre domaine : approuver les administrateurs du domaine. Quand le domaine A approuve le domaine B, le domaine A attend des administrateurs du domaine B qu’ils soient professionnels et honnêtes. Si le domaine B est compromis, toutes les ressources du domaine A partagées avec le domaine B sont en péril. Par exemple, supposons que Bob ait un compte dans le domaine B et qu’il ait accès à une base de données importante du domaine A.

Si un assaillant essaie de deviner le mot de passe de Bob par une succession de tentatives de logon, peu importe la rigueur de la stratégie de lockout du domaine A : seule la stratégie de lockout du domaine B se dresse entre l’attaquant et la base de données du domaine A. En outre, seuls les administrateurs du domaine B vont remarquer les défaillances de logon dans le journal Security du DC. (Bien que, si l’assaillant attaque directement les ordinateurs du domaine A avec le compte de Bob, les défaillances du logon local apparaîtront dans le journal Security de cet ordinateur.) Par conséquent, si les administrateurs de domaines dans un domaine approuvé sont laxistes en sécurisation des comptes, surveillance des intrusions et autres mesures de sécurité, correction de leurs systèmes ou application d’autres contrôles de sécurité, le domaine approbateur – ou au moins ses ressources qui sont à la disposition des utilisateurs du domaine approuvé – est exposé aux mêmes risques que le domaine approuvé.

Il faut ajouter à cela l’éventualité d’un administrateur indélicat dans le domaine approuvé. En effet, des administrateurs peuvent manipuler les comptes et les groupes de nombreuses façons, entre autres en imitant un utilisateur auquel vous avez accordé l’accès. Bien entendu, ces mêmes risques sont présents aussi dans le domaine approbateur. Par conséquent, quand vous décidez d’approuver ou non un autre domaine, vous devez vous demander si vous faites vraiment confiance aux administrateurs de l’autre domaine. Toutefois, l’alternative au fait de ne pas approuver un domaine qui contient des utilisateurs avec lesquels vous devez partager des ressources, n’est pas non plus sans risque. Si vous n’approuvez pas le domaine, il vous faudra créer des comptes pour ses utilisateurs. Dans ce cas, vous aurez la certitude que ces comptes bénéficieront du niveau de sécurité que vous maintenez dans votre domaine mais saurez-vous quand ces utilisateurs quitteront leurs fonctions ou en changeront – ou les administrateurs dans le domaine approuvé auront-ils une plus grande chance de désactiver les comptes ou d’ajuster les appartenances par suite de changements de job ?

Un autre risque découle du fait que les DC approuvés fournissent des informations sur l’appartenance aux groupes aux DC approbateurs, en plus de l’authentification des utilisateurs. Dans une forêt, un DC approuve tous les SID qu’un DC approuvé spécifie pour un utilisateur. Par conséquent, un utilisateur malveillant du domaine B, suffisamment compétent ou détenteur d’un programme écrit par un pirate compétent, pourrait faire qu’un DC du domaine B spécifie que l’administrateur du domaine B appartient au groupe Administrators du domaine A, et le domaine A lui octroierait l’autorité administrative. (Voir « Facts about Directory Structures and Directory Structure Owners » dans “Design Considerations for Delegation of Administration in Active Directory”.

Quand cette vulnérabilité a été découverte pour la première fois, un assaillant pouvait l’exploiter contre tout type de relation d’approbation. Pour contrecarrer ce risque, Microsoft a ajouté une nouvelle fonction à toutes les versions de Windows, appelée SID filtering. Avec SID filtering activé, le DC approbateur analyse les SID revenant d’un DC approuvé et refuse par filtrage ceux qui correspondent à des comptes ou à des groupes étrangers au domaine approuvé. Cependant, SID filtering n’est pas possible entre des domaines de la même forêt parce que SID filtering rompt la réplication. Un administrateur de domaine dans le domaine approbateur doit appliquer SID filtering au domaine approuvé. Par exemple, on pourrait utiliser la commande Netdom suivante pour filtrer les SID provenant du domaine

Jonescorp :
C:\winnt>netdom /filtersids yes jonescorp