Audit Active Directory : Part 2 - les relations d'approbation

Envoyer

Sommaire

 

 

Introduction

Après avoir traité les sous-réseaux dans notre premier article « Audit Active Directory : Part 1 - les sous-réseaux », nous allons voir dans ce nouvel article comment auditer les relations d’approbation Active Directory.

Bien que nous ferons un petit rappel sur la notion de relation d’approbation Active Directory et les différentes informations à prendre en compte, nous éviterons de rentrer trop dans le détail sur le sujet. L’objectif de cet article est vraiment de vous permettre de collecter les données essentielles pour analyser avec pertinence vos relations d’approbation.

 


Quelle est l'utilité d'une relation d'approbation ?

Comme son nom l’indique, une relation d’approbation est un lien de confiance établi entre deux domaines Active Directory ou, plus rarement, un domaine Active Directory et un domaine Kerberos Non-Windows.

Une relation d’approbation va permettre de mutualiser l’accès à des ressources entre deux domaines Active Directory qui disposent d’une base de données utilisateurs et ordinateurs différente.

Un exemple assez rependu est le cas d’une multinationale qui peut disposer d’une forêt constituée de plusieurs domaines enfants. Cela lui permet de scinder les responsabilités administratives en fonction de zones géographiques déterminées. Elle va disposer d’un domaine Active Directory pour l’Amérique, un autre pour l’Asie-Pacifique et pour la région EMEA… Chaque domaine est autonome et est géré par des équipes informatiques spécifiques. Toutefois, il peut s’avérer qu’un utilisateur de la zone Asie-Pacifique ait besoin d’accéder à un serveur de fichiers intégré au domaine de la région EMEA. C’est là que la relation d’approbation entre en jeu !

 

Grâce à la relation d’approbation, l’utilisateur du domaine « ap.corpnet.net » peut accéder aux données du serveur de fichiers situé sur le domaine « emea.corpnet.net ».

Voyons un autre exemple. Désormais, notre multinationale rachète une compagnie qui dispose également de son propre annuaire Active Directory. Les deux structures ont besoin de partager des ressources de manière transparente pour les utilisateurs. Une relation d’approbation est donc établie entre les deux forêts afin que les ressources puissent être accessibles entre elles.

 

L’utilisateur de la forêt « corpnet.net » peut accéder aux données du serveur de fichiers situé sur le domaine de la filiale « contoso.com ».

 

 

Quelles sont les caractéristiques et les options d'une relation d'apporbation ?

Pour pouvoir auditer correctement les relations d’approbations, il est important d’en connaître les différentes caractéristiques. En général, cela se cantonne à :

  • un type: externe, forêt, parent-enfant, raccourci ou Kerberos.
  • une direction: entrante, sortante ou bidirectionnelle.
  • Transitivité: active ou inactive.

Pourquoi est-ce important ? Tout simplement parce que le niveau de sécurité exigé pour une relation d’approbation variera en fonction de ces caractéristiques.

Si nous prenons le cas d’une relation d’approbation de type « Parent-Enfant » (ou interne). Sachant que l’environnement informatique est nettement mieux maitriser en interne que dans le cadre d’une relation d’approbation de type « Externe » avec un partenaire, forcément cette dernière sera plus exigeante en terme de sécurité. Il en va de même pour la direction. Approuver un domaine externe (direction entrante) est forcément plus risqué pour l’organisation que d’être approuvée par un domaine externe (direction sortante).

 

Pour les options, la plupart étant fortement liées à la sécurité, il vous sera impérativement nécessaire de les connaître :

  • Authentification sélective: lorsque vous établissez un lien d’approbation entre deux domaines, l’ensemble des comptes du domaine ou de la forêt approuvée peuvent s’authentifier. Par exemple, ils font partie automatiquement du groupe « Utilisateurs authentifiés ». L’option « authentification sélective » permettra justement de limiter les autorisations d’accès à certains groupes d’utilisateurs par exemple.
  • Filtrage SID: Active Directory permet de migrer des objets d’un domaine à un autre afin de préserver les accès de l’environnement source. Cette conservation des accès passe par un attribut appelé « SID History » où l’identifiant de sécurité (SID) d’un ou plusieurs objets sources est associé à un objet de destination. Active Directory vérifie l’attribut SID ainsi que l’attribut SID History pour construire votre jeton d’accès. De ce fait, il serait tout à fait possible de lier, à votre insu, le SID d’un compte administrateur du domaine vers un compte lambda. Le filtrage SID, activé par défaut depuis Windows Server 2003, permet d’éviter ce genre de cas et en particulier lorsqu’il n’y a pas de migration d’objets à réaliser entre les deux domaines.
  • Quarantaine SID: Cette option permet d’exclure tous les identifiants de sécurité (SID) n’appartenant pas au domaine approuvé. L’option est activée par défaut depuis Windows Server 2003.

 

