Traccia eventi in ADSI

Windows Server 2008 e Windows Vista introducono Event Tracing in Active Directory Service Interfaces (ADSI). Alcune aree del provider LDAP ADSI hanno un'implementazione sottostante complessa o che implica una sequenza di passaggi che rende difficile diagnosticare i problemi. Per aiutare gli sviluppatori di applicazioni a risolvere i problemi, Event Tracing è stato aggiunto alle aree seguenti:

Analisi e download dello schema

L'interfaccia IAD in ADSI richiede che lo schema LDAP venga memorizzato nella cache nel client in modo che gli attributi possano essere sottoposto a marshalling correttamente (come descritto nel modello di schema ADSI). A tale scopo, ADSI carica lo schema per ogni processo (e per ogni server/dominio LDAP) in memoria da un file di schema (sch) salvato sul disco locale o scaricandolo dal server LDAP. Processi diversi nello stesso computer client usano lo schema memorizzato nella cache su disco, se disponibile e applicabile.

Se non è possibile ottenere lo schema dal disco o dal server, ADSI usa uno schema predefinito hardcoded. In questo caso, gli attributi che non fanno parte di questo schema predefinito non possono essere sottoposto a marshalling e ADSI restituisce un errore durante il recupero di questi attributi. Un certo numero di fattori può causare questo problema, inclusi i problemi nell'analisi dello schema e privilegi insufficienti per scaricare lo schema. Spesso è difficile determinare il motivo per cui viene usato un determinato schema predefinito. L'uso di Traccia eventi in questa area consentirà di diagnosticare più rapidamente il problema e risolverlo.

Modifica e impostazione della password

ChangePassword e SetPassword usano più di un meccanismo per eseguire l'operazione richiesta in base alla configurazione disponibile, come descritto in Impostazione e modifica delle password utente con il provider LDAP. Quando ChangePassword e SetPassword hanno esito negativo, può essere difficile determinare esattamente perché e Event Tracing aiuterà a risolvere i problemi con questi metodi.

Cache di associazione ADSI

ADSI tenta internamente di riutilizzare le connessioni LDAP quando possibile (vedere Memorizzazione nella cache delle connessioni). Durante la risoluzione dei problemi, è utile tracciare se è stata aperta una nuova connessione per la comunicazione con il server o se è stata usata una connessione esistente. Può anche essere utile per tracciare il ciclo di vita della cache di connessione (talvolta definita cache di associazione) e la relativa creazione o chiusura e se è stata eseguita una segnalazione di connessione. Nel caso di un'associazione serverless, ADSI chiama il localizzatore di controller di dominio per selezionare un server per il dominio del contesto dell'utente. ADSI mantiene quindi una cache del mapping del server di dominio per le connessioni successive. Event Tracing consente di tracciare la selezione del controller di dominio ed è quindi utile per la risoluzione dei problemi relativi alla connessione.

Abilitazione della traccia e avvio di una sessione di traccia

Per attivare la traccia ADSI, creare la chiave del Registro di sistema seguente:

\HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\adsi\Tracing\ProcessName

ProcessName è il nome completo del processo che si vuole tracciare, inclusa l'estensione , ad esempio "Svchost.exe"). Inoltre, è possibile inserire un valore facoltativo di tipo DWORD denominato PID in questa chiave. È consigliabile impostare questo valore e tracciare solo un processo specifico. In caso contrario, verranno tracciate tutte le istanze dell'applicazione specificata da ProcessName .

Eseguire quindi il comando seguente:

tracelog.exe -start sessionname **-guid #**provider_guid -f filename -flag traceFlags -level traceLevel

sessionname è semplicemente un identificatore arbitrario usato per etichettare la sessione di traccia. Sarà necessario fare riferimento a questo nome di sessione in un secondo momento quando si arresta la sessione di traccia. Il GUID per il provider di rilevamento ADSI è "7288c9f8-d63c-4932-a345-89d6b060174d". filename specifica il file di log in cui verranno scritti gli eventi. traceFlags deve essere uno dei valori seguenti:

Flag Valore
DEBUG_SCHEMA
0x00000001
DEBUG_CHANGEPWD
0x00000002
DEBUG_SETPWD
0x00000004
DEBUG_BINDCACHE
0x00000008

Questi flag determinano quali metodi ADSI verranno tracciati, in base alla tabella seguente:

Flag metodo
DEBUG_SCHEMA
  • LdapGetSchema
  • GetSchemaInfoTime
  • LdapReadSchemaInfoFromServer
  • ProcessSchemaInfo
  • HelperReadLdapSchemaInfo
  • ProcessClassInfoArray
  • ReadSchemaInfoFromRegistry
  • StoreSchemaInfoFromRegistry
  • AttributeTypeDescription
  • ObjectClassDescription
  • DITContentRuleDescription
  • DirectoryString
  • DirectoryStrings
  • DITContentRuleDescription

DEBUG_CHANGEPWD
  • CADsUser::ChangePassword

DEBUG_SETPWD
  • CADsUser::SetPassword

