Lourd WAN et contrôleur de domaine l'utilisation du processeur lorsque vous effectuez des sauvegardes d'état du système

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 2789917

Cet article décrit comment sauvegardes d'état du système par les contrôleurs de domaine Active Directory de manière transitive mettre à jour les attributs de référence qui entraînent des clients Active Directory Service Interfaces (ADSI) Télécharger le schéma d'agrégation. Ce processus de téléchargement potentiellement augmente la charge sur les ordinateurs de rôle de contrôleur de domaine et du réseau sous-jacent.
Symptômes
Les problèmes suivants peuvent se produire lorsque vous effectuez la sauvegarde d'état système de la partition de schéma sur un contrôleur de domaine dans une forêt Active Directory :
  • Une meilleure utilisation du processeur sur les ordinateurs de rôle du contrôleur de domaine lorsque les attributs de référence de requête sur les ordinateurs Windows Active Directory qui sont utilisées aux fins suivantes :
    • Pour détecter les mises à jour le schéma d'agrégation
    • Pour copier le schéma d'agrégation à partir de contrôleurs de domaine si une modification est détectée.
  • Accroissement du trafic de Lightweight Directory Access Protocol (LDAP) sur le réseau lorsque les clients ADSI copiez le contenu du schéma global à partir des contrôleurs de domaine.
Cause
Ce problème se produit car l'attribut de Signature DSA est mis à jour sur le contexte de nommage de schéma (schema CN) lorsque vous effectuez une sauvegarde d'état système d'un contrôleur de domaine qui exécute Windows Server 2003 Service Pack 1 (SP1) ou une version ultérieure.

Lorsque l'attribut de Signature DSA est mis à jour par une sauvegarde d'état du système, les cachets de date sont mises à jour sur les deux attributs de référence. Un de ces attributs se trouve sur la tête du contexte de nommage de schéma, et l'autre se trouve sur le CN = Aggregate, CN = Schema objet.

Les clients Windows qui exécutent des scripts et des applications ADSI interrogent ces attributs de référence afin de détecter les mises à jour le schéma d'agrégation. Lorsqu'ils détectent ces mises à jour, les clients ADSI téléchargent une copie à jour du schéma d'agrégation à partir d'un contrôleur de domaine à travers un lecture de LDAP.

Remarque
pour plus d'informations sur la détection du schéma d'agrégation qui est lié aux requêtes LDAP et les e/s réseau, consultez la section « Informations complémentaires ».
Solutions de contournement
Une solution de contournement du côté serveur et côté client d'une solution de contournement fournissent une exonération partielle par réduction mais ne pas éliminer le nombre de fois que les clients ADSI téléchargent le schéma d'agrégation. Les solutions de contournement côté client et côté serveur peuvent être exécutées indépendamment un de l'autre. Cela signifie que vous pouvez implémenter la solution de contournement côté client uniquement, côté serveur ou encore les deux solutions de contournement en même temps.

Solution de contournement côté serveur



Modification de signature DSA

La solution de contournement du côté serveur se compose des sauvegardes d'état du système de la partition de schéma empêche la mise à jour de l'attribut deSignature DSA . L'attribut de Signature DSA contient un indicateur DRA_INHIBIT_BACKUP_AUTO_STAMP pour déterminer si une sauvegarde d'état système mis à jour cet attribut. Toutefois, étant donné que l'attribut de Signature DSA est stocké dans un format binaire de grande taille, il ne peut pas être changée facilement à l'aide d'un outil tel que LDP. EXE ou ADSIEDIT. MSC.

Pour contourner ce problème, exécutez un script Windows PowerShell ou un fichier exécutable qui empêche les sauvegardes d'état du système à partir de la mise à jour de l'attribut de Signature DSA sur la partition de schéma et, à son tour, l'attribut whenChanged sur la tête du contexte de nommage de schéma et le whenModified de l'attribut sur le CN = Aggregate objets.

Consultez le Modifier l'attribut de dSASignature Script PowerShell sur le site Microsoft Script Center.

Vous pouvez aussi compiler et exécuter l'exemple de code suivant pour définir ou effacer l'indicateur DRA_INHIBIT_BACKUP_AUTO_STAMP dans l'attribut de Signature DSA dans le contexte de nommage de schéma.

Qu'un PowerShell ou un correctif de programmation est utilisé, il existe un effet côté négatif de l'activation de l'indicateur DRA_INHIBIT_BACKUP_AUTO_STAMP . Cet effet secondaire est documenté dans la section « Informations complémentaires ».

