Bien choisir son nom de domaine Active Directory

Sommaire

 

 

Introduction

Faisons un rapide parallèle : un couple de jeunes mariés attend un bébé. Ils réfléchissent longuement au prénom qu’ils vont lui donner. Ils savent que cette décision suivra leur enfant durant toute sa vie et qu’il pourra difficilement en changer.

Pour Active Directory, nous sommes un peu dans le même cas. Le nom que vous allez donner à votre domaine va le suivre toute son existence. De plus, il va être également très difficile voire impossible de le changer après coup. Enfin, il faudra s’assurer que le nom de domaine choisi ne représentera pas le moindre problème technique ou organisationnel.

Cet article va donc vous aider à faire le bon choix. Il fait écho à un article de Microsoft sur le sujet que je vous engage à consulter l’article Active Directory Domain Naming Considerations (http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-domain-naming-considerations.aspx).

 


Les critères techniques

L’ouverture des réseaux vers l’extérieur, la fédération de services ou la construction d’un Cloud hybride nécessitent plus que jamais que votre nom de domaine Active Directory soit localisable et compatible avec ce nouvel écosystème.

La première chose à respecter est d’utiliser un TLD existant. TLD pour « Top Level Domain » est un terme désignant les noms de domaines de premier niveau comme par exemple « .fr » ou « .com » (vous trouverez la liste complète depuis http://data.iana.org/TLD/tlds-alpha-by-domain.txt). En clair, il faudra éviter les « .local » ou « .lan ».

Idéalement, vous devriez vous appuyer sur votre nom de domaine Internet existant. A l’heure d’aujourd’hui, la plupart des entreprises ont à leur disposition un nom de domaine, ne serait-ce que pour leur site Internet. Il vous suffira de créer un sous-domaine rattaché à ce domaine existant. Par exemple, votre nom de domaine Internet est « macompagnie.fr ». Votre nom de domaine Active Directory pourra être « intra.macompagnie.fr » ou « ad.macompagnie.fr ». Et si vous ne disposez pas d’un nom de domaine sur Internet, il sera temps donc temps d’en prendre un!

Concernant les restrictions de caractères, c’est assez simple. Vous ne pouvez utiliser que des caractères alphabétiques (A-Z), caractères numériques (0-9) ou le signe moins (-). Pour plus de détails sur les conventions de noms Active Directory vous pouvez consulter ce lien http://support.microsoft.com/kb/909264.

 

 

Les critères humains et organisationnels

Ce point est secondaire mais le plus visible pour l’ensemble des utilisateurs. Du coup, il va falloir choisir un nom de domaine adapté à la structure et surtout qui sera viable dans le temps. Evitez une dénomination trop générique ou trop technique. J’ai cité « intra » un peu plus haut à titre d’exemple mais éviter ce genre de nom. Cela rentre dans le cadre du générique ou de l’ordinaire. Essayez de trouver un acronyme accrocheur en rapport avec l’activité de l’entreprise. Vous pourriez également faire participer les utilisateurs au choix du nom!

N’oubliez pas également qu’une entreprise peut changer de nom, être rachetée, fusionnée … et sans doute plus facilement que votre annuaire.

 

 

Changer le nom de votre domaine Active Directory

Il est possible de modifier le nom de votre domaine Active Directory mais les conditions sont restreintes. Microsoft fourni l’outil « rendom » pour réaliser l’opération. La procédure est disponible en anglais depuis le lien http://technet.microsoft.com/fr-fr/library/cc794869(v=ws.10).aspx.

En terme de contraintes au niveau des produits Microsoft, seul Exchange 2003 SP1 est supporté (les versions ultérieures ou antérieures ne le sont donc pas) et aucune version de SCCM (pas de support officiel). Il faudra également que vous disposiez à minima d’un niveau fonctionnel Active Directory supérieur ou égal à Windows Server 2003.

Pour les applications tierces, il faudra gérer au cas par cas. Plus l’adhérence de l’application à l’annuaire est forte, plus le risque sera grand.

En clair, c’est une opération plus ou moins réalisable en fonction de votre environnement mais à éviter autant que possible.

 

 

How to Find Active Directory Schema Update History by Using PowerShell

Audit Active Directory : Part 1 – les sous-réseaux

Sommaire

 

 

Introduction

Active Directory est constitué de nombreux composants qui doivent pouvoir être évaluer régulièrement sous la forme d’un audit. L’objectif est de pouvoir améliorer le fonctionnement de votre architecture Active Directory et détecter les différents dysfonctionnements.

Dans ce premier article, nous allons traiter le cas des sous-réseaux Active Directory. Le niveau de criticité est très faible mais pour des questions de performances, il est intéressant de les prendre en compte.

 


La notion de sous-réseau dans Active Directory

Généralement dans un réseau d’entreprise  un ou plusieurs sous-réseaux TCP/IP sont associés à un site physique. Naturellement, la topologie de sites Active Directory s’appuie également sur cet état de fait.

Dans Active Directory, un objet de type « Site » est créé pour chaque site géographique. Pour que ces sites puissent être localisés par les postes clients, les sous-réseaux du site sont aussi déclarés sont forme d’objets de type « Subnet » et rattachés au bon objet « Site ».

Le principal intérêt est que si un poste se localise correctement sur son site de référence, alors il aura accès à un service de proximité et donc de meilleure qualité. D’autre part, cela évitera de surcharger les liaisons WAN et donc d’optimiser la bande passante.

Prenons un exemple. Une société s’établit sur Paris et décide d’ouvrir une succursale sur Marseille. Cette succursale va être reliée informatiquement au site de Paris tout en disposant de son propre contrôleur de domaine. Nous avons déclaré le sous-réseau « 192.168.0.0/24 » qui est rattaché au site de Paris et le sous-réseau « 192.168.1.0/24 » pour le site de Marseille. Du coup, si nous nous retrouvons avec un poste sur Marseille qui n’est dans aucun sous-réseau déclaré, alors il va s’authentifier de manière totalement aléatoire sur le site de Paris ou sur le site de Marseille.

 

En conclusion, la première chose à faire dans la gestion des sous-réseaux Active Directory est de s’assurer qu’ils sont tous bien déclarés et associer au bon site Active Directory.

 

 

Détecter les sous-réseaux manquants

Lorsque qu’un client contacte un contrôleur de domaine alors que son adresse IP ne fait pas parti d’un sous-réseau déclaré, une information est enregistrée dans le fichier de log « %SYSTEMROOT%\Debug\netlogon.log ».

L’information est enregistré avec un tag « NO_CLIENT_SITE ». Le tag est assorti du nom du poste et de son adresse IP. Il est donc conseillé de vérifier régulièrement le contenu du fichier journal sur chaque contrôleur de domaine. Par contre, Si vous avez une structure physique étendue avec beaucoup de contrôleurs de domaine, vous pouvez rapidement vous trouver submergé.

De ce fait, j’ai créé un script qui va vous permettre de collecter l’ensemble des tags « NO_CLIENT_SITE » de tous vos contrôleurs de domaine (d’un domaine spécifique, d’une forêt ou d’une liste de contrôleurs de domaine). Le cas échéant le script génèrera  la liste des sous-réseaux manquants. Il ne vous restera plus qu’à identifier sur quel site les ajouter.

Le script est disponible depuis le lien suivant : Collect Active Directory missing subnets (http://gallery.technet.microsoft.com/scriptcenter/Collect-Active-Directory-fa4dff2e)

{gallery}66_AUDITAD_SUBNETS/02{/gallery}

 

 

 


Notez que pour pouvoir l’exécuter, vous devrez respecter certains prérequis :

  • Système d’exploitation client : Windows 7 Service Pack 1, Windows 8, Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2, Windows Server 2012 avec PowerShell V3 (en installant le Windows Management Framework 3.0 si nécessaire).
  • Système d’exploitation des contrôleurs de domaine : Windows Server 2003, Windows Server 2008 et Windows Server 2012.
  • Droits : « administrateur du domaine » pour analyser les contrôleurs de domaine d’un domaine, « administrateur de l’entreprise » pour analyser les contrôleurs de domaine de toute la forêt.

 

 

Détecter les sous-réseaux se chevauchant

Vous pouvez également rencontrer des problèmes de chevauchement lors de la déclaration de vos sous réseaux. Comme son nom l’indique, un chevauchement est tout simplement le fait d’avoir deux sous-réseaux ou plus qui couvrent partiellement la même plage d’adresses IP (à ne pas confondre avec les sous-réseaux de type « catch-all » qui sont assimilables à des super-étendues de sous-réseau (pour plus d’information sur la notion de sous-réseau « catch-all » vous pouvez consulter l’article http://technet.microsoft.com/fr-fr/magazine/2009.06.subnets.aspx).

Pour cela, j’ai créé un second script qui va récupérer l’ensemble des sous-réseaux déclarés dans l’annuaire et vérifier qu’ils ne se chevauchent pas. Il ne vous restera plus qu’à déterminer s’il est nécessaire de modifier les sous-réseaux concernés

Le script est disponible depuis le lien suivant: Auditing Active Directory Subnets (http://gallery.technet.microsoft.com/scriptcenter/Auditing-Active-Directory-c47935c0)

Le script vous permettra également de détecter la possibilité de créer des « super » sous-réseaux pour chaque site afin de vous faciliter la vie. Il vous indiquera également si des sous-réseaux sont orphelins (non-rattachés à un site).

{gallery}66_AUDITAD_SUBNETS/03{/gallery}

 

 


 

En terme de prérequis, le script n’a pas d’exigence particulière hormis si vous désirez prendre en charge les sous-réseaux de type « IPv6 ». Il vous faudra un .Net Framework 4 et indiquer à PowerShell de l’utiliser  (le script vous indiquera la marche à suivre).

Remarque : le script est capable d’évaluer la possibilité de créer une super-étendue sur un site Active Directory afin de réduire le nombre d’objets « subnet » déclarés.

How to Find Active Directory Schema Update History by Using PowerShell

Identifier les modifications du schéma Active Directory

Sommaire

 

 

Introduction

Analyser les données de votre schéma Active Directory peut être très instructif. Cela permettra de mieux connaitre l’histoire de votre annuaire et évaluer les différentes mises à jour réalisées. Nous allons donc voir à travers cet article comment collecter et traiter les données nécessaires à notre analyse du schéma Active Directory.

Nous nous sommes inspiré de l’article « How to find active directory schema update history by using powershell » disponible sur le blog de Hey Scripting Guy.

 


Identifier les versions actuelles de votre schéma

Certains produits exigent que le schéma Active Directory soit mis à jour. Chaque nouvelle version de ces produits va également nécessiter possiblement une nouvelle mise à jour du schéma introduisant la notion de version.

Les produits les plus connus nécessitant une modification du schéma sont Microsoft Exchange Server, Microsoft Lync Server et bien évidement Active Directory.

Il est donc possible d’identifier rapidement, au sein du schéma, si un de ces produits a été déployé et quelle en est la dernière version. Pour cela, nous décrivons comment procéder en vous reportant à nos articles proposés ci-dessous :

 

Vous pouvez également utiliser le script PowerShell proposé par Ashley McGlone de Microsoft est disponible ICI.

Actuellement et à notre connaissance, aucun autre produit que ceux cités ci-dessus ne peut être identifié de manière analogue. Il faudra donc réaliser nécessairement une analyse plus approfondie.

 

 

A la découverte des grandes dates de l’histoire de votre schéma

Le schéma est en ensemble de classes et d’attributs permettant de construire des objets dans l’Active Directory. Il est donc rare que la modification du schéma soit réalisée régulièrement. En réalité, le schéma est modifié soit pour des besoins spécifiques (ajout d’un ou plusieurs attributs sur une classe d’objet), soit, et en général c’est la grande majorité des cas, pour des montées de version des produits Microsoft (Active Directory, Exchange, Lync, SCCM…). Ces montées de version entrainent la création de lot d’attributs et/ou de classes qui peuvent être rapidement identifiés depuis les diverses publications officielles de Microsoft. Concernant les modifications spécifiques, elles sont peut recommandées, extrêmement rares et très limitées donc également facilement différentiables.

Remarque : pour plus d’information sur la notion de schéma Active Directory, nous vous invitons à consulter notre article sur le sujet « Les versions de schéma et les niveaux fonctionnels Active Directory ».

La première étape consiste à récupérer tous les objets de la partition de schéma ainsi que leur date de création. Comme une mise à jour de schéma induit la création de plusieurs nouvelles classes ou attributs, en regroupant les objets du schéma par date de création, nous aurons rapidement une vue globale sur les différentes mises à jour effectuées.

Pour cela, nous avons utilisé le code PowerShell ci-dessous, retournant le nombre d’objets dans le schéma Active Directory regroupés par date de création  et par date de modification.

{codecitation style= »brush:PowerShell »}

$Forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

$ADSearcher = New-Object System.DirectoryServices.DirectorySearcher
$ADSearcher.SearchRoot = New-Object System.DirectoryServices.DirectoryEntry($forest.Schema.GetDirectoryEntry().Path)
$ADSearcher.PageSize = 10000
$ADSearcher.SearchScope = « Subtree »

$SchemaProperties = @(« objectclass », »name », »whenchanged », »whencreated »)

$ADSearcher.PropertiesToLoad.Clear()
$ADSearcher.PropertiesToLoad.AddRange(@($SchemaProperties))

$ADSchema = $ADSearcher.FindAll()

$selectedProperties = $SchemaProperties | ForEach-Object {@{name= »$_ »;expression=$ExecutionContext.InvokeCommand.NewScriptBlock(« `$_[‘$_’] »)}}
$FilteredResult = @()

foreach ( $object in $ADSchema )
{
$FilteredResult += $Object.Properties | Select-Object -Property $selectedProperties | Select-Object « objectClass », »name »,@{Name= »whenChanged »;Expression={($_.whenChanged).Date.ToShortDateString()}},@{Name= »WhenCreated »;Expression={($_.WhenCreated).Date.ToShortDateString()}}
}

Write-Host « Schema objects grouped by creation date: » -foreground green
$FilteredResult | group-object WhenCreated | ft Count,Name -autosize

Write-Host « Schema objects grouped by modification date: » -foreground green
$FilteredResult | group-object WhenChanged | ft Count,Name –autosize
$FilteredResult | Export-Csv –Path « Export-SchemaObjects.csv » –delimiter « ; » –NotypeInformation

{/codecitation}

 

Nous l’avons ensuite exécuté dans un environnement de test où nous avons réalisé les opérations suivantes :

  • Création de la forêt le 19 décembre 2012 sous Windows 2000.
  • Mise à jour du schéma le 27 décembre 2012 vers Windows 2003.
  • Mise à jour du schéma le 3 Janvier 2013 vers Windows 2003 R2.
  • Mise à jour du schéma le 10 Janvier 2013 vers Windows 2008.

 

Lors de l’exécution du script dans ce même environnement de test, nous avons obtenu le résultat suivant :

 

Nous constatons que la date de création est un très bon indicateur et reflète bien les différentes mises à jour réalisées. La seule singularité du résultat retourné par le script est cette date du  21/10/1630. Elle provient en fait de la base de données modèle qui est utilisé par Active Directory lors de la promotion du premier contrôleur de domaine de la forêt. Dans notre exemple cette date provient du modèle fourni avec Windows Server 2000. Nous ne pouvons donc pas nous baser sur cette date pour connaître la date de création de la forêt. Par contre, nous pouvons nous base sur la date de création de la partition de schéma qui est le fameux « Count » égal à 1 dans notre exemple et qui nous permet donc de dire que tous les objets affichant une date de création en date du 21/10/1630 ont été créés le 19/12/2012.

La date de modification est par contre difficilement exploitable. En effet, un attribut ou une classe peut être modifié à plusieurs reprises. Une mise à jour du schéma peut également entrainer la modification de nombreux objets (comme par exemple la mise à jour de Windows 2008 qui met à jour de nombreux attributs pour la fonctionnalité FAS de RODC).

 

 

Identifier la nature des différentes mises à jour

Une fois que nous avons identifié clairement les différentes dates de mises à jour de notre schéma, il faut maintenant identifier à quel type de mise à jour elles sont associées.

Nous savons déjà que certains produits Microsoft sont responsables de la création de classes et d’attributs à chaque nouvelle version  (Il même d’ailleurs fort probable que la quasi-totalité des mises à jour est été faites par un de ces produits):

  • Microsoft Windows Server et Active Directory
  • Microsoft Exchange Server
  • Microsoft Lync Server
  • Microsoft System Center Configuration Manager

 

Il ne restait donc plus qu’à associer les noms des différents attributs ou classes du schéma en se basant sur diverses sources :

 

Afin d’exploiter au mieux cette information, nous avons tenté de consolider dans un fichier CSV l’ensemble des attributs et classes du schéma associé aux différentes versions des produits Microsoft. Le fichier est disponible en téléchargement ICI. Il vous suffira de rechercher le nom d’un attribut pour obtenir la version du produit Microsoft et d’y associer une date de création.

 

 

Facilitez-vous la vie !

Afin de réaliser toutes ces opérations de manière automatique, nous avons créé le script PowerShell « Active Directory Schema Discover 1.0 » disposant d’une interface graphique afin de faciliter la consultation des informations relatives au schéma.

{gallery}59_ADSCHEMAHISTORY/02{/gallery}

 

 

 

 

 

 

 

 


Le script est disponible en téléchargement ICI.

 

 

 

Aller plus loin

Nous avons vu premièrement comment identifier les différentes dates de mises à jour de votre schéma. Ensuite, nous avons montré comment associer ces dates de mises à jour aux différents produits. Le cas échéant, les possibles personnalisations de votre schéma peuvent apparaitre au grand jour et ouvrir le pas à de nouvelles investigations.

Mais l’analyse de notre schéma n’est pas faite en profondeur. Les possibles modifications d’attributs existants n’apparaitront pas dans le cadre de ces opérations. Il faudra donc, si nécessaire, pousser l’analyse et utiliser des outils tel que « AD DS / LDS Schema Analyzer » de Microsoft que nous vous présenterons dans un prochain article.

 

 


How to Find Active Directory Schema Update History by Using PowerShell

Quel type de mécanisme DNS choisir (stub, secondaire ou redirecteurs conditionnels) ?

Sommaire

 

 

Introduction

Lorsqu’il est nécessaire que deux forêts distinctes puissent résoudre mutuellement leurs noms de machine et plus particulièrement lors de la création d’une relation d’approbation, vous serez dans l’obligation de mettre en place un mécanisme de résolution DNS entre ces deux forêts.

Pour cela, il existe trois solutions spécifiques qui sont la zone DNS secondaire, la zone de stub et les redirecteurs conditionnels. Chacune de ces solutions offre son lot d’avantages et d’inconvénients que nous allons voir au sein de cet article.

Remarque : Microsoft propose déjà un très bon article permettant de comprendre la différence entre une zone stub et les redirecteurs conditionnels: Différence entre les zones de stub et les redirecteurs conditionnels.

 


La zone secondaire

Une zone secondaire est une copie complète d’une zone primaire accessible uniquement en lecture seule. Sa mise en place permet d’accélérer le temps de réponse des requêtes des clients DNS car le serveur disposant de la zone secondaire traitent directement les demandes de résolution DNS.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Pour permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé un zone secondaire  « corpnet.net » sur les serveurs DNS « NS01.fabrikam.com » et « NS02.fabrikam.com ». Seul le serveur « NS03.fabrikam.com » n’est pas à même de résoudre la zone « corpnet.net » car il ne dispose pas d’une copie de la zone « corpnet.net ».

 

Un premier client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » à partir de « NS02.fabrikam.com »:

1-     Le client envoie sa demande de résolution au serveur « NS02.fabrikam.com ».

2-     Le serveur lui renvoie le résultat de la requête.

 

Un deuxième client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » à partir de « NS03.fabrikam.com »:

3-     Le client envoie une demande de résolution au serveur « NS03.fabrikam.com ».

4-     Le serveur DNS renvoie une erreur.

 


La zone de DNS secondaire est de moins en moins utilisée car elle représente généralement deux principaux points faibles. Premièrement, la zone secondaire est gérée indépendamment sur chaque serveur DNS (pas de stockage possible depuis la base Active Directory) et il peut devenir complexe de la mettre à disposition à l’ensemble de l’infrastructure. Ensuite, la zone secondaire peut générer de lourdes réplications car elle doit récupérer la totalité de la zone DNS primaire. Il faut qu’elle soit utilisé soit de manière intensive, soit que la zone DNS primaire ne contienne que peu d’enregistrements pour qu’elle puisse représenter un réel intérêt.

 

 

La zone de stub

A la manière d’une zone DNS secondaire, la zone de stub est une copie en lecture seule d’une zone DNS. Toutefois, elle ne dispose que des enregistrements nécessaires pour identifier les serveurs DNS autoritaires pour la zone concernée (enregistrement SOA, enregistrement A et NS). De ce fait, la réplication des mises à jour ne concerne qu’un nombre limité d’enregistrements (A noter que le rafraichissement de la zone s’appuie sur la valeur du paramètre d’actualisation spécifié dans l’enregistrement de ressources SOA).

La zone de stub a également la possibilité de pouvoir être stockée directement sur Active Directory et donc de profiter de la réplication multi-maître d’Active Directory.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Afin de permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé une zone de stub pour la zone « corpnet.net » sur le domaine « fabrikam.com ». Nous avons décidé de la stocker sur Active Directory et de la rendre disponible sur l’ensemble des serveurs DNS du domaine.

Lorsqu’un client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » :

1-     Le client envoie une demande de résolution sur un des serveurs DNS.

2-     Le serveur DNS contacté sur « fabrikam.com » sélectionne un serveur autoritaire depuis la zone de stub et lui transfert la demande de résolution.

3-     Le serveur DNS contacté sur « corpnet.net » renvoie le résultat de la requête DNS.

4-     Le serveur DNS contacté initialement par le client  lui fournit le résultat de la requête DNS.

 

La zone de stub représente un réel avantage en termes d’administration. Par contre, la mise en place d’une zone de stub ne permet de pas contrôler les flux entre la zone de stub et la zone primaire. Si nous reprenons l’exemple ci-dessus, un serveur DNS du domaine « fabrikam.com » contactera aléatoirement n’importe quel serveur DNS autoritaire sur le domaine « corpnet.net » ce qui peut poser des problèmes si un filtrage de sécurité est mis en place entre les deux forêts.

 

 

 

Le redirecteur conditionnel

A la manière d’une règle de routage IP où l’on spécifie le routeur IP à utiliser pour contacter un réseau IP spécifique, le redirecteur conditionnel permet de préciser le ou les serveurs DNS à interroger pour résoudre un domaine DNS donné.

Un redirecteur conditionnel peut être stocké directement sur la base Active Directory et être répliqué sur l’ensemble des serveurs DNS de la forêt afin de permettre d’avoir des règles de redirection DNS à l’échelle de l’entreprise. Ce dernier point permet de simplifier grandement l’administration et le déploiement des redirecteurs conditionnels.

Afin de mieux comprendre le fonctionnement, prenons l’exemple détaillé ci-dessous de deux forêts Active Directory « corpnet.net » et « fabrikam.com ». Pour permettre la résolution de nom du domaine « corpnet.net » depuis le domaine « fabrikam.com », nous avons créé un redirecteur conditionnel « corpnet.net » sur le domaine « fabrikam.com » pointant vers le serveur « NS03.corpnet.net ». Le redirecteur conditionnel est stocké sur Active Directory et est disponible sur l’ensemble des serveurs DNS du domaine.

Lorsqu’un client sur « fabrikam.com » tente de résoudre un nom d’hôte « x.corpnet.net » :

1-     Le client envoie une demande de résolution sur un des serveurs DNS.

2-     Le serveur contacté  sur « fabrikam.com » contacte le serveur NS03.corpnet.net afin de réaliser la résolution de nom.

3-     « NS03.corpnet.net » renvoie le résultat de la requête DNS au serveur de « fabrikram.com ».

4-     Le serveur DNS contacté initialement par le client  lui fournit le résultat de la requête DNS.

 

Le redirecteur conditionnel est simple à mettre en place et permet de définir clairement le ou les serveurs DNS à utiliser pour une zone DNS donnée. Le contrôle de flux réseau est donc assuré.

D’un autre côté, les redirecteurs conditionnels nécessitent une maintenance accrue car la sélection des serveurs DNS doit être réalisé manuellement. Si un serveur DNS utilisé dans de la redirection conditionnelle disparait alors il faudra mettre impérativement à jour la règle de redirection en conséquence.

 

 

 

Tableau récapitulatif

 

Stockage

Avantages

Inconvénients

Zone DNS secondaire

  • Fichier à plat
  • Autonomie
  • Résolution DNS rapide
  • Maitrise des flux réseau
  • Volume de réplications
  • Configuration et maintenance sur chaque serveur

Zone de stub

  • Fichier à plat
  • Active Directory
  • Stockage depuis la base Active Directory
  • Utilisation des réplications Active Directory
  • Mise à jour dynamique des serveurs de noms
  • Maitrise des flux réseau

Redirecteur conditionnel

  • Configuration locale du serveur DNS
  • Active Directory
  • Stockage depuis la base Active Directory
  • Utilisation des réplications Active Directory
  • Maitrise des flux réseau
  • Mise à jour manuelle des serveurs maîtres

 


Vérifier les réplications Active Directory

Sommaire

Active Directory Replication Status Tool

Depuis quelques semaines, Microsoft nous propose un nouvel outil pour la surveillance des réplications Active Directory. Un digne remplaçant au fameux outil REPLMON (replication monitor), un peu plus « user friendly » que la commande « repadmin /showrepl * /csv ». L’outil est Active Directory Replication Status Tool.

Pour pouvoir l’utiliser, il suffit simplement de disposer du Framework .Net 4 et d’un poste intégré à un domaine Active Directory (seul Windows 2000 n’est pas supporté).

Lorsque vous lancez l’outil, vous avez la possibilité de surveiller les réplications au niveau de la forêt (Forest), d’un domaine spécifique (Domain), par le biais d’une découverte automatique (Select Targets) ou par un import (Load Exported Data Set). Il suffit de cliquer sur « Refresh Replication status » pour lancer l’analyse.

{gallery}53_REPLMON/01{/gallery}

 

 

 

 

 

 

 

 

 

Grâce à  Active Directory Replication Status Tool , vous avez la possibilité de vérifier rapidement que toutes les réplications sont opérationnelles  grâce à un code couleur clair et un filtrage rapide des résultats.

{gallery}53_REPLMON/02{/gallery}

 

 

 

 

 

 

 

Vous avez également la possibilité de pouvoir consulter rapidement la documentation Technet relative à la moindre erreur remontée par l’outil depuis l’onglet « Replication Status Viewer ».

{gallery}53_REPLMON/03{/gallery}

 

 

 

 

 

 

 

 

Autre point extrêmement intéressant est la possibilité de réaliser un export des données collectées dans le cadre d’une analyse hors-ligne ultérieure et de la réimporter à l’aide de l’option « Load Exported Data Set ».

{gallery}53_REPLMON/04{/gallery}

 

 

 

 

 

 

 


Automatiser la notification avec Repadmin

La commande « Repadmin /showrepl * /csv » perd un peu de sa substance avec ce nouvel outil. Nous pouvons toutefois continuer à nous appuyer dessus pour utiliser un script d’automatisation d’envoi de rapports. Cela vous permet de pouvoir surveiller de manière automatique et régulière les réplications Active Directory.

Le script que nous vous proposons permet de formater l’export réalisé à l’aide de la commande « repadmin /showrepl * /csv » au format HTML, avec un classement des résultats par statut (« Error », « Warning » ou « Success ») et d’envoyer le tout par message électronique.

{codecitation style= »brush:PowerShell »}

#========================================================================
# Created on:   24/08/2012
# Created by:   AUGAGNEUR Alexandre
# Filename:     Repadmin-ShowRepl-HTMLReports.ps1
#
# Description:    Generate HTML reports based on
#                « repadmin /showrepl * /csv » command return,
#                format it and send it by email
#========================================================================

###################################################
#        VARIABLES
###################################################

# Path of CSV/HTML exports
$ExportPath = « c:\temp »

# Path of Repadmin binary (only necessary if not found in $env:path)
$RepadminExec = $null

# Random name of CSV/HTML Export
$BaseFilename = « Repadmin-« +(Get-Date -Format yyMMdd)+ »-« +(Get-Random)
$CSVFilename = $BaseFilename+ ».csv »
$HTMLFilename = $BaseFilename+ ».html »

# CSV Headers
$Header = « showrepl_COLUMNS », »Destination DSA Site », »Destination DSA », »Naming Context », »Source DSA Site », »Source DSA », `
« Transport Type », »Number of Failures », »Last Failure Time », »Last Success Time », »Last Failure Status »

# HTML Style
$style = @ »
<style>
BODY{font-family: »Segoe UI »}
P{text-decoration:underline;text-indent:40px;font-size:20px;color:DarkSlateGray;font-weight:bold}
TABLE{border-width: 2px;border-style: solid;border-color: Black;border-collapse: collapse;}
TABLE.error{border-color:red}
TABLE.warning{border-color:darkorange}
TABLE.success{border-color:green}
TH{border-width: 2px;padding: 0px;border-style: solid;padding:5px}
TD{border-width: 1px;padding: 0px;border-style: solid;text-align:center}
TH.error{border-color:red;background-color:salmon}
TH.warning{border-color:darkorange;background-color:orange}
TH.success{border-color:green;background-color:limegreen}
TD.error{border-color: red}
TD.warning{border-color:darkorange}
TD.success{border-color:green}
</style>
« @

# Email notification parameters
$Sender = « sender.at.corpnet.net »
$Recipient = « recipient.at.corpnet.net » # You can specify an array if needed
$Server = « smtp.corpnet.net »

###################################################
#        FUNCTIONS
###################################################

function EmailNotification($Sender, $Recipient, $Server, $Subject, $Body)
{
$SMTPclient = new-object System.Net.Mail.SmtpClient $Server

# SMTP Port (if needed)
# $SMTPClient.port = 587

# Enabling SSL (if needed)
# $SMTPclient.EnableSsl = $true

# Specify authentication parameters (if needed)
# $SMTPAuthUsername = « login »
# $SMTPAuthPassword = « password »
# $SMTPClient.Credentials = New-Object System.Net.NetworkCredential($SMTPAuthUsername, $SMTPAuthPassword)

$Message = new-object System.Net.Mail.MailMessage
$Message.From = $Sender
$Recipient | %{ $Message.To.Add($_) }
$Message.Subject = $Subject
$Message.Body = $Body
$Message.IsBodyHtml = $true

$SMTPclient.Send($Message)
}

###################################################
#        MAIN
###################################################

# Construct CSV file full path
$CSVExport = Join-Path $ExportPath $CSVFilename

# Find repadmin binary if not defined
if ( !($RepadminExec) )
{
foreach ( $path in ($env:path).split(« ; ») )
{
if (Test-Path $path\repadmin.exe)
{
$RepadminExec = « $path\repadmin.exe »
}
}
}

if ( $RepadminExec )
{
# Command to generate replications status
$StrCmd = « $RepadminExec /showrepl * /csv »

# Generate CSV output
Invoke-Expression $StrCmd | Out-File $CSVExport

if ( Test-Path $CSVExport )
{
$ReplicationsState = Import-Csv -Path $CSVExport -Header $Header -Delimiter « , »

$ServersInError = @()
$ErrorContent = @()

# Filtering error messages
$ReplicationsState | Where-Object { $_. »showrepl_COLUMNS » -match « showrepl_ERROR » } | %{
if ($_.showrepl_COLUMNS -match « showrepl_ERROR ») {
$ServersInError += $_. »Destination DSA »
$ErrorContent += $_
}
}

# Format errors content
if ( $ErrorContent )
{
$MailObject= »AD REPLICATIONS STATUS – $(Get-Date -Format yy/MM/dd) – error(s) found »

$MailBody += $ErrorContent | Select-Object -Property « Destination DSA »,@{ Name= »Error Message »; Expression={ $_. »Naming Context » } } | ConvertTo-Html -As table -Fragment -PreContent « <p>AD Replications status with errors</p> » -PostContent « <br><br> » | Out-String
$MailBody = $MailBody.Replace(« <th> », »<therror » »> »)
$MailBody = $MailBody.Replace(« <td> », »<tderror » »> »)
$MailBody = $MailBody.Replace(« <table> », »<tableerror » »> »)
}

# Filtering warning messages
$WarningContent = $ReplicationsState | Where-Object {  @(« showrepl_ERROR », »showrepl_COLUMNS ») -notcontains $_. »showrepl_COLUMNS » -and $_. »Last Failure Status » -ne 0 }  

# Format warning content
if ( $WarningContent )
{
if (!$MailObject)
{
$MailObject= »AD REPLICATIONS STATUS – $(Get-Date -Format yy/MM/dd) – warning(s) found »
}

$MailBody += $WarningContent | Select-Object -ExcludeProperty « showrepl_COLUMNS », »Transport Type » -Property * | ConvertTo-Html -As table -Fragment -PreContent « <p>AD Replications status with warning</p> » -PostContent « <br><br> » | Out-String
$MailBody = $MailBody.Replace(« <th> », »<thwarning » »> »)
$MailBody = $MailBody.Replace(« <td> », »<tdwarning » »> »)
$MailBody = $MailBody.Replace(« <table> », »<tablewarning » »> »)
}

# Filtering success messages (uncomment the line if you want to see them in the email report)
# $SuccessContent = $ReplicationsState | Where-Object { @(« showrepl_ERROR », »showrepl_COLUMNS ») -notcontains $_. »showrepl_COLUMNS » -and $_. »Last Failure Status » -eq 0}

# Format success content
if ( $SuccessContent )
{
if (!$MailObject)
{
$MailObject= »AD REPLICATIONS STATUS – $(Get-Date -Format yy/MM/dd) – OK »
}

$MailBody += $SuccessContent | select-object -ExcludeProperty « showrepl_COLUMNS », »Transport Type » -Property * | ConvertTo-Html -As table -body « <p>AD Replications status with success</p> » -PreContent $style | Out-String
$MailBody = $MailBody.Replace(« <th> », »<thsuccess » »> »)
$MailBody = $MailBody.Replace(« <td> », »<tdsuccess » »> »)
$MailBody = $MailBody.Replace(« <table> », »<tablesuccess » »> »)
}

# Generate HTML file (if wanted)
# $HTMLExport = Join-Path $ExportPath $HTMLFilename
# ConvertTo-Html -Head $style -body $MailBody -Title $MailObject | Out-File $HTMLExport

if ( $MailBody )
{
EmailNotification $Sender $Recipient $Server $MailObject (ConvertTo-Html -Head $style -Body $MailBody -Title $MailObject | Out-String)
}
}
}

{/codecitation}

L’avantage avec ce type de solution est que vous pouvez être rapidement informé d’un problème de réplication de manière automatique. Ci-dessous, vous avez des exemples de rapports envoyés par message électronique.

{gallery}53_REPLMON/05{/gallery}

Polling interval of an Active Directory Integrated zone by the DNS Service

An Active Directory integrated zone is updated using Active Directory replication system. So basically, a new DNS record created on an Active Directory integrated zone is replicated immediately inside an Active Directory site (intra-site replication topology). The problem is that the DNS record won’t appear immediately on the DNS server even if the Active Directory database is up-to-date. In fact, the DNS server does not query directly the Active Directory database but just reloading the zone every 180 seconds from it.

To check the polling interval value of a DNS Server, you can check the parameter named “dwDsPollingInterval” with the command “dnscmd /info”.

{gallery}52_DNSUpdate/01{/gallery}

 

 

 

In first, if you need to poll immediately the last version of the zone, type the following to force a manual update “dnscmd /zoneupdatefromds <zone name>

{gallery}52_DNSUpdate/02{/gallery}

 

 

 

By the way, it is also possible to change this value (between 30 and 3600 seconds). To do it, you can use the dnscmd tool to change it by typing the following : dnscmd /config /dspollinginterval <value>. You can also do it by creating/modifying directly the DWORD registry key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\DsPollingInterval”.

{gallery}52_DNSUpdate/03{/gallery}

 

Réaliser une capture réseau à l’aide de Netsh et Network Monitor

Sommaire

 

 

Introduction

Par défaut, Windows 2008 R2 et Windows 7 sont dotés d’une fonctionnalité de capture réseau intégrée à l’utilitaire netsh. Cette nouveauté offre de nombreux avantages que nous  vous proposons de découvrir dans notre article.

 


Les points forts

netsh intègre donc désormais une fonctionnalité de capture de trames réseau dont voici les points forts :

  • Aucun prérequis d’installation: la fonctionnalité « trace » de netsh est disponible par défaut sur tout système Windows 7 ou Windows 2008 R2. Il devient plus confortable et plus simple d’initier une capture sur ces systèmes. Ci-dessous, vous avez un exemple d’une capture de base exécutée à l’aide de la commande « netsh trace start capture=yes » depuis l’invite de commande.

{gallery}50_CAPTURE_NETSH/01{/gallery}

 

 

 

 

Remarque: Le fichier de traces, au format ETL, devra être exploité par un outil tel que Network Monitor que nous présentons un peu plus loin.

  • Un mode persistant pour capturer dès le démarrage du système : il dispose d’un mode persistant qui permet de réaliser une capture au démarrage du poste. Cela peut s’avérer particulièrement intéressant lorsqu’il est nécessaire de capturer les communications initiées au démarrage (exemple: Active Directory, DHCP,…). La commande à saisir sera « netsh trace start capture=yes persistent=yes ».
  • Surveillance des processus et du trafic réseau : il ne se contente pas de la capture du trafic réseau. Il est également capable de tracer les évènements système et applicatifs. Pour cela, il s’appuie sur les évènements ETW (Event tracing for Windows). Du coup, il n’est plus nécessaire de collecter indépendamment les données de type système et réseau. De plus, en les couplant, cela simplifie le diagnostic et, de ce fait, d’accélérer la résolution des incidents.
  • Génération de rapports : il permet également de collecter toute une somme de rapports permettant d’identifier plus aisément le système cible. Entre autres, nous retrouvons le rapport d’application des stratégies de groupes (gpresult), les informations générales du système d’exploitation, l’ensemble des dossiers partagés… le tout consultable aisément via une page HTML et compilé dans un fichier CAB. Pour activer la génération des rapports, il faudra saisir la commande « netsh trace start capture=yes report=yes ».

{gallery}50_CAPTURE_NETSH/02{/gallery}

 

 

 

 

 

 

 

 


Réaliser une capture réseau

La capture réseau avec netsh trace se réalise simplement à l’aide de l’option « capture=yes » et, si nécessaire, avec l’option « report=yes » pour la génération de rapports. En clair, il suffit d’exécuter la commande « netsh trace start capture=yes report=yes » (précisez l’option « persistent=yes » si vous voulez que la capture ne s’interrompe pas durant le redémarrage du système).

{gallery}50_CAPTURE_NETSH/03{/gallery}

 

 

 

 

Notez que l’exécution de la capture se réalise en tâche de fond et que la commande se termine avec un récapitulatif de la configuration. A tout moment, Il est possible d’interroger à l’aide de la commande « netsh trace show status » l’état de la capture.

{gallery}50_CAPTURE_NETSH/04{/gallery}

 

 

 

 

 

 

 

Finalement, pour arrêter la capture, il faudra saisir la commande « netsh trace stop » qui lancera la compilation des données collectées dans un fichier ETL et la génération des différents rapports annexes dans un fichier CAB (contenant également le fichier ETL).

{gallery}50_CAPTURE_NETSH/05{/gallery}

 

 

 

 

 

 

Le fichier ETL devra être exploité directement via le logiciel Network Monitor de Microsoft.

 

 

 

Visualiser la capture depuis Network Monitor

La seconde étape consiste donc à installer Network Monitor de Microsoft afin de pouvoir visualiser le contenu de notre capture. Il est disponible depuis ce lien. L’idéal étant de l’installer directement sur votre poste et de rapatrier les fichiers de capture.

Une fois Network Monitor installé, il suffit d’ouvrir votre fichier ETL.

Lors de la première ouverture d’une des captures réalisées, vous obtiendrez le message d’erreur « NDIS_MicrosofWindowsNDISPacketCapture : Windows stub parser : Requires full Common parsers… » au sein de chaque trame et depuis le champ Description. Pour pallier à cela, sélectionnez  le menu « Options » depuis le menu « Tools » de la barre d’outils, allez dans l’onglet « Parser Profiles » et activez le profile « Windows ».

{gallery}50_CAPTURE_NETSH/06{/gallery}

 

 

 

 

 

 

 

 

 

 

Vous avez deux autres très bons exemples disponibles depuis Microsoft MSDN : http://msdn.microsoft.com/en-us/library/dd569140.aspx et http://msdn.microsoft.com/en-us/library/dd569141.aspx.

 

 

 

Filtrer les évènements système à l’aide des « providers »

Afin de limiter la capture des évènements système,  netsh exploite les fournisseurs (ou provider en anglais) de l’Event Tracing for Windows (voir notre section Annexe: Utilisation de « ETW » pour le filtrage des évènements système pour plus de détail). Il en existe des centaines à notre disposition, couvrant de manière exhaustive l’ensemble des composants du système.

Pour vous aider à trouver le bon fournisseur, vous pouvez utiliser la commande « netsh trace show providers | find « filtre » ». Par exemple, pour les fournisseurs associés à Active Directory, nous utiliserons la commande « netsh trace show providers | find « Active Directory » ».

{gallery}50_CAPTURE_NETSH/07{/gallery}

 

 

 

De ce fait, si vous désirez gérer un ou plusieurs fournisseurs dans une capture, vous pourrez utiliser l’option « provider={GUID} »  ou « provider=[NAME] » pour chaque fournisseur voulu. Par exemple, la commande « netsh trace start provider={BBA3ADD2-C229-4CDB-AE2B-57EB6966B0C4} provider={8E598056-8993-11D2-819E-0000F875A064} provider={F33959B4-DBEC-11D2-895B-00C04F79AB69} capture=yes » va nous permettre de capturer les fournisseurs relatifs à Active Directory.

{gallery}50_CAPTURE_NETSH/08{/gallery}

 

 

 

 

Chaque fournisseur peut disposer également de ses propres filtres (Keywords) et d’un niveau de verbosité (Levels). Il vous est possible de consulter les options possibles pour chaque fournisseur à l’aide de la commande « netsh trace show provider {Provider GUID | Name} ».

{gallery}50_CAPTURE_NETSH/09{/gallery}

 

 

 

 

 

 

Les niveaux de verbosité et certains filtres sont communs à la plus part des fournisseurs. Pour les consulter, il suffit de saisir la commande « netsh trace show globalKeywordsAndLevels ». Alors que les mots clés sont propres à chaque fournisseur donc nécessite d’être consulter spécifiquement pour chacun d’entre eux, les valeurs relatives pour le niveau de verbosité est le même pour tous. Cela permettra de limiter la taille des fichiers de capture et de cibler mieux l’information à capturer.

{gallery}50_CAPTURE_NETSH/10{/gallery}

 

 

 

 

 

 

Dans l’exemple ci-dessous, nous capturons le fournisseur « Windows Firewall Service » (provider={5EEFEBDB-E90C-423A-8ABF-0241E7C5B87D}) avec un niveau verbosité critique (level=1) et un filtre sur TL_ERROR et TL_WARN (keywords=0x1,0x2).

{gallery}50_CAPTURE_NETSH/11{/gallery}

 

 

 

 

 

 

 

Filtrer les évènements système et diagnostiquer à l’aide des scénarios

En complément des providers, nous avons également tout un ensemble de scénario afin de pouvoir capturer ou même diagnostiquer divers problèmes. Vous pouvez les lister à l’aide de la commande « netsh trace show scenarios ».

{gallery}50_CAPTURE_NETSH/12{/gallery}

 

 

 

 

 

 

 

 

Un  scénario regroupe un ensemble de fournisseurs que vous pouvez consulter à l’aide de la commande « netsh trace show scenario [NAME] ». Cette commande permet également d’obtenir des informations complémentaires sur le scénario concerné.

{gallery}50_CAPTURE_NETSH/13{/gallery}

 

 

 

 

 

 

 

L’utilisation des scénarios va nous permettre de capturer le trafic réseau plus simplement. Il suffit de saisir la commande suivante « netsh trace start scenario=FileSharing capture=yes » pour capturer les évènements relatifs au partage de fichiers plutôt que de rechercher les fournisseurs et les saisir.

{gallery}50_CAPTURE_NETSH/14{/gallery}

 

 

 

 

Les scénarios ont une autre utilité. Ils permettent le diagnostic.  Pour cela, nous passons dès lors par l’option « diagnose » de « netsh trace ». Par exemple, le scénario « FileSharing » va nous permettre d’évaluer les problèmes de partages réseau. Il suffit de saisir la commande suivante «  netsh trace diagnose scenario=FileSharing UNCPath=\\chemin capture=yes ».

{gallery}50_CAPTURE_NETSH/15{/gallery}

 

 

 

 

 

 

 

 

Réduire le nombre de trames à collecter à l’aide des filtres de capture

Pour compléter la panoplie de fournisseurs et de scénarios déjà à notre disposition, la fonctionnalité de capture dispose également de ses propres filtres. Par exemple, cela permettra de focaliser les captures de trames réseau sur un protocole particulier ou une adresse ip spécifique.

Pour en obtenir une liste exhaustive, il vous suffit de saisir la commande « netsh trace show capturefilterhelp ».

{gallery}50_CAPTURE_NETSH/16{/gallery}

 

 

 

 

 

 

En plus de fournir la liste de tous les paramètres, la commande capturefilterhelp fournir quelques exemples et vous guide dans l’usage des filtres de capture. Nous n’allons pas tous les détailler mais les filtres sont assez communs comme le filtre « ipv4.address » pour la capture d’une adresse ip spécifique ou « CaptureInterface » pour spécifier une interface réseau spécifique.

Dans l’exemple ci-dessous, nous réalisons une capture avec, comme interlocuteur spécifique, l’équipement disposant de l’adresse ip « 192.168.10.1 » depuis l’interface réseau « Connexion au réseau local ».

{gallery}50_CAPTURE_NETSH/17{/gallery}

 

 

 

 

 

 

Annexe: récapitulatif des options de « netsh trace »

Comme tout outil, « netsh trace » dispose de tout un ensemble de paramètres et comme ils ne sont pas si nombreux, nous allons vous les présenter.

Dans un premier temps, il est important de noter qu’il ne propose pas uniquement de la capture (option « start »). Vous pouvez obtenir la liste de ses fonctionnalités à l’aide de la commande « netsh trace help ». Nous trouvons entre autres, la fonction de diagnostic (option « diagnose ») ou  la fonction de conversion (option « convert ») permettant de convertir le fichier de capture en un format spécifique.

Bien entendu et dans le cadre de notre article, l’option la plus intéressante de « netsh trace » reste la capture dont voici les paramètres (tous optionnels) :

  • Scenario: préciser un ou plusieurs scénarios
  • globalKeywords: préciser un filtre global (liste des filtres disponibles à l’aide de la commande « netsh trace show globalKeywordsandLevel »)
  • globalLevel: préciser un niveau de verbosité global à tous les fournisseurs spécifiés
  • capture: activer la capture des trames réseau en plus des traces systèmes. Il faut donc impérativement le préciser!
  • report: activer la génération d’un rapport à la fin de la capture.
  • persistent: résumer une session de capture dans le cadre d’un redémarrage. Particulièrement intéressant si vous désirez réaliser une capture durant le démarrage de votre machine.
  • traceFile: préciser le chemin et le nom du fichier de capture.
  • maxSize: préciser la taille maximale du fichier de capture (250 Mo par défaut). La valeur 0 permet de ne pas fixer de limite.
  • fileMode: paramètre optionnel pour définir le type de rotation.
  • overwrite: préciser si le précédent fichier de capture est écrasé.
  • Correlation: préciser si les évènements de capture seront regroupés.
  • provider: préciser un ou plusieurs fournisseurs.
  • keywords: préciser un filtre spécifique à un fournisseur.
  • levels: préciser un niveau de verbosité spécifique à un fournisseur.

 

 

 

Annexe: Utilisation de « ETW » pour le filtrage des évènements système

Introduit depuis Windows 2000,  ETW (Event Tracing for Windows) est un ensemble de composants permettant de tracer toutes les opérations liées au système d’exploitation ou aux applications (pour plus de détail sur ETW, vous pouvez consulter l’article Event Tracing for Windows: Vu de l’intérieur.

ETW fonctionne sur un modèle de fournisseurs et d’abonnés. Les applications et les composants du système enregistrent leurs données sous la forme d’un « provider » qui pourront être récupérer par un « subscriber ». L’outil de souscription de prédilection était logman mais, depuis Windows 7 et Windows 2008 R2, il est supplanté par netsh. D’ailleurs, depuis une invite de commandes, les commandes « logman providers » ou « netsh trace show providers » vous retourneront exactement la même liste de fournisseurs.

Si vous désirez obtenir des sources complémentaires sur Netsh et ETW, nous vous conseillons de lire l’article Event Tracing for Windows and Network Monitor depuis le blog Technet dédié à Network Monitor. Vous pouvez également consulter un autre très bon article en français sur ETW extrait de MSDN Magazine Améliorez le débogage et l’optimisation des performances avec ETW.

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

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 ».

{gallery}49_DCLINKSPC/01{/gallery}

 

 

 

 

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] ».

{gallery}49_DCLINKSPC/02{/gallery}

 

 

 

 

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).

{gallery}49_DCLINKSPC/03{/gallery}

 

 

 

 

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.

{gallery}49_DCLINKSPC/04{/gallery}

 

 

 

 

 

 


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é.

{gallery}49_DCLINKSPC/05{/gallery}

 

 

 

 

 

 

 

 

 

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 ».

{gallery}49_DCLINKSPC/06{/gallery}

 

 

 

 

 

 

 

 

 

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 ».

{gallery}49_DCLINKSPC/07{/gallery}

 

 

 

 

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 ».

{gallery}49_DCLINKSPC/08{/gallery}