DEBUG_BINDCACHE
  • GetServerBasedObject
  • GetServerLessBasedObject
  • GetGCDomainName
  • GetDefaultDomainName
  • GetUserDomainFlatName
  • BindCacheLookup
  • EquivalentPortNumbers
  • CanCredentialsBeReused
  • BindCacheAdd
  • BindCacheAddRef
  • AddReferralLink
  • CommonRemoveEntry
  • BindCacheDerefHelper
  • NotifyNewConnection
  • QueryForConnection
  • LdapOpenBindWithCredentials
  • LdapOpenBindWithDefaultCredentials

È possibile combinare i flag combinando i bit appropriati nell'argomento traceFlags . Ad esempio, per specificare i flag DEBUG_SCHEMA e DEBUG_BINDCACHE, il valore traceFlags appropriato sarà 0x00000009.

Infine, il flag traceLevel deve essere uno dei valori seguenti:

Flag Valore
TRACE_LEVEL_ERROR
0x00000002
TRACE_LEVEL_INFORMATION
0x00000004

TRACE_LEVEL_INFORMATION fa sì che il processo di traccia registri tutti gli eventi, mentre TRACE_LEVEL_ERROR fa sì che il processo di traccia registri solo gli eventi di errore.

Per terminare la traccia, eseguire il comando seguente:

tracelog.exe -stop sessionname

Nell'esempio precedente, sessionname è lo stesso nome di quello fornito con il comando che ha avviato la sezione di traccia.

Osservazioni:

È più efficace tracciare solo processi specifici specificando un particolare PID rispetto a tracciare tutti i processi in un computer. Se è necessario tracciare più applicazioni nello stesso computer, potrebbe verificarsi un impatto sulle prestazioni; è presente un output di debug sostanziale nelle sezioni orientate alle prestazioni del codice. Inoltre, gli amministratori devono prestare attenzione a impostare correttamente le autorizzazioni dei file di log durante la traccia di più processi; in caso contrario, qualsiasi utente potrebbe essere in grado di leggere i log di traccia e altri utenti potranno tracciare i processi che contengono informazioni sicure.

Si supponga, ad esempio, che l'amministratore imposti la traccia per un'applicazione "Test.exe" e non specifichi un PID nel Registro di sistema per tracciare più istanze del processo. Ora un altro utente vuole tracciare l'applicazione "Secure.exe". Se i file di log di traccia non sono limitati correttamente, tutto ciò che l'utente deve eseguire è rinominare "Secure.exe" in "Test.exe" e verrà tracciato. In generale, è consigliabile tracciare solo processi specifici durante la risoluzione dei problemi e rimuovere la chiave del Registro di sistema di traccia non appena viene eseguita la risoluzione dei problemi.

Poiché l'abilitazione di Event Tracing produrrà file di log aggiuntivi, gli amministratori devono monitorare attentamente le dimensioni dei file di log; la mancanza di spazio su disco nel computer locale può causare un denial of service.

Scenari di esempio

Scenario 1: l'amministratore rileva un errore imprevisto in un'applicazione che imposta le password per gli account utente, quindi esegue i passaggi seguenti per risolvere il problema usando Event Tracing.

  1. Scrivere uno script che riproduce il problema e creare la chiave del Registro di sistema

    \HKEY_LOCAL_MACHINE system\CurrentControlSet\Services\adsi\Tracing cscript.exe\

  2. Avviare una sessione di traccia, impostando traceFlags su 0x2 (DEBUG_CHANGEPASSWD) e traceLevel su 0x4 (TRACE_LEVEL_INFORMATION), usando il comando seguente:

    tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b06060174d -f .\adsi.etl -flag 0x2 -level 0x4

  3. Eseguire cscript.exe con il relativo script di test per riprodurre il problema e quindi terminare la sessione di traccia:

    tracelog.exe -stop scripttrace

  4. Eliminare la chiave del Registro di sistema

    \HKEY_LOCAL_MACHINE system\CurrentControlSet\Services\adsi\Tracing cscript.exe\

  5. Eseguire lo strumento ETW Tracerpt.exe per analizzare le informazioni di traccia dal log:

    tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b06060174d -f .\adsi.etl -flag 0x2 -level 0x4

Scenario 2: l'amministratore vuole tracciare le operazioni di analisi e download dello schema in un'applicazione ASP denominata w3wp.exe già in esecuzione. A tale scopo, l'amministratore eseguirà i passaggi seguenti:

  1. Creare la chiave del Registro di sistema

    \HKEY_LOCAL_MACHINE System\CurrentControlSet\Services\adsi\Tracing w3wp.exe\

    e all'interno di tale chiave creare un valore di tipo DWORD denominato PID e impostarlo sull'ID processo dell'istanza di w3wp.exe attualmente in esecuzione nel computer locale.

  2. Quindi creano una sessione di traccia, impostando traceFlags su 0x1 (DEBUG_SCHEMA) e traceLevel su 0x4 (TRACE_LEVEL_INFORMATION):

    tracelog.exe -start w3wptrace -guid #7288c9f8-d63c-4932-a345-89d6b06060174d -f .\w3wp.etl -flag 0x1 -level 0x4

  3. Riprodurre l'operazione necessaria per la risoluzione dei problemi.

  4. Terminare la sessione di traccia:

    tracelog.exe -stop w3wptrace

  5. Eliminare la chiave del Registro di sistema HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\adsi\Tracing\w3wp.exe.

  6. Eseguire lo strumento ETW tracerpt.exe per analizzare le informazioni di traccia dal log:

    tracerpt.exe .\w3wp.etl -o -report