Remarque Cet exemple de code doit être exécuté dans un contexte de sécurité d'admin de schéma sur un contrôleur de domaine.

S'assurer que les définitions sont à jour.

Enfin, assurez-vous que thatIPv4 et le sous-réseau IPv6, du site et sous-réseau-à-site définitions sont à jour dans votre forêt Active Directory et couvrent tous les sous-réseaux de votre entreprise dans toutes les forêts. Ceci permet de surethat les ordinateurs qui exécutent des applications ADSI qui interrogent et copie des versions mises à jour du schéma agrégation de le faire à partir de contrôleurs de domaine de site optimal. Pour plus d'informations sur la façon de configurer les paramètres du site, accédez au site Web Microsoft TechNet suivant :

Exemples de code

//+-------------------------------------------------------------------------////// File: dsasignaturemod.c//// This is a sample program for setting or clearing the// DRA_INHIBIT_BACKUP_AUTO_STAMP flag in the dSASignature// attribute on the schema NC.////--------------------------------------------------------------------------#include <windows.h>#include <winldap.h>#include <winber.h>#include <strsafe.h>#include <stdio.h>#include <conio.h>#define CHECKLDAP(result, op) if (result) { printf("%s failed with LDAP error=0x%x(%d)\n", op, result, result); goto Exit; }#define CHECKLDAPLE(result, op) if (!result) { printf("%s failed with LDAP error=0x%x(%d)\n", op, LdapGetLastError(), LdapGetLastError()); goto Exit; }//// Type definitions for the dsaSignature attribute//#define DRA_INHIBIT_BACKUP_AUTO_STAMP (0x1)typedef struct _BACKUP_NC_HEAD_DSA_SIGNATURE_STATE_V1 {DWORD dwFlags;LONGLONG BackupErrorLatencySecs;UUID dsaGuid;} BACKUP_NC_HEAD_DSA_SIGNATURE_STATE_V1;typedef struct _BACKUP_NC_HEAD_DSA_SIGNATURE_STATE {DWORD dwVersion;DWORD cbSize;union{BACKUP_NC_HEAD_DSA_SIGNATURE_STATE_V1 V1;};} BACKUP_NC_HEAD_DSA_SIGNATURE_STATE;// Whether we are setting or clearing the bitBOOL gfSet = FALSE;// Whether we are querying the bitBOOL gfGet = FALSE;// Whether we are automating and want to skip PromptForOK()BOOL skipPrompt = FALSE;// Copy of the schema NC DNLPWSTR pszSchemaNCCopy = NULL;BOOL PromptForOK(){int prompt;BOOL ret = skipPrompt;printf("\n");printf("This program is about to %s the DRA_INHIBIT_BACKUP_AUTO_STAMP flag in\n", gfSet ? "set" : "clear");printf("the dSASignature attribute on the following directory NC:\n");printf("\n");printf(" %S\n", pszSchemaNCCopy);printf("\n");if (!skipPrompt) {printf("Do you wish to continue? (Y\\N)");prompt = _getch();printf("\n");ret = (prompt == 'Y' || prompt == 'y') ? TRUE : FALSE;}return ret;}void Usage(){CHAR szExeName[MAX_PATH];ZeroMemory(szExeName, sizeof(szExeName));GetModuleFileNameA(NULL, szExeName, ARRAYSIZE(szExeName));printf("Usage:\n");printf("\n");printf("%s [/get | /set | /clear] [/auto]\n", szExeName);printf("\n");printf(" /get - queries current state of the DRA_INHIBIT_BACKUP_AUTO_STAMP flag\n");printf(" /set - sets the DRA_INHIBIT_BACKUP_AUTO_STAMP flag\n");printf(" /clear - clears the DRA_INHIBIT_BACKUP_AUTO_STAMP flag\n");printf(" /auto - skips the prompt for proceeding (for automation purposes)\n");printf("\n");}BOOL ParseArgs(int argc, __in char ** argv){BOOL ret = FALSE;if (argc >= 2){if (!_stricmp("/get", argv[1])) {gfGet = TRUE;ret = TRUE;}else if (!_stricmp("/set", argv[1])) {gfSet = TRUE;ret = TRUE;}else if (!_stricmp("/clear", argv[1])) {gfSet = FALSE;ret = TRUE;}if (argc >= 3){if (!_stricmp("/auto", argv[2])) {skipPrompt = TRUE;}}}return ret;} void __cdecl main(int argc, __in char ** argv){BOOL fFoundDSASignature = FALSE;BOOL fFlagSet = FALSE;LDAP* ldap = NULL;ULONG cb = 0;ULONG cch = 0;ULONG result = 0;LPWSTR pszAttrs[2] = { 0 };LPWSTR* ppszSchemaNC = NULL;LDAPMod mod;LDAPMod* mods[2];LDAPMessage* pldapMsg = NULL;LDAPMessage* pldapResults = NULL;struct berval valMod;struct berval* vals[2];struct berval** val = NULL;BACKUP_NC_HEAD_DSA_SIGNATURE_STATE dsaSignature;ZeroMemory(&dsaSignature, sizeof(dsaSignature));if (!ParseArgs(argc, argv)) {Usage();return;}printf("\n");//// Init connection handle//ldap = ldap_init(NULL, LDAP_PORT);CHECKLDAPLE(ldap, "ldap_init");//// Connect to DC//result = ldap_connect(ldap, NULL);CHECKLDAP(result, "ldap_connect");//// Retrieve schema NC name//pszAttrs[0] = L"schemaNamingContext";pszAttrs[1] = NULL;result = ldap_search_sW(ldap,NULL,LDAP_SCOPE_BASE,L"(objectclass=*)",pszAttrs,0,&pldapResults);CHECKLDAP(result, "ldap_search_s for schemaNamingContext");pldapMsg = ldap_first_entry(ldap, pldapResults);CHECKLDAPLE(pldapMsg, "ldap_first_entry");//// Make a copy of the schema NC name//ppszSchemaNC = (LPWSTR*)ldap_get_valuesW(ldap, pldapMsg, L"schemaNamingContext");cch = wcslen(ppszSchemaNC[0]) + 1;pszSchemaNCCopy = (LPWSTR)malloc(cch * sizeof(WCHAR));StringCchCopy(pszSchemaNCCopy, cch, ppszSchemaNC[0]);ldap_value_free(ppszSchemaNC);ppszSchemaNC = NULL;ldap_msgfree(pldapResults);pldapResults = NULL;//// Bind to the DC//result = ldap_bind_s(ldap, pszSchemaNCCopy, NULL, LDAP_AUTH_NEGOTIATE);CHECKLDAP(result, "ldap_bind_s");//// Retrieve current value of the dSASignature attribute//pszAttrs[0] = L"dSASignature";pszAttrs[1] = NULL;result = ldap_search_sW(ldap,pszSchemaNCCopy,LDAP_SCOPE_BASE,L"(objectclass=*)",pszAttrs,0,&pldapResults);CHECKLDAP(result, "ldap_search_s for dSASignature");pldapMsg = ldap_first_entry(ldap, pldapResults);CHECKLDAPLE(pldapMsg, "ldap_first_entry");//// Make a copy of the dSASignature attribute.//val = (struct berval**)ldap_get_values_len(ldap, pldapMsg, L"dSASignature");// Make sure that the value was there and seems to be the correct size.if (val && val[0]) {if (val[0]->bv_len == sizeof(BACKUP_NC_HEAD_DSA_SIGNATURE_STATE)) {memcpy(&dsaSignature, val[0]->bv_val, val[0]->bv_len);fFoundDSASignature = TRUE;}}ldap_value_free_len(val);val = NULL;ldap_msgfree(pldapResults);pldapResults = NULL;//// Sanity check//if (!fFoundDSASignature ||dsaSignature.dwVersion != 1) {printf("The dSASignature attribute was either not\n");printf("found or was in an unexpected format.\n");goto Exit;}//// Cache whether the flag is set already or not//fFlagSet = (DRA_INHIBIT_BACKUP_AUTO_STAMP & dsaSignature.V1.dwFlags) ? TRUE : FALSE;//// If query-only mode, display current setting and leave//if (gfGet) {printf("The target directory %s have the DRA_INHIBIT_BACKUP_AUTO_STAMP set.\n",fFlagSet ? "DOES" : "DOES NOT");goto Exit;}//// If doing a modification, see whether there is anything to do.//if (gfSet && fFlagSet) {printf("The /set operation was specified but the target directory already\n");printf(" has the flag set. Exiting with no changes.\n");goto Exit;}else if (!gfSet && !fFlagSet) {printf("The /clear operation was specified but the target directory already\n");printf(" has the flag cleared. Exiting with no changes.\n");goto Exit;}//// Yes there is work to do; prompt the admin// for approval before you continue.//if (!PromptForOK()) {goto Exit;}//// Set or clear the bit in our local copy//if (gfSet) {dsaSignature.V1.dwFlags |= DRA_INHIBIT_BACKUP_AUTO_STAMP;}else {dsaSignature.V1.dwFlags &= (~DRA_INHIBIT_BACKUP_AUTO_STAMP);}//// Prepare for the modify//ZeroMemory(&valMod, sizeof(valMod));valMod.bv_len = sizeof(dsaSignature);valMod.bv_val = (PCHAR)&dsaSignature;vals[0] = &valMod;vals[1] = NULL;ZeroMemory(&mod, sizeof(mod));mod.mod_op = LDAP_MOD_REPLACE | LDAP_MOD_BVALUES;mod.mod_type = L"dSASignature";mod.mod_vals.modv_bvals = vals;mods[0] = &mod;mods[1] = NULL;//// And do it://result = ldap_modify_s(ldap,pszSchemaNCCopy,mods);CHECKLDAP(result, "ldap_modify_s for dSASignature");printf("\n");printf("Modification succeeded!\n");Exit:if (pszSchemaNCCopy) {free(pszSchemaNCCopy);}if (ldap) {ldap_unbind(ldap);}printf("\n");return;}

