Migrations de Domaine et de DC : comment surveiller le trafic LDAP, Kerberos et NTLM sur vos contrôleurs de domaine
Bonjour tout le monde, ici Stéphane Gonzalez pour une traduction d'un article d'Adrian Corona.
L'article original se trouve ici : https://blogs.technet.com/b/askpfeplat/archive/2013/12/16/domain-and-dc-migrations-how-to-monitor-ldap-kerberos-and-ntlm-traffic-to-your-domain-controllers.aspx
Cette fois-ci, je voudrais parler d'un scénario sur lequel j’ai beaucoup de questions : la migrations de domaine / contrôleur de domaine.
Un élément très (si ce n’est le plus) important d'une migration réussie est de savoir s’il y a un système ou une application qui utilise encore les services de votre domaine avant la mise hors service de votre domaine / contrôleur de domaine.
Habituellement les services informatiques auront la visibilité des applications les plus importantes dans l'environnement ainsi que de toutes les configurations spécifiques (adresses IPs codées en dur, noms de serveur, etc.). Toutefois, il est très fréquent d'avoir des services "pas-aussi-important" utilisant l’AD et ne pas avoir de documentation (ou même connaissance) à leur sujet. Il est aussi très courant de n’avoir aucune documentation pour des services importants :).
La question la plus commune que je reçois de clients est: « Comment puis-je surveiller s’il y a des applications qui utilisent encore mon domaine? »
Cette question s'étend sur beaucoup de scénarios tels que la migration de domaine, la consolidation ou par simple curiosité.
Peut-être voulez-vous écrire la documentation manquante.
Sérieusement, faites-le, s'il vous plaît !
Quel que soit votre scénario, il est très important de savoir quels systèmes utilisent vos contrôleurs de domaine et pourquoi.
Un ensemble de collecteurs de données ou data collector set, est un composant qui exploite et regroupe différentes sources d'information de performance dans une seule vue.
Un ensemble de collecteurs de données peut être créé puis enregistré individuellement, regroupé avec d'autres ensembles de collecteurs de données et incorporé dans les journaux, vu dans l'analyseur de performances, configuré pour générer des alertes lorsque des seuils sont atteints, ou utilisés par d'autres applications non Microsoft.
En d'autres termes : génial !
Je n’irai pas dans les détails sur le fonctionnement des Data Collector Set, mais je vais vous montrer comment les utiliser pour obtenir des informations AD clés sur vos contrôleurs de domaine.
Nous pourrons profiter des avantages du tracing ETW qui est très puissant, vous pouvez vous renseigner à ce sujet ici.
Remarque: pour que cela fonctionne correctement, vous devrez exécuter cette partie du processus à partir d'un contrôleur de domaine.
Dans cet exemple, j'utilise un contrôleur de domaine 2012 R2 mais le processus doit être la même pour 2008 et 2008 R2. Malheureusement ce processus ne s'applique pas aux contrôleurs de domaine 2003 sur lesquels vous pouvez utiliser SPA et obtenir des informations similaires mais de toutes façons vous allez vous débarrasser de ces vieux DCs 2K3, n’est-ce pas ?
Les ensembles de collecteurs de données sont très utiles, il y a des collecteurs intégrés et le reporting est détaillé.
Par exemple, je peux commencer le collecteur de diagnostics intégré Active Directory et il s’exécutera pendant 5 minutes (si vous voulez changer ça, vous aurez besoin de créer votre propre DCS)
Une fois la collecte terminée, vous pouvez voir ces rapports impressionnants qui vous montreront des informations très importantes sur les performances de votre contrôleur de domaine.
Cela semble magnifique mais le seul problème est que ces rapports sont limités à un nombre maximum de résultats, toutefois les données des traces ETW sont là donc il doit y avoir un moyen d'en profiter... nous allons voir comment.
Tout d'abord commencer par démarrer l'analyseur de performances ou performance Monitor :
Développez Data Collector Set :
Faites un clic droit User Defined – New – Data Collector Set
Tapez le nom que vous voulez ajouter en tant que Data Collector Set, sélectionnez create manually (advanced) et cliquez sur Next :
Sélectionnez Event Trace data :
Sur les Event Providers (fournisseurs d'événements), cliquez sur Add.. et sélectionnez les providers suivants :
- Active directory Domain Services : Core
- Active Directory : Kerberos KDC
- NTLM Security Protocol
Remarque : il existe de nombreux autres providers disponible, vous pouvez personnaliser votre suivi avec tout ce que vous voulez inclure, gardez juste à l'esprit que plus vous ajouterez de providers plus votre fichier sera volumineux.
Cliquez sur Next, sélectionnez le chemin d'accès où vous souhaitez enregistrer le fichier et cliquez sur Finish.
Sur la console Perfmon faire un clic droit sur votre Data Collector Set nouvellement créé et sélectionnez Properties :
Dans cette fenêtre, vous pouvez configurer plusieurs options, mais nous nous intéressons à la condition d'arrêt qui indique à votre système la durée de la collecte d'informations.
ATTENTION : La trace ETW croît très rapidement dans un système fortement utilisé, 5 minutes de trace consomme ~ 100 Mo d’espace disque donc soyez prudent par rapport à l’emplacement où que vous placez ce fichier. De plus, vous souhaiterez exécuter ce processus lorsqu'il y aura le plus d'activité utilisateur afin d’avoir un échantillon représentatif.
Dans notre cas, je vais exécuter mon test pendant 1 heure :
Après avoir créé votre collecteur, sélectionnez-le et cliquez sur Démarrer dans la barre d'outils :
Une fois les données collectées, vous aurez un fichier nommé datacollector01.etl, si vous essayez de l’ouvrir vous ne verrez que du brouillage car ce fichier est au format binaire.
Alors que pouvons-nous faire pour le lire ?
Ne vous inquiétez pas, « Après un certain temps, vous ne verrez même plus le code ».
Si vous n'êtes pas aussi avancé que Cypher dans ce cas vous pouvez toujours utiliser tracerpt pour convertir ces fichiers en fichier CSV lisible et convenable pour un humain.
Pour cela, ouvrez une invite de commande élevée sur le contrôleur de domaine et exécutez la commande suivante :
Tracerpt – l « file.etl » –of CSV
Si vous exécutez cette commande sur une autre machine, les providers ne sont peut-être pas disponibles et les événements de décodage seront incomplets.
Lorsque le processus est terminé, vous aurez 2 fichiers :
- Summary.csv – vous pouvez utiliser ce fichier pour valider que tous les providers ont été trouvés : il suffit pour cela de vérifier que toutes les lignes sur la colonne eventname sont remplies. Si vous avez une ou plusieurs lignes vides, le système que vous avez utilisé n'a pas les providers corrects (ce qui ne devrait pas se produire si vous l’exécutez sur le contrôleur de domaine car il les a tous)
- Dumpfile.csv : ce fichier contient des informations lisibles par un être humain (vraiment ??)
Pas de panique, vous pouvez ouvrir ce fichier avec Excel et vous verrez un document bien formaté qui permet de filtrer et de trier comme il vous plaît ...
Mais ce n'est pas pratique si je dois revoir tous mes contrôleurs de domaine manuellement.
Par conséquent une macro simple, créée par un collègue PFE, Adrian Corona, vous permet de traiter ce fichier et vous donner un format plus agréable (cette macro peut traiter un seul fichier à la fois), la seule chose que vous devez faire est de suivre ces étapes :
Télécharger le document import-DC-Info.xlsm joint en bas de ce post. Il fonctionne avec Excel 2010 et 2013.
Placez le document dans le même dossier que le fichier dumpfile.csv
Ouvrez le fichier et si nécessaire activez les macros.
Cliquez sur Importer un fichier (import files).
Asseyez-vous et détendez-vous.
Une fois ce processus exécuté, vous aurez un fichier excel appelé DCInfo.xlsx avec quelques onglets et les tableaux croisés dynamiques créés :
LDAP
Il contient une liste de toutes les requêtes LDAP exécutées sur votre DC avec une liste d'adresses IPs (avec doublons supprimés), la combinaison IP: port et aussi la requête exécutée. Avec cela vous pouvez voir qui demande quelles infos, et à partir de quelle IP cette requête était originaire.
Kerberos-Pivot
Il s'agit d'un tableau croisé dynamique peuplé depuis l'onglet Kerberos qui est trié par le nombre total d'accès à un service particulier. Ce tableau est utile pour avoir un rapide coup d’œil sur les services qui s’authentifient toujours sur le DC en Kerberos. Pour obtenir cette information j'ai filtré et nettoyé les requêtes TGS-Start, j'ai exclu les demandes AS puisqu'ils pourraient potentiellement augmenter le nombre de résultats et nous ne gagnerions pas beaucoup d'informations supplémentaire en les incluant.
Kerberos
Ce tableau est une synthèse (et doublons supprimés) listant toutes les demandes TGS faites, vous allez utiliser cet onglet si vous voulez voir plus en détail depuis le tableau croisé dynamique, plus précisément la colonne utilisateur (User) vous montrera le compte utilisateur/ordinateur/service réel qui demande un service tandis que la colonne de service indique quel service est requis. Prenons par exemple la ligne suivante :
FabrikamDC3 est un contrôleur de domaine qui demande un ticket Kerberos pour accéder à un partage de fichiers sur fabrikamdc (probablement le contenu Sysvol)
NTLM-Pivot
Ce tableau est très similaire à Kerberos-Pivot, il vous donnera le nombre total de demandes NTLMValidateUser en cours depuis les clients vers des services.
NTLM
Une liste complète de chaque requête NTLMValidateUser , semblable à l'onglet Kerberos.
Comme je l'ai expliqué plus tôt, ce processus doit être effectué de tous vos contrôleurs de domaine de préférence au cours de la même fenêtre de temps, ainsi vous aurez des demandes d'authentification et requêtes enregistrées uniques. Si vous vous enregistrez des informations de contrôleurs de domaine différents à des moments différents, vous pourriez obtenir des informations du même client sur différents contrôleurs de domaine, et par conséquent des informations dupliquées.
Si vos fichiers csv exportés ne sont pas très grands, une suggestion est de manuellement consolider toutes les données exportées dans un csv unique... Mais attention au fait qu'un énorme fichier peut consommer beaucoup de mémoire et prendra plus de temps à être traité. Si le temps n'est pas nécessairement une préoccupation, allez-y !
La macro n'a pas beaucoup de contrôle d’erreur mais elle fonctionnera si elle est utilisée conformément aux instructions. La bonne nouvelle est que même si vous n'utilisez pas la macro, vous avez toujours des informations qui peuvent être exploitées de la manière que vous préférez.
Restez à l’écoute.
Stéphane Gonzalez
Traduit à partir de : https://blogs.technet.com/b/askpfeplat/archive/2013/12/16/domain-and-dc-migrations-how-to-monitor-ldap-kerberos-and-ntlm-traffic-to-your-domain-controllers.aspx