L’explication reste assez sommaire et n’est peut-être pas forcément très compréhensible pour tous. Je vous encourage donc à lire l’article de Microsoft « Security Considerations for Trusts » (http://technet.microsoft.com/en-us/library/cc755321(v=ws.10).aspx) pour de plus amples informations.

 

 

 

Collecter et valider l'état de vos relations d'approbation

Dans un premier temps, vous pouvez visualiser rapidement les différentes relations d’approbation de votre forêt depuis la console MMC « Domaines et approbations Active Directory ». A l’aide d’un clic droit, sélectionnez « Propriétés » sur chaque domaine de votre forêt et allez dans l’onglet « Approbations » pour obtenir la liste des relations d’approbation du domaine concerné.

 

 

 

 

 

 

 

 

 

L’inconvénient de passer la MMC est qu’il est nécessaire de collecter l’information indépendamment pour chaque domaine. De plus,les options comme le filtrage SID et la quarantaine SID ne sont pas visibles. Enfin, vous ne pouvez pas vérifier l’état d’une relation d’approbation.

La deuxième alternative est d’utiliser l’outil en ligne de commande NLTEST qui est plus complet que la MMC pour collecter les relations d’approbation d’un domaine. Effectivement, il permet de remonter la valeur de la propriété « trustAttributes » qui identifie les différentes options activées sur une relation d’approbation (pour l’association valeur/options voir l’article MSDN depuis le lien http://msdn.microsoft.com/en-us/library/cc223779.aspx).

A partir d'une invite de commandes, taper la commande « nltest /domain_trusts ».

Clairement, ce n’est pas non plus très satisfaisant car, on doit traiter également chaque domaine indépendamment (utilisez l’option /server pour pointer sur un contrôleur de domaine d’un domaine spécifique), qu’il faut se casser un peu la tête pour évaluer les différentes options d’une relation d’approbation et qu’il n’est pas possible de vérifier l’état d’une relation d’approbation.

 

 

Un script pour faciliter la collecte

Du coup, j’ai développé un script PowerShell qui permet de palier aux déficiences des outils standards proposé par Microsoft. Le script collecte TOUTES les relations d’approbation de votre forêt et VALIDE l’état de chacune d’entre elles (dans la mesure du possible et en fonction des droits dont vous disposez).

Le script est téléchargeable depuis le Script Center de Microsoft via le lien http://gallery.technet.microsoft.com/scriptcenter/Auditing-Active-Directory-9d8eb14a

Il va collecter l’ensemble des informations des relations d’approbation de votre forêt ou d’un domaine spécifique et il va vérifier l’état de chaque lien à l’aide de classe WMI « Trustmon » (http://msdn.microsoft.com/en-us/library/windows/desktop/aa393921(v=vs.85).aspx) et de la méthode .Net « System.DirectoryServices.ActiveDirectory.Domain.VerifyTrustRelationship » (http://msdn.microsoft.com/fr-fr/library/system.directoryservices.activedirectory.domain.verifytrustrelationship(v=vs.85).aspx).

Son utilisation est simple. Il suffit simplement de spécifier le chemin du fichier d’export à l’aide de l’argument « FilePath ». Le script analyse par défaut la forêt sur laquelle vous êtes connecté. Si vous voulez analyser un domaine spécifique, vous devrez le spécifier à l’aide de l’argument « domainName ».

 

Le tout sera exporté au format CSV. Il ne vous restera plus qu’à traiter les informations !

 

 

 

 

How to Find Active Directory Schema Update History by Using PowerShell

Mise à jour le Lundi, 08 Juillet 2013 15:28