Exemple de sortie de programme

Les sorties de programme exemple sont les suivantes :
C:\>dsasignaturemod.exe /get The target directory DOES NOT have the DRA_INHIBIT_BACKUP_AUTO_STAMP set.
C:\>dsasignaturemod.exe /set  This program is about to set the DRA_INHIBIT_BACKUP_AUTO_STAMP flag inthe dSASignature attribute on the following directory NC:     CN=Schema,CN=Configuration,DC=rootdomain,DC=com Do you wish to continue? (Y\N) Modification succeeded!
C:\>dsasignaturemod.exe /set /auto  This program is about to set the DRA_INHIBIT_BACKUP_AUTO_STAMP flag inthe dSASignature attribute on the following directory NC:     CN=Schema,CN=Configuration,DC=rootdomain,DC=com  Modification succeeded!
C:\>dsasignaturemod.exe /get The target directory DOES have the DRA_INHIBIT_BACKUP_AUTO_STAMP set.
C:\>dsasignaturemod.exe /clear  This program is about to clear the DRA_INHIBIT_BACKUP_AUTO_STAMP flag inthe dSASignature attribute on the following directory NC:     CN=Schema,CN=Configuration,DC=rootdomain,DC=com Do you wish to continue? (Y\N) Modification succeeded!
C:\>dsasignaturemod.exe /clear /auto  This program is about to clear the DRA_INHIBIT_BACKUP_AUTO_STAMP flag inthe dSASignature attribute on the following directory NC:     CN=Schema,CN=Configuration,DC=rootdomain,DC=com  Modification succeeded!

