Polling per le modifiche tramite il controllo DirSync
Il controllo di sincronizzazione di Active Directory (DirSync) è un'estensione server LDAP che consente a un'applicazione di cercare in una partizione di directory gli oggetti modificati dopo uno stato precedente.
Usare il controllo DirSync tramite ADSI specificando la preferenza di ricerca ADS_edizione StandardARCHPREF_DIRSYNC quando si usa IDirectorySearch. Per altre informazioni e un esempio di codice, vedere Esempio di codice con ADS_edizione StandardARCHPREF_DIRSYNC. È anche possibile eseguire una ricerca DirSync usando l'API LDAP. Di seguito viene descritta l'implementazione di ADSI, la maggior parte delle quali si applica anche all'uso diretto di LDAP, ad eccezione di quanto descritto alla fine di questo argomento.
Quando si esegue una ricerca DirSync, si passa un elemento dati specifico del provider (cookie) che identifica lo stato della directory al momento della ricerca DirSync precedente. Per la prima ricerca, si passa un cookie Null e la ricerca restituisce tutti gli oggetti che corrispondono al filtro. La ricerca restituisce anche un cookie valido. Archiviare il cookie nella stessa risorsa di archiviazione sincronizzata con il server Active Directory. Nelle ricerche successive ottenere il cookie dall'archiviazione e passarlo con la richiesta di ricerca. I risultati della ricerca includono ora solo gli oggetti e gli attributi modificati dopo lo stato precedente identificato dal cookie. La ricerca restituisce anche un nuovo cookie da archiviare per la ricerca successiva.
Nella tabella seguente sono elencati i parametri di ricerca che la richiesta di ricerca client può specificare.
| Parametro | Descrizione |
|---|---|
| Base della ricerca | La base di una ricerca DirSync deve essere la radice di una partizione di directory, che può essere una partizione di dominio, la partizione di configurazione o la partizione dello schema. |
| Ambito | L'ambito di una ricerca DirSync deve essere ADS_SCOPE_SUBTRedizione Enterprise, ovvero l'intero sottoalbero della partizione. Tenere presente che per una ricerca di una partizione di dominio, il sottoalbero include le teste, ma non il contenuto, delle partizioni di configurazione e schema. Per eseguire il polling delle modifiche in un ambito più piccolo, usare la tecnica USNChanged anziché DirSync. |
| Filtro | È possibile specificare qualsiasi filtro di ricerca valido. Per una ricerca iniziale con un cookie Null, i risultati includono tutti gli oggetti che corrispondono al filtro. Per le ricerche successive con un cookie valido, i risultati della ricerca includono solo i dati per gli oggetti che corrispondono al filtro e sono stati modificati dopo lo stato indicato dal cookie. Per altre informazioni sui filtri di ricerca, vedere Creazione di un filtro di query. |
| Attributi | È possibile specificare un elenco di attributi da restituire quando si verifica una modifica. Per ogni oggetto, i risultati iniziali includono tutti gli attributi richiesti impostati nell'oggetto . I risultati della ricerca successivi includono solo gli attributi specificati che sono stati modificati. Gli attributi non modificati non sono inclusi nei risultati della ricerca. Nell'implementazione di ADSI i risultati della ricerca includono sempre objectGUID e instanceType di ogni oggetto. Inoltre, l'elenco di attributi specificato funge da filtro aggiuntivo: i risultati della ricerca iniziale includono solo gli oggetti con almeno uno degli attributi specificati impostati; Le ricerche successive includono solo gli oggetti in cui uno o più attributi sono stati modificati (valori aggiunti o eliminati). |
Tenere presente anche che:
Per le ricerche incrementali, la procedura consigliata consiste nell'eseguire l'associazione allo stesso controller di dominio usato nella ricerca precedente, ovvero il controller di dominio che ha generato il cookie. Se lo stesso controller di dominio non è disponibile, attendere fino a quando non è o associarlo a un nuovo controller di dominio ed eseguire una sincronizzazione completa. Archiviare il nome DNS del controller di dominio nella risorsa di archiviazione secondaria con il cookie.
È possibile passare un cookie generato da un controller di dominio a un controller di dominio diverso che ospita una replica della stessa partizione di directory. Non è possibile che un client manchi le modifiche usando un cookie da un controller di dominio in un altro controller di dominio. Tuttavia, è possibile che i risultati della ricerca del nuovo controller di dominio includano le modifiche segnalate dal vecchio controller di dominio; in alcuni casi, il nuovo controller di dominio può restituire tutti gli oggetti e gli attributi, come con una sincronizzazione completa. Il client deve semplicemente rendere il database coerente con i risultati della ricerca segnalati per una determinata chiamata DirSync, ovvero gestire tutti i risultati incrementali come se fossero lo stato più recente. Non importa se si è visto la modifica prima o si torna addirittura a uno stato precedente perché le sincronizzazioni incrementali ripetute convergeranno sulla coerenza.
È anche possibile che l'altro controller di dominio rifiuti il cookie restituito dal controller di dominio originale. La ricerca genera un errore LDAP nel server come "0000203D: LdapErr: DSID-xxxxxxxx, commento: Controllo elaborazione errori, dati 0" e l'applicazione client può generare un errore, ad esempio "System.DirectoryServices.Protocols.DirectoryOperationException: si è verificato un errore di protocollo". Ciò può verificarsi, ad esempio, quando il cookie è precedente e il contenuto interno del cookie dovrebbe essere diverso quando viene elaborato da un server LDAP che esegue una versione diversa di Windows. Il cookie è una struttura opaca e non è garantito che sia coerente strutturalmente tra tutte le versioni del sistema operativo Windows. L'applicazione client deve gestire questo caso e riprovare con una sincronizzazione completa se si verifica questo errore.
Quando un oggetto viene rinominato o spostato, gli oggetti figlio, se presenti, non vengono inclusi nei risultati della ricerca, anche se i nomi distinti degli oggetti figlio sono stati modificati. Analogamente, quando un ace ereditabile viene modificato in un descrittore di sicurezza degli oggetti, gli oggetti figlio dell'oggetto non vengono inclusi nei risultati della ricerca, anche se i descrittori di sicurezza degli oggetti figlio sono stati modificati.
Usare l'attributo objectGUID per identificare gli oggetti rilevati. L'objectGUID di ogni oggetto rimane invariato indipendentemente dalla posizione in cui l'oggetto viene spostato all'interno della foresta.
Tenere presente che i risultati della ricerca di una ricerca DirSync indicano lo stato degli oggetti in una replica della partizione di directory al momento della ricerca. Ciò significa che le modifiche apportate in altri controller di dominio non verranno incluse se non sono state replicate nel controller di dominio di destinazione. Significa anche che gli attributi di un oggetto possono essere stati modificati più volte dalla ricerca DirSync precedente, ma la ricerca mostrerà solo lo stato finale, non la sequenza di modifiche.
Nell'implementazione di ADSI l'applicazione deve gestire il cookie come opaco e non fare ipotesi sull'organizzazione o sul valore interno.
Tenere presente che il client archivia il cookie, la lunghezza dei cookie e il nome DNS del controller di dominio nella stessa risorsa di archiviazione che contiene i dati dell'oggetto sincronizzato. In questo modo si garantisce che il cookie e altri parametri rimangano sincronizzati con i dati dell'oggetto se l'archiviazione viene ripristinata da un backup.
Per recuperare l'attributo parentGUID, costruito per il controllo DirSync, è anche necessario richiedere l'attributo name.
Per usare il controllo DirSync, il chiamante deve avere il diritto "directory get changes" assegnato nella radice della partizione monitorata. Per impostazione predefinita, questo diritto viene assegnato agli account Amministrazione istrator e LocalSystem nei controller di dominio. Il chiamante deve disporre anche del diritto di accesso esteso DS-Replication-Get-Changes. Per altre informazioni sull'implementazione di un meccanismo di rilevamento delle modifiche per le applicazioni che devono essere eseguite con un account che non dispone di questo diritto, vedere Polling for Changes Using USNChanged (Polling for Changes Using USNChanged). Per altre informazioni sui privilegi, vedere Privilegi.
Recupero di oggetti eliminati con una ricerca DirSync
I risultati della ricerca ADS_edizione StandardARCHPREF_DIRSYNC includono automaticamente oggetti eliminati (tombe) che corrispondono al filtro di ricerca specificato. Tuttavia, un filtro di ricerca che corrisponde a un oggetto quando è attivo potrebbe non corrispondere all'oggetto dopo l'eliminazione. Ciò è dovuto al fatto che le lapide conserva solo un subset degli attributi presenti nell'oggetto originale. Ad esempio, in genere si usa il filtro seguente per gli oggetti utente.
(&(objectClass=user)(objectCategory=person))
L'attributo objectCategory viene rimosso quando un oggetto viene eliminato, quindi il filtro precedente non corrisponde ad alcun oggetto di rimozione definitiva. Viceversa, l'attributo objectClass viene conservato negli oggetti tombstone, quindi un filtro di "(objectClass=user)" corrisponde agli oggetti utente eliminati.
L'elenco di attributi specificato con una ricerca DirSync funge anche da filtro; I risultati della ricerca includono solo gli oggetti in cui uno o più attributi specificati sono stati modificati dopo la ricerca DirSync precedente. Se l'elenco di attributi non include attributi conservati nelle pietre tombe, i risultati della ricerca non includeranno la rimozione definitiva. Per gestirlo, richiedere tutti gli attributi specificando un elenco di attributi Null; oppure è possibile richiedere l'attributo isDeleted , impostato su TRUE in tutte le pietre tombe. Gli attributi tombstone hanno il bit 0x8 impostato nell'attributo searchFlags della definizione attributeSchema .
Per altre informazioni, vedere Recupero di oggetti eliminati.
Implementazione LDAP del controllo DirSync
È anche possibile eseguire una ricerca DirSync usando l'API LDAP con il controllo LDAP_edizione StandardRVER_DIRSYNC_OID. Se si usa l'API LDAP, specificare anche i controlli LDAP_edizione StandardRVER_EXTENDED_DN_OID e LDAP_edizione StandardRVER_SHOW_DELETED_OID. Il controllo LDAP_edizione StandardRVER_EXTENDED_DN_OID fa sì che una ricerca LDAP restituisca una forma estesa del nome distinto che include objectGUID e objectSID per oggetti entità di sicurezza, ad esempio utenti, gruppi e computer. Il controllo LDAP_edizione StandardRVER_SHOW_DELETED_OID fa in modo che i risultati della ricerca includano i dati per gli oggetti eliminati. Tenere presente che questi controlli vengono inclusi automaticamente nell'implementazione di ADSI.