Share via

Sondagem de alterações usando o controle DirSync

  • Artigo

O controle de sincronização de diretório do Active Directory (DirSync) é uma extensão de servidor LDAP que permite que um aplicativo pesquise objetos alterados desde um estado anterior em uma partição de diretório.

Use o controle DirSync por meio do ADSI especificando a preferência de pesquisa ADS_SEARCHPREF_DIRSYNC ao usar IDirectorySearch. Para obter mais informações e um exemplo de código, consulte Código de exemplo usando ADS_SEARCHPREF_DIRSYNC. Você também pode executar uma pesquisa DirSync usando a API LDAP. A seguir descrevemos a implementação do ADSI, a maioria dos quais também se aplica ao uso direto do LDAP, exceto conforme discutido no final deste tópico.

Ao executar uma pesquisa do DirSync, você passa um elemento de dados (cookie) específico do provedor que identifica o estado do diretório no momento da pesquisa anterior do DirSync. Para a primeira pesquisa, você passa um cookie nulo e a pesquisa retorna todos os objetos que correspondem ao filtro. A pesquisa também retorna um cookie válido. Armazene o cookie no mesmo armazenamento que você está sincronizando com o servidor do Active Directory. Em pesquisas subsequentes, obtenha o cookie do armazenamento e passe-o com a solicitação de pesquisa. Os resultados da pesquisa agora incluem apenas os objetos e atributos que foram alterados desde o estado anterior identificado pelo cookie. A pesquisa também retorna um novo cookie para armazenar para a próxima pesquisa.

A tabela a seguir lista os parâmetros de pesquisa que a solicitação de pesquisa do cliente pode especificar.

Parâmetro Descrição
Base da pesquisa A base de uma pesquisa DirSync deve ser a raiz de uma partição de diretório, que pode ser uma partição de domínio, a partição de configuração ou a partição de esquema.
Escopo O escopo de uma pesquisa DirSync deve ser ADS_SCOPE_SUBTREE, ou seja, toda a subárvore da partição. Lembre-se de que, para uma pesquisa de uma partição de domínio, a subárvore inclui os cabeçalhos, mas não o conteúdo, das partições de configuração e esquema. Para pesquisar alterações em um escopo menor, use a técnica USNChanged em vez de DirSync.
Filter Você pode especificar qualquer filtro de pesquisa válido. Para uma pesquisa inicial com um cookie nulo, os resultados incluem todos os objetos que correspondem ao filtro. Para pesquisas subsequentes com um cookie válido, os resultados da pesquisa incluem dados apenas para objetos que correspondem ao filtro e foram alterados desde o estado indicado pelo cookie. Para obter mais informações sobre filtros de pesquisa, consulte Criando um filtro de consulta.
Atributos Você pode especificar uma lista de atributos a serem retornados quando ocorrer uma alteração. Para cada objeto, os resultados iniciais incluem todos os atributos solicitados definidos no objeto. Os resultados da pesquisa subsequentes incluem apenas os atributos especificados que foram alterados. Atributos inalterados não são incluídos nos resultados da pesquisa. Na implementação ADSI, os resultados da pesquisa sempre incluem o objectGUID e instanceTypede cada objeto. Além disso, a lista de atributos especificada atua como um filtro adicional: os resultados iniciais da pesquisa incluem apenas objetos que têm pelo menos um dos atributos especificados definidos; As pesquisas subsequentes incluem apenas objetos nos quais um ou mais dos atributos foram alterados (valores adicionados ou excluídos).

 