Solution de contournement côté client

Optimisation de la sélection du contrôleur de domaine

Certaines applications explicitement se connectent à un contrôleur de domaine avant de téléchargent le cache du schéma mis à jour à partir de ce contrôleur de domaine. Toutefois, les applications généralement laissent du localisateur de contrôleur de domaine pour trouver le meilleur contrôleur de domaine pour un certain contexte d'attribution de noms LDAP. Les clients peuvent rencontrer un retard dans la mise à jour du cache de schéma, car elles ciblent des contrôleurs de domaine sur une connexion réseau lente. Cela est susceptible de se produire entre les frontières de forêts. Votre objectif doit être toujours télécharger le cache du schéma du contrôleur de domaine le plus proche en termes de réseau.

Solution de contournement

La solution de contournement du côté client consiste à configurer les ordinateurs qui exécutent Windows Vista, Windows Server 2008 ou une version ultérieure pour utiliser un magasin par ordinateur basé sur le schéma d'agrégation.

Sur les ordinateurs Windows XP, le cache du schéma d'agrégation utilisé une banque par ordinateur. Cela signifie que le téléchargement du schéma agrégation a été partagé entre tous les utilisateurs qui ont une session sur l'ordinateur local, tant que les deux utilisateurs ont des droits d'administration ou les magasins locaux dans le système de fichiers et le Registre ont des autorisations en écriture pour les utilisateurs authentifiés. Dans le cas contraire, le cache du schéma a dû être téléchargées dans la mémoire RAM durant chaque session d'ADSI et a été ignoré après la fin de la session ADSI.

Sur Windows Vista et versions ultérieures, le cache du schéma ADSI est implémenté dans une banque d'informations par l'utilisateur. Bien que la sécurité est améliorée avec le cache par utilisateur, chaque utilisateur unique qui se connecte à un protocole RDP (Remote Desktop) ou Terminal Server AQ, kiosque ou autre système multi-utilisateur peut provoquer le même ordinateur pour télécharger le cache du schéma ADSI.

