Notificações de alteração nos Serviços de Domínio Active Directory
Os Serviços de Domínio 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 |
---|---|
Escopo |
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 seja suportado se o objeto base for a raiz de um contexto de nomenclatura, seu uso pode afetar severamente o desempenho do servidor, pois ele gera uma mensagem de resultado de pesquisa LDAP toda vez que um objeto no contexto de nomeação é modificado. Não é possível especificar LDAP_SCOPE_SUBTREE para uma subárvore arbitrária. |
Filter |
Especifique um filtro de pesquisa de "(objectclass=*)", o que significa que você recebe notificações para 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, use a função ldap_result para aguardar notificações de alteração. Quando ocorre uma alteração, o servidor envia uma mensagem LDAP que contém o identificador da mensagem para a solicitação de notificação que gerou a notificação. Isso faz com que a função ldap_result retorne com resultados de pesquisa que identificam o objeto que foi alterado.
O aplicativo cliente deve determinar o estado inicial do objeto monitorado. Para fazer isso, você deve primeiro 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 distinto 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 próprio contêiner 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 distinto do objeto que foi alterado. Não confie em nomes distintos para identificar os objetos rastreados, pois nomes distintos 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 corporativa.
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 distinto do objeto no contêiner Objetos Excluídos de sua partição. Não é necessário especificar o controle de lápide (LDAP_SERVER_SHOW_DELETED_OID) para obter notificações de exclusões de objetos. Para obter mais informações, consulte Recuperando objetos excluídos.
Quando um cliente registra uma solicitação de notificação, ele continua a receber 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 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, caso houvesse 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 a partir de um backup, a réplica de um objeto do servidor pode não refletir as alterações relatadas anteriormente ao cliente, caso em que 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.