Alterar notificações no Active Directory Domain Services

Os Serviços de Domínio do Active Directory fornecem um mecanismo para que um aplicativo cliente se registre com um controlador de domínio para receber notificações de alteração. Para fazer isso, o cliente especifica o controle de notificação de alteração LDAP em uma operação de pesquisa LDAP assíncrona. O cliente também especifica os seguintes parâmetros de pesquisa.

Parâmetro	Descrição
Âmbito	Especifique LDAP_SCOPE_BASE para monitorar apenas o objeto ou LDAP_SCOPE_ONELEVEL para monitorar os filhos imediatos do objeto, não incluindo o objeto em si. Não especifique LDAP_SCOPE_SUBTREE. Embora o escopo da subárvore tenha suporte se o objeto base for a raiz de um contexto de nomenclatura, seu uso poderá afetar severamente o desempenho do servidor, pois ele gera uma mensagem de resultado de pesquisa LDAP sempre que um objeto no contexto de nomenclatura é modificado. Não é possível especificar LDAP_SCOPE_SUBTREE para uma subárvore arbitrária.
Filtro	Especifique um filtro de pesquisa de "(objectclass=*)", o que significa que você recebe notificações de alterações em qualquer objeto no escopo especificado.
Atributos	Especifique uma lista de atributos a serem retornados quando ocorrer uma alteração. Lembre-se de que você recebe notificações quando qualquer atributo é modificado, não apenas os atributos especificados.

Você pode registrar até cinco solicitações de notificação em uma única conexão LDAP. Você deve ter um thread dedicado que aguarde as notificações e as processe rapidamente. Quando você chama a função ldap_search_ext para registrar uma solicitação de notificação, a função retorna um identificador de mensagem que identifica essa solicitação. Em seguida, você usa a função ldap_result para aguardar as notificações de alteração. Quando ocorre uma alteração, o servidor envia uma mensagem LDAP que contém o identificador de mensagem para a solicitação de notificação que gerou a notificação. Isso faz com que a função ldap_result retorne com os resultados da pesquisa que identificam o objeto que foi alterado.

O aplicativo cliente deve determinar o estado inicial do objeto monitorado. Para fazer isso, primeiro você deve registrar a solicitação de notificação e, em seguida, ler o estado atual.

O aplicativo cliente também deve determinar a causa da alteração. Para uma pesquisa de nível base, uma notificação ocorre quando qualquer atributo é alterado ou quando o objeto é excluído ou movido. Para uma pesquisa de um nível, uma notificação ocorre quando um objeto filho é criado, excluído, movido ou modificado. Lembre-se de que mover ou renomear um objeto na hierarquia acima de um objeto de destino não gera uma notificação, mesmo que o nome diferenciado do destino tenha sido alterado como resultado. Por exemplo, se o monitoramento for alterado para os objetos filho em um contêiner, você não receberá notificações se o contêiner em si for movido ou renomeado.

Quando o cliente processa os resultados da pesquisa, ele pode usar a função ldap_get_dn para obter o nome diferenciado do objeto que foi alterado. Não confie em nomes diferenciados para identificar os objetos rastreados, pois nomes diferenciados podem ser alterados. Em vez disso, inclua o atributo objectGUID na lista de atributos a serem recuperados. O objectGUID de cada objeto permanece inalterado, independentemente de onde o objeto é movido dentro da floresta empresarial.

Se um objeto dentro do escopo de pesquisa for excluído, o cliente receberá uma notificação de alteração e o atributo isDeleted do objeto será definido como TRUE. Nesse caso, os resultados da pesquisa relatam o novo nome diferenciado do objeto no contêiner Objetos Excluídos de sua partição. Não é necessário especificar o controle tombstone (LDAP_SERVER_SHOW_DELETED_OID) para obter notificações de exclusões de objeto. Para obter mais informações, consulte Recuperando objetos excluídos.

Quando um cliente registra uma solicitação de notificação, o cliente continua recebendo notificações até que a conexão seja interrompida ou o cliente abandone a pesquisa chamando a função ldap_abandon. Se o cliente ou o servidor se desconectar, por exemplo, se o servidor falhar, a solicitação de notificação será encerrada. Quando o cliente se reconecta, ele deve se registrar para notificações novamente e, em seguida, ler o estado atual dos objetos de interesse no caso de haver alterações enquanto o cliente estava desconectado.

O cliente pode usar o valor do atributo uSNChanged de um objeto para determinar se o estado atual do objeto no servidor reflete as alterações mais recentes que o cliente recebeu. O sistema aumenta o atributo uSNChanged de um objeto quando o objeto é movido ou modificado. Por exemplo, se o servidor falhar e a partição de diretório for restaurada de um backup, a réplica do servidor de um objeto poderá não refletir alterações relatadas anteriormente ao cliente, nesse caso, o valor uSNChanged no servidor será menor do que o valor armazenado pelo cliente.

Para obter mais informações e um exemplo de código que usa o controle de notificação de alteração LDAP em uma operação de pesquisa LDAP assíncrona, consulte código de exemplo para receber notificações de alteração.

Para obter mais informações sobre quando usar o controle de notificação de alteração LDAP, consulte Visão geral das técnicas de controle de alterações.