Vous pouvez forcer un secours à la configuration de la banque d'informations par ordinateur sur les ordinateurs qui exécutent Windows Vista et les versions ultérieures en définissant le les REG DWORD dans le chemin d'accès du Registre HKLM\SYSTEM\CurrentControlSet\Services\ADSI\Cache à une valeur de 1. En outre, vous devez accorder un accès en écriture sur %systemroot%\SchCache et HKLM\Software\Microsoft\ADs\Providers\LDAP pour les utilisateurs authentifiés. Pour plus d'informations, reportez-vous à la section. ADSI et le contrôle de compte d'utilisateur.

Remarque : L'utilisation de la banque « par ordinateur » est particulièrement utile dans les scénarios dans lesquels un profil d'utilisateur itinérant est supprimé lorsque l'utilisateur ferme la session. Ces utilisateurs doivent créer un nouveau profil itinérant et doivent peut-être télécharger le schéma d'agrégation. Scénarios spécifiques qui provoquent la suppression d'un profil itinérant sont les suivants :
  • Utilisateurs qui sont configurés pour se connecter à l'aide de profils d'utilisateurs obligatoires.
  • Utilisateurs qui sont soumis à la stratégie "Supprimer les profils utilisateur plus anciens qu'un nombre spécifié de jours, au démarrage du système".
  • Utilisateurs qui sont soumis à la stratégie "Supprimer les copies mises en cache des profils itinérants".
  • Un utilisateur dont le profil mis en cache a été supprimé par un script ou un outil tel que DELPROF. EXE ou un équivalent.
Plus d'informations

Informations sur ADSI

Un client ADSI est une implémentation d'un programme qui accède à Active Directory afin de se conformer à l'objet COM (Component Model).

Les ordinateurs Windows qui exécutent des scripts et des applications ADSI mettre à jour une copie locale du schéma Active Directory agrégation. Au début de chaque session de client ADSI, l'attribut de schéma de référence est vérifiée pour que les modifications. Car aucun attribut explicite dans Active Directory n'identifie toutes les modifications possibles pour le schéma Active Directory, des attributs de proxy sont utilisés pour déterminer quand les ordinateurs basés sur Windows doivent copier une copie à jour du schéma global sur le réseau à partir d'un contrôleur de domaine dans le domaine du client respectifs. Voici quelques exemples d'applications ADSI :
  • Le composant logiciel enfichable Active Directory Administrative Center Management Console MMC (Microsoft)
  • Le composant logiciel enfichable MMC Active Directory domaines et approbations
  • Le composant logiciel enfichable MMC Active Directory Sites et Services
  • Le composant logiciel enfichable MMC Active Directory utilisateurs et ordinateurs
  • Le composant logiciel enfichable MMC ADSI Edit
  • Le composant logiciel enfichable MMC DHCP
  • Le composant logiciel enfichable MMC Gestionnaire DNS
  • Console de gestion Exchange
  • Composant logiciel enfichable MMC Gestion de stratégie groupe
  • Squery.exe

Attributs qui sont utilisés pour détecter les modifications apportées au schéma de regroupement

Le tableau suivant fournit une vue d'ensemble des attributs qui sont utilisés pour détecter les modifications de schéma agrégé pour chaque version de Windows :

Version du système d'exploitation client ADSICondition pour le téléchargement du cache du schéma ADSI
Windows XP
Windows Server 2003
Windows Server 2003 R2
Windows Vista / Windows Server 2008
Windows 7 / Windows Server 2008 R2
Mise à jour de l'attribut modifyTimeStamp sur l'objet schéma d'agrégation
Windows 8 / Windows Server 2012
Windows 8.1 / Windows Server 2012 R2
Mise à jour de l'attribut whenChanged
Si une modification est détectée sur l'un de ces attributs de proxy, le client ADSI télécharge une copie du schéma agrégé.

Les ordinateurs qui exécutent les systèmes d'exploitation antérieurs à Windows 8 ou Windows Server 2012 interrogent l'attribut modifyTimeStamp sur le schéma d'agrégation. Le modifyTimeStamp a été mis à jour par le redémarrage du service Active Directory afin que le redémarrage d'un contrôleur de domaine ou le redémarrage du service Active Directory a causé quelques clients ADSI télécharger le cache du schéma d'agrégation à partir d'un contrôleur de domaine lorsque aucune modification de schéma autorisées se n'était produit. Cela était inférieure d'un problème dès le départ, car Active Directory est devenu un service de redémarrage de Windows Server 2008.

Les ordinateurs qui exécutent Windows 8, Windows Server 2012 ou une version ultérieure de l'attribut whenChanged sur la tête du contexte de nommage de schéma requête. L'attribut whenChanged a pour effet secondaire de la mise à jour lorsqu'une sauvegarde d'état du système met à jour l'attribut de Signature DSA dans le contexte de nommage de schéma. À son tour, il met à jour l'horodatage de l'attribut whenChanged de la tête du contexte de nommage de schéma.

Événements qui mettent à jour les attributs du proxy global de schéma sur un contrôleur de domaine

Le tableau suivant fournit une vue d'ensemble des attributs de référence sont mis à jour en fonction de la version du système d'exploitation et les opérations qui déclencheront des mises à jour de l'attribut.

Version système d'exploitation du contrôleur de domaineCondition de mise à jour de l'attribut de schéma d'agrégation modifyTimeStampCondition de mise à jour de l'attribut de schéma whenChanged
Windows Server 2003
Windows Server 2003 R2
Windows Server 2008
Windows Server 2008 R2
Contrôleur de domaine ou le démarrage du Service d'annuaire NT (NTDS) Extension de schéma / système de sauvegarde de l'état
Windows Server 2008 R2 avec Ko 2671874
Windows Server 2012
Windows Server 2012 R2
Extension de schéma / système de sauvegarde de l'étatExtension de schéma / système de sauvegarde de l'état
Si une modification est détectée, le cache du schéma ADSI doit être téléchargée. Une sauvegarde d'état système écrit des données dans l'attribut de Signature DSA du contexte de nommage de schéma qui se traduit par un cachet de temps whenChanged de mise à jour du schéma.

Détection des mises à jour du cache de schéma agrégé par les clients ADSI

Pour détecter les élevée du processeur et l'utilisation du réseau, utilisez le 3.4 le Moniteur réseau outil permettant de capturer l'utilisation du réseau et puis procédez comme suit pour analyser les résultats :
  1. Utilisez un des filtres suivants dans l'outil, en fonction du système d'exploitation Windows.

    Remarque De ces filtres, remplacez la chaîne "CN = Schema, CN = Configuration, DC = Contoso, DC = com » par le chemin de nom unique (DN) de l'Active Directory schema contexte de nommage en question.
    Windows 7 et les clients antérieurs
    Utilisez le filtre d'affichage suivant pour interroger la valeur de l'attribut modifyTimeStamp sur l'objet de schéma agrégé dans le trafic réseau capturée :
    (LDAPMessage.SearchRequest.BaseObject.OctetStream == "CN=Aggregate,CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchRequest.Attributes.Attribute.OctetStream == "modifyTimeStamp") OR(LDAPMessage.SearchResultEntry.ObjectName.OctetStream == "CN=Aggregate,CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchResultEntry.Attributes.PartialAttribute.Type.OctetStream == "modifyTimeStamp")
    Windows 8 clients et versions ultérieures

    Utilisez le filtre d'affichage suivant pour interroger la valeur de l'attribut whenChanged sur le schéma tête NC dans le trafic réseau capturée :
    (LDAPMessage.SearchRequest.BaseObject.OctetStream == "CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchRequest.Attributes.Attribute.OctetStream == "whenChanged") OR (LDAPMessage.SearchResultEntry.ObjectName.OctetStream == "CN=Schema,CN=Configuration,DC=Contoso,DC=com" AND LDAPMessage.SearchResultEntry.Attributes.PartialAttribute.Type.OctetStream == "whenChanged")
    Par défaut, cette valeur est comparée avec la valeur de temps dans le Registre du client dans la clé suivante :

    HKEY_CURRENT_USER\Software\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=<root domain>,DC=com

    Le client télécharge un cache de schéma mis à jour si la durée de l'attribut modifyTimeStamp ou whenChanged est ultérieure à la valeur qui est stockée dans le Registre. (Cet attribut dépend du système d'exploitation client.)

    Voici une capture d'écran de l'outil :

    Cette capture d'écran est un exemple que si le temps dans l'attribut modifyTimeStamp ou whenChanged est ultérieur à la valeur qui est stockée dans le Registre

    À partir de la capture d'écran, vous pouvez voir les éléments suivants :
    • Le client ADSI se lie au contrôleur de domaine dans le nom d'image 8.
    • La recherche LDAP de l'attribut proxy modifié de schéma est stockée dans un des premiers cadres LDAPSASLBuffer qui suivent la liaison.
    • Le trafic LDAP est crypté dans plusieurs trames LDAPSASLBuffer (cibler le port sur le contrôleur de domaine = TCP 389).
    • Le contrôleur de domaine continue à envoyer des données cryptées supplémentaires sur plusieurs trames TCP qui ont une longueur de charge utile de TCP de 1460.
  2. Une fois que vous avez identifier la conversation correcte dans la trace réseau qui présente ce problème, vous pouvez filtrer sur le port TCP utilisé par le client. Dans l'exemple, la conversation est lancée à partir du client sur le port TCP 65237. Un filtre d'analyseur de réseau tels que « tcp.port == 65237 » peut être utilisé pour isoler des trames connexes.
  3. Si vous copiez toutes les images dans cette conversation et la coller dans Microsoft Excel, vous voyez que la copie de schéma de regroupement par défaut a une taille de charge utile de TCP de 2 mégaoctets (Mo) de données sur le câble. La taille du fichier de schéma d'agrégation par défaut est environ 4 Mo après le codage.

