Recherche d'événements dans ADSI
Windows Server 2008 et Windows Vista introduisent le suivi des événements dans les interfaces de service Active Directory (ADSI). Certains domaines du fournisseur LDAP ADSI ont une implémentation sous-jacente qui est complexe ou qui implique une séquence d'étapes qui rend difficile le diagnostic des problèmes. Pour aider les développeurs d'applications à résoudre les problèmes, le suivi des événements a été ajouté aux domaines suivants :
L'interface des DAI dans ADSI exige que le schéma LDAP soit mis en cache sur le client afin que les attributs puissent être marshallés correctement (comme décrit dans le modèle de schéma ADSI). Pour ce faire, ADSI charge le schéma de chaque processus (et de chaque serveur/domaine LDAP) en mémoire, soit à partir d'un fichier de schéma (.sch) enregistré sur le disque local, soit en le téléchargeant à partir du serveur LDAP. Différents processus sur la même machine cliente utilisent le schéma mis en cache sur le disque s'il est disponible et applicable.
Si le schéma ne peut être obtenu à partir du disque ou du serveur, ADSI utilise un schéma par défaut codé en dur. Dans ce cas, les attributs qui ne font pas partie de ce schéma par défaut ne peuvent pas être mis en cache et ADSI renvoie une erreur lors de la récupération de ces attributs. Un certain nombre de facteurs peuvent être à l'origine de cette situation, notamment des problèmes d'analyse du schéma et des privilèges insuffisants pour télécharger le schéma. Il est souvent difficile de déterminer pourquoi un certain schéma par défaut est utilisé. L'utilisation du suivi des événements dans ce domaine permet de diagnostiquer plus rapidement le problème et de le résoudre.
ChangePassword et SetPassword utilisent plusieurs mécanismes pour exécuter la requête en fonction de la configuration disponible (comme décrit dans la section Définition et modification des mots de passe des utilisateurs avec le fournisseur LDAP). Lorsque ChangePassword et SetPassword échouent, il peut être difficile d'en déterminer la raison exacte. Le suivi des événements vous aidera à résoudre les problèmes liés à ces méthodes.
ADSI essaie en interne de réutiliser les connexions LDAP dans la mesure du possible (voir Mise en cache des connexions). Lors du dépannage, il est utile de savoir si une nouvelle connexion a été ouverte pour communiquer avec le serveur ou si une connexion existante a été utilisée. Il peut également être utile de suivre le cycle de vie du cache de connexion (parfois appelé cache de liaison) et sa création ou sa fermeture, et de savoir si un renvoi de connexion a eu lieu. Dans le cas d'une liaison sans serveur, ADSI appelle le localisateur de DC pour sélectionner un serveur pour le domaine du contexte de l'utilisateur. ADSI conserve ensuite un cache du mappage domaine-serveur pour les connexions ultérieures. Le traçage des événements permet de retracer la sélection du DC, et est donc utile pour dépanner les problèmes liés à la connexion.
Pour activer le traçage ADSI, créez la clé de registre suivante :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\ProcessName
ProcessName est le nom complet du processus que vous souhaitez suivre, y compris son extension (par exemple, « Svchost.exe »). En outre, vous pouvez placer dans cette clé une valeur facultative de type DWORD nommée PID. Il est fortement recommandé de définir cette valeur afin de ne tracer qu'un processus particulier. Sinon, toutes les instances de l'application spécifiée par ProcessName seront tracées.
Exécutez ensuite la commande suivante :
tracelog.exe -start sessionname **-guid #**provider_guid -f filename -flag traceFlags -level traceLevel
sessionname est simplement un identifiant arbitraire utilisé pour étiqueter la session de traçage (vous devrez vous référer à ce nom de session plus tard lorsque vous arrêterez la session de traçage). Le GUID du fournisseur de suivi ADSI est « 7288c9f8-d63c-4932-a345-89d6b060174d ». filename spécifie le fichier journal dans lequel les événements seront écrits. traceFlags doit être l'une des valeurs suivantes :
Indicateur | Valeur |
---|---|
DEBUG_SCHEMA |
0x00000001 |
DEBUG_CHANGEPWD |
0x00000002 |
DEBUG_SETPWD |
0x00000004 |
DEBUG_BINDCACHE |
0x00000008 |
Ces indicateurs déterminent les méthodes ADSI qui seront suivies, conformément au tableau suivant :
Indicateur | Method |
---|---|
DEBUG_SCHEMA |
|
DEBUG_CHANGEPWD |
|
DEBUG_SETPWD |
|
DEBUG_BINDCACHE |
|
Vous pouvez combiner des indicateurs en combinant les bits appropriés dans l'argument traceFlags. Par exemple, pour spécifier les indicateurs DEBUG_SCHEMA et DEBUG_BINDCACHE, la valeur appropriée de traceFlags serait 0x00000009.
Enfin, l'indicateur traceLevel doit prendre l'une des valeurs suivantes :
Indicateur | Valeur |
---|---|
TRACE_LEVEL_ERROR |
0x00000002 |
TRACE_LEVEL_INFORMATION |
0x00000004 |
TRACE_LEVEL_INFORMATION permet au processus de traçage d'enregistrer tous les événements, tandis que TRACE_LEVEL_ERROR permet au processus de traçage d'enregistrer uniquement les événements d'erreur.
Pour mettre fin au suivi, exécutez la commande suivante :
tracelog.exe -stop nom_de_la_session
Dans l'exemple précédent, sessionname est le même nom que celui qui a été fourni avec la commande qui a démarré la section de traçage.
Il est plus efficace de suivre uniquement des processus spécifiques en spécifiant un PID particulier que de suivre tous les processus d'un ordinateur. Si vous devez tracer plusieurs applications sur la même machine, il peut y avoir un impact sur les performances ; il y a une sortie de débogage substantielle dans les sections du code axées sur les performances. En outre, les administrateurs doivent veiller à définir correctement les permissions des fichiers journaux lors du suivi de plusieurs processus ; dans le cas contraire, n'importe quel utilisateur pourrait être en mesure de lire les journaux de suivi, et d'autres utilisateurs seraient en mesure de suivre les processus contenant des informations sécurisées.
Par exemple, supposons que l'administrateur configure le suivi d'une application « Test.exe » et qu'il ne spécifie pas de PID dans le registre pour le suivi de plusieurs instances du processus. Un autre utilisateur souhaite maintenant tracer l'application « Secure.exe ». Si les fichiers journaux de traçage ne sont pas correctement restreints, il suffit à cet utilisateur de renommer « Secure.exe » en « Test.exe » pour que l'application soit tracée. En général, il est préférable de ne tracer que des processus spécifiques lors du dépannage et de supprimer la clé de registre de traçage dès que le dépannage est terminé.
Étant donné que l'activation du suivi des événements génère des fichiers journaux supplémentaires, les administrateurs doivent surveiller attentivement la taille des fichiers journaux ; le manque d'espace disque sur l'ordinateur local peut entraîner un déni de service.
Scénario 1 : l'administrateur constate une erreur inattendue dans une application qui définit des mots de passe pour des comptes d'utilisateurs ; il doit donc prendre les mesures suivantes pour résoudre le problème à l'aide du suivi des événements.
Rédigez un script qui reproduit le problème et créez la clé de registre.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe
Démarrez une session de traçage, en définissant traceFlags sur 0x2 (DEBUG_CHANGEPASSWD) et traceLevel sur 0x4 (TRACE_LEVEL_INFORMATION), à l'aide de la commande suivante :
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
Exécutez cscript.exe avec leur script de test pour reproduire le problème, puis mettez fin à la session de traçage :
tracelog.exe -stop scripttrace
Supprimez la clé de registre
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe
Exécutez l'outil ETW Tracerpt.exe pour analyser les informations de traçage du journal :
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
Scénario 2 : L'administrateur souhaite tracer les opérations d'analyse et de téléchargement du schéma dans une application ASP nommée w3wp.exe qui est déjà en cours d'exécution. Pour ce faire, l'administrateur procède comme suit :
Créez la clé de registre
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe
et à l'intérieur de cette clé, créer une valeur de type DWORD nommée PID et la définir sur l'ID du processus de l'instance de w3wp.exe actuellement en cours d'exécution sur l'ordinateur local.
Ils créent ensuite une session de traçage, en définissant traceFlags sur 0x1 (DEBUG_SCHEMA) et traceLevel sur 0x4 (TRACE_LEVEL_INFORMATION) :
tracelog.exe -start w3wptrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\w3wp.etl -flag 0x1 -level 0x4
Reproduisez l'opération qui nécessite un dépannage.
Mettez fin à la session de traçage :
tracelog.exe -stop w3wptrace
Supprimez la clé de registre HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe.
Exécutez l'outil ETW tracerpt.exe pour analyser les informations de traçage du journal :
tracerpt.exe .\w3wp.etl -o -report