Identifier les connexions établies entre ordinateurs et contrôleurs de domaine Active Directory

Envoyer

Sommaire

 

 

Introduction

Beaucoup s’appuient sur la variable d’environnement %LOGONSERVER% pour identifier le contrôleur de domaine utilisé par un ordinateur. Premièrement, Il faut savoir que cette variable d’environnement n’est pas mise à jour et donc pas toujours très fiable. De plus, même en identifiant le contrôleur de domaine avec lequel le canal sécurisé a été établi, d’autres services liés à Active Directory ne sont pas assujettis forcément à cette information.

Nous allons donc voir comme recueillir les informations de la manière la plus pertinente et la plus complète possible.

 

 


Etablissement du canal de communication sécurisé

Lorsque vous démarrez votre station de travail, un canal sécurisé est établi avec un contrôleur de domaine. Ce processus est sous la responsabilité du service NETLOGON qui initialise également la variable d’environnement %LOGONSERVER%.

Pour consulter la valeur de %LOGONSERVER%, ouvrez une invite de commandes et tapez la commande « set logonserver ».

 

 

 

 

Comme nous le disions en introduction, la valeur de la variable d’environnement %LOGONSERVER% n’est pas mise à jour. Il se peut donc que le canal sécurisé ait été établi avec un autre contrôleur de domaine entre le moment où la variable d’environnement %LOGONSERVER% a été initialisée et le moment où vous la consultez. De ce fait, il est préférable de s’appuyer sur l’outil dédié NLTEST (disponible par défaut sur les postes Windows 7 et intégré aux support tools pour Windows XP).

Pour connaître le contrôleur de domaine partenaire du canal sécurisé établi avec votre poste de travail, utilisez la commande « nltest /sc_query:[MONDOMAINE] ».

 

 

 

 

Notez également que la commande ci-dessus permet de connaître le statut actuel du canal sécurisé. Il est aussi possible de contrôler l’état de la connexion à l’aide de la cmdlet PowerShell « Test-ComputerSecureChannel » intégré au module PowerShell ActiveDirectory de Microsoft (disponible sur Windows 7 et Windows 2008 R2).

 

 

 

 

Afin de confirmer ce mécanisme, vous pouvez, à tout moment, réinitialiser le canal sécurisé à l’aide de la commande « nltest /sc_reset:[MONDOMAINE] ». Vous pouvez voir que dans notre exemple ci-dessous, à aucun moment la variable %LOGONSERVER% est identique aux résultats retournés par NLTEST. En conclusion, nous ne pouvons définitivement pas nous fier à elle.

 

 

 

 

 

 


Les services annexes

Outre l’établissement du canal sécurisé, d’autres services sont utilisés au sein d’un environnement Active Directory. Nous avons, entre autres, les dossiers partagés SYSVOL et NETLOGON, l’application des stratégies de groupe, le serveur de temps et l'authentification Kerberos. Tous ces services peuvent être utilisés indépendamment les uns des autres (en fonction de leur configuration, des temps de réponse…) par les ordinateurs du domaine.

Nous avons un exemple concret avec les dossiers partagés SYSVOL et NETLOGON. Sans entrer dans le détail, chaque contrôleur de domaine dispose d’un partage SYSVOL et NETLOGON qu’il met à la disposition des ordinateurs du domaine. Ils permettent par exemple de stocker la partie dite « fichiers » des stratégies de groupe, les scripts de connexion… Ses partages s’appuient sur DFS pour les publier sur un espace de nom commun (le nom de domaine Active Directory) et pour se répliquer entre chaque contrôleur de domaine.

On pourrait donc s’attendre à ce que, sur chaque ordinateur du domaine, le dossier SYSVOL et NETLOGON pointent sur le même contrôleur de domaine cependant ce n’est pas toujours le cas. Un ordinateur peut pointer sur deux contrôleurs de domaine différents à un instant donné.

 

 

 

 

 

 

 

 

 

Il peut être également intéressant de vérifier depuis quel contrôleur de domaine les stratégies de groupe sont appliquées au démarrage du poste. Il suffit d’utiliser la commande « gpresult /r ».

 

 

 

 

 

 

 

 

 

Chaque poste du domaine synchronise son temps à l’aide d’un serveur de temps. Pour consulter le serveur de temps utilisé par le poste de travail, nous avons à notre disposition l’outil « w32tm » qui permet, entre autres, de connaître la source de temps de notre poste à l’aide de la commande « w32tm /query /status ».

 

 

 

 

Enfin, concernant l’authentification Kerberos, il n’est pas vraiment possible de savoir quel serveur KDC a fourni le ticket au client Kerberos hormis en réalisant une capture réseau. Toutefois, vous pouvez identifier quel serveur KDC est ciblé par la machine à l’aide de la commande « nltest /dsgetdc:corpnet.net /kdc ».

 

Mise à jour le Mercredi, 01 Août 2012 20:56