Corrélation entre le trafic réseau vers le processus côté client

Vous pouvez utiliser le Moniteur système (Sysmon) pour déterminer le processus sur le client qui a lancé cette conversation. ID d'événement 3 est enregistré dans le journal des événements Microsoft-Windows-Moniteur système opération lorsque le Moniteur système est installé et configuré pour enregistrer les connexions LDAP. Cela vous permet d'associer le trafic réseau à un processus côté client car il enregistre l'adresse IP source et port ainsi que le nom de l'Image et ProcessID.


Nom du journal : Microsoft-Windows-Moniteur système opérationnels
Source : Microsoft-Windows-Moniteur système
Date : Date
ID de l'événement: 3
Catégorie de tâche : Réseau de connexion détectée (règle : réseauMe connecter)
Niveau : informations
Mots clés :
Utilisateur : système
Ordinateur : Ordinateur
Description :
Détecté d'une connexion réseau :
Numéro de séquence : 206
UtcTime : UtcTime
ProcessGuid: {ProcessGuid}
ProcessId : 3220
Image : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Utilisateur : Nom d'utilisateur
Protocole : tcp
Initié : true
SourceIsIpv6 : false
SourceIp : SourceIp
SourceHostname : ADSIClient
PortSource : 65237
SourcePortName :
DestinationIsIpv6 : false
DestinationIp : DestinationIp
DestinationHostname : DestinationHostname
DestinationPort : 389
DestinationPortName : ldap
Xml de l'événement :

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider name="Microsoft-Windows-Sysmon" guid=""></Provider></System></Event>"{Nom du fournisseur}" />
<EventID>3</EventID>
<Version>4</Version>
<Level>4</Level>
<Task>3</Task>
<Opcode>0</Opcode>
<Keywords>0 x 8000000000000000</Keywords>
<TimeCreated SystemTime=" systemtime=""></TimeCreated SystemTime=">Heure" />
<EventRecordID>39</EventRecordID>
<Correlation></Correlation>
<Execution processid="1140" threadid="3492"></Execution>
<Channel>Microsoft-Windows-Moniteur système opérationnels</Channel>
<>r >Ordinateur
<Security UserID=" userid=""></Security UserID=">ID utilisateur" />

<EventData>
<Data name="SequenceNumber">206</Data>
<Data name="UtcTime"></Data></EventData>Heure
<Data name="ProcessGuid">{</Data>ProcessGuid}
<Data name="ProcessId">3220</Data>
<Data name="Image">C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Data>
<Data name="User"></Data>Utilisateur
<Data name="Protocol">TCP</Data>
<Data name="Initiated">true</Data>
<Data name="SourceIsIpv6">false</Data>
<Data name="SourceIp"></Data>SourceIp
<Data name="SourceHostname"></Data>SourceHostname
<Data name="SourcePort">65237</Data>
<Data name="SourcePortName">
</Data>
<Data name="DestinationIsIpv6">false</Data>
<Data name="DestinationIp"></Data>DestinationIp
<Data name="DestinationHostname"></Data>DestinationHostname
<Data name="DestinationPort">389</Data>
<Data name="DestinationPortName">LDAP</Data>

Moniteur de processus d'ouverture de session du client

Moniteur de processus d'ouverture de session du client fournit des informations contextuelles riches. Filtrer le journal de moniteur de traitement sur l'ID de processus qui est consigné dans les événements enregistrés par le Moniteur système.

Le journal de moniteur de traitement sur l'ID de processus enregistré dans les événements enregistrés par le Moniteur système des filtres de la capture d'écran

Vous trouverez les opérations suivantes d'intérêt.
OpérationChemin d'accès
RegOpenKeyHKLM\SYSTEM\CurrentControlSet\Services\ADSI\Cache
RegQueryValueHKCU\Software\Microsoft\ADs\Providers\LDAP\CN = Aggregate, CN = Schema, CN = Configuration, DC =domaine enfant, DC =domaine racine, DC = com\Time
De réception TCPNom d'hôte>: Port-> <DCName> </DCName>: LDAP
RegCreateKeyHKCU\SOFTWARE\Microsoft\ADs\Providers\LDAP\CN = Aggregate, CN = Schema, CN = Configuration, DC =domaine enfant, DC =domaine racine, DC = com
WriteFileC:\Users\<username>\AppData\Local\Microsoft\Windows\SchCache\</username>domaine enfant.domaine racine. com.sch
Remarque Une pour vérifier si les ordinateurs basés sur Windows sont mise à jour de la copie locale du cache du schéma d'agrégation consiste à surveiller les modifications de l'horodatage du fichier *.sch dans le système de fichiers local du client ADSI.

Vous pouvez utiliser les données dans le tableau ci-dessous pour affiner votre filtre de très grands journaux de Process Monitor.

Filtres supplémentaires facultatives :
ColonneRelationValeur
Chemin d'accèsContientSchCache
OpérationEstWriteFile
La capture d'écran est le processus Moniteur de filtre

Configuration du Moniteur système pour enregistrer les connexions LDAP

  1. Télécharger Moniteur système sur le client.
  2. Créez un fichier texte pour la configuration du Moniteur système, enregistrez le fichier sous Sysmonconfig.xml et ajoutez le contenu suivant :

    <Sysmon schemaversion="2.0">  <!-- Capture all hashes -->  <HashAlgorithms>*</HashAlgorithms>  <EventFiltering>  <!-- Log all drivers except if the signature -->  <!-- contains Microsoft or Windows -->  <DriverLoad onmatch="exclude">  <Signature condition="contains">microsoft</Signature>  <Signature condition="contains">windows</Signature>  </DriverLoad>  <!-- Do not log process termination -->  <ProcessTerminate onmatch="include" />  <!-- Log network connection if the destination port equal 443 -->  <NetworkConnect onmatch="include">  <DestinationPort>389</DestinationPort><DestinationPort>636</DestinationPort><DestinationPort>3268</DestinationPort><DestinationPort>3269</DestinationPort>  </NetworkConnect>  </EventFiltering></Sysmon>
  3. Exécutez la commande suivante pour installer le Moniteur système :
    Moniteur système i - sysmonconfig.xml

Effet de l'activation de l'indicateur DRA_INHIBIT_BACKUP_AUTO_STAMP

Un effet secondaire de l'activation de l'indicateur DRA_INHIBIT_BACKUP_AUTO_STAMP est l'événement QU'ID 2089 incorrectement indique que la partition de schéma n'est pas capturée dans les forêts qui sont création de sauvegardes d'état du système.

Exemple d'événement ID 2089 semblable au suivant est enregistré dans le journal d'Application :


Type d'événement : avertissement
Source de l'événement : La réplication NTDS
Catégorie d'événement : sauvegarde
L'ID d'événement : 2089
Date : date
Heure : heure
Utilisateur : nom d'utilisateur
Ordinateur : nom de l'ordinateur
Description :

Cette partition de l'annuaire n'a pas été sauvegardée depuis au moins le nombre de jours suivant.

Partition d'annuaire :

CN = schema, DC = la partition d'application dns forêt racine

Remarque L'ID d'événement 2089 n'est pas connecté comme pour d'autres partitions de clé CN = Configuration ou de la partition de l'annuaire du domaine, car il n'y a aucune méthode pour effectuer des sauvegardes spécifiques à la partition. Pour plus d'informations, consultez l'article suivant de la Base de connaissances Microsoft :
914034 L'événement de réplication NTDS 2089 est consigné si Windows Server 2003 SP1 et les contrôleurs de domaine de version ultérieure ne sont pas sauvegardés dans un laps de temps donné

Avertissement : Cet article a été traduit automatiquement.

خصائص

رقم الموضوع: 2789917 - آخر مراجعة: 07/28/2015 15:52:00 - المراجعة: 3.0

Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard, Windows Server 2012 R2 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 Essentials, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Standard

  • kbexpertiseadvanced kbsurveynew kbbug kbprb kbtshoot kbmt KB2789917 KbMtfr
تعليقات