Além disso, esteja ciente de que:

  • Para pesquisas incrementais, a prática recomendada é vincular ao mesmo controlador de domínio (DC) usado na pesquisa anterior, ou seja, o controlador de domínio que gerou o cookie. Se o mesmo controlador de domínio não estiver disponível, aguarde até que ele esteja ou vincule-se a um novo controlador de domínio e execute uma sincronização completa. Armazene o nome DNS do controlador de domínio no armazenamento secundário com o cookie.

    Você pode passar um cookie gerado por um DC para um DC diferente hospedando uma réplica da mesma partição de diretório. Não há chance de um cliente perder alterações usando um cookie de um DC em outro DC. No entanto, é possível que os resultados da busca da nova CD incluam alterações relatadas pela antiga DO; em alguns casos, o novo controlador de domínio pode retornar todos os objetos e atributos, como acontece com uma sincronização completa. O cliente deve apenas tornar seu banco de dados consistente com os resultados de pesquisa relatados para qualquer chamada DirSync específica, ou seja, manipular todos os resultados incrementais como se fossem o estado mais recente. Não importa se você já viu a alteração antes ou se está voltando a um estado anterior, porque sincronizações incrementais repetidas convergirão para a consistência.

  • Também é possível que o outro DC rejeite o cookie retornado do DC original. A pesquisa gera um erro LDAP no servidor como "0000203D: LdapErr: DSID-xxxxxxxx, comentário: Controle de processamento de erros, dados 0", e o aplicativo cliente pode gerar um erro como "System.DirectoryServices.Protocols.DirectoryOperationException: Ocorreu um erro de protocolo". Isso pode acontecer, por exemplo, quando o cookie é mais antigo, e espera-se que o conteúdo interno do cookie seja diferente quando processado por um servidor LDAP executando uma versão diferente do Windows. O cookie é uma estrutura opaca e não é garantido que seja estruturalmente consistente entre todas as versões do sistema operacional Windows. O aplicativo cliente deve lidar com esse caso e tentar novamente com uma sincronização completa se esse erro for encontrado.

  • Quando um objeto é renomeado ou movido, seus objetos filho, se houver, não são incluídos nos resultados da pesquisa, mesmo que os nomes distintos dos objetos filho tenham sido alterados. Da mesma forma, quando uma ACE hereditária é modificada em um descritor de segurança de objeto, os objetos filho do objeto não são incluídos nos resultados da pesquisa, mesmo que os descritores de segurança dos objetos filho tenham sido alterados.

  • Use o atributo objectGUID para identificar os objetos controlados. O objectGUID de cada objeto permanece inalterado, independentemente de onde o objeto é movido dentro da floresta.

  • Lembre-se de que os resultados da pesquisa de uma pesquisa do DirSync indicam o estado dos objetos em uma réplica da partição de diretório no momento da pesquisa. Isso significa que as alterações feitas em outros DCs não serão incluídas se não tiverem sido replicadas para o DC de destino. Isso também significa que os atributos de um objeto podem ter sido alterados várias vezes desde a pesquisa anterior do DirSync, mas a pesquisa mostrará apenas o estado final, não a sequência de alterações.

  • Na implementação do ADSI, o aplicativo deve manipular o cookie como opaco e não fazer suposições sobre sua organização interna ou valor.

  • Lembre-se de que o cliente armazena o cookie, o comprimento do cookie e o nome DNS do controlador de domínio no mesmo armazenamento que contém os dados do objeto sincronizado. Isso garante que o cookie e outros parâmetros permaneçam sincronizados com os dados do objeto se o armazenamento for restaurado a partir de um backup.

  • Para recuperar o atributo parentGUID, que é construído para o controle DirSync, também é necessário solicitar o atributo name.

Para usar o controle DirSync, o chamador deve ter o direito "directory get changes" atribuído na raiz da partição que está sendo monitorada. Por padrão, esse direito é atribuído às contas Administrador e LocalSystem em controladores de domínio. O chamador também deve ter o direito de acesso de controle estendido DS-Replication-Get-Changes. Para obter mais informações sobre como implementar um mecanismo de controle de alterações para aplicativos que devem ser executados em uma conta que não tenha esse direito, consulte Sondagem para alterações usando USNChanged. Para obter mais informações sobre privilégios, consulte Privilégios.

Os resultados da pesquisa ADS_SEARCHPREF_DIRSYNC incluem automaticamente objetos excluídos (marcas de exclusão) que correspondem ao filtro de pesquisa especificado. No entanto, um filtro de pesquisa que corresponderá a um objeto quando ele estiver ativo pode não corresponder ao objeto depois que ele for excluído. Isso ocorre porque as lápides retêm apenas um subconjunto dos atributos presentes no objeto original. Por exemplo, você normalmente usaria o seguinte filtro para objetos de usuário.

(&(objectClass=user)(objectCategory=person))

O atributo objectCategory é removido quando um objeto é excluído, portanto, o filtro acima não corresponderia a nenhum objeto de lápide. Por outro lado, o atributo objectClass é retido em objetos de lápide, portanto, um filtro de "(objectClass=user)" corresponderia a objetos de usuário excluídos.

A lista de atributos especificada com uma pesquisa do DirSync também atua como um filtro; os resultados da pesquisa incluem apenas objetos nos quais um ou mais dos atributos especificados foram alterados desde a pesquisa anterior do DirSync. Se a lista de atributos não incluir nenhum atributo retido em lápides, os resultados da pesquisa não incluirão marcas de exclusão. Para lidar com isso, solicite todos os atributos especificando uma lista de atributos nulos; ou você pode solicitar o atributo isDeleted , definido como TRUE em todas as lápides. Os atributos Tombstone têm o 0x8 bit definido no atributo searchFlags da definição attributeSchema .

Para obter mais informações, consulte Recuperando objetos excluídos.

Implementação LDAP do controle DirSync

Você também pode executar uma pesquisa DirSync usando a API LDAP com o controle LDAP_SERVER_DIRSYNC_OID . Se você usar a API LDAP, especifique também os controles LDAP_SERVER_EXTENDED_DN_OID e LDAP_SERVER_SHOW_DELETED_OID . O controle LDAP_SERVER_EXTENDED_DN_OID faz com que uma pesquisa LDAP retorne uma forma estendida do nome distinto que inclui o objectGUID e objectSID para objetos de entidade de segurança, como usuários, grupos e computadores. O controle LDAP_SERVER_SHOW_DELETED_OID faz com que os resultados da pesquisa incluam dados para objetos excluídos. Lembre-se de que esses controles são incluídos automaticamente na implementação do ADSI.