O Active Directory é incomum entre os diretórios LDAP, pois não é incomum ter cargas muito grandes. Na verdade, a maior carga útil que você pode enviar é de 12 Mbytes. Isso parece absurdamente grande, mas lá vai você.
No lado da entrada, é possível que alguém possa enviar uma consulta como (| (samAccountName = jsmith) (samAccountName = jdoe) (...) (samAccountName = zsmith)) e especificar curingas individuais ou juntos.
No lado da saída, um motivo comum para grandes cargas é paginação. Quando você tem uma consulta que retorna vários resultados, a resposta pode ser enorme. O AD tem suporte embutido para paginação e é muito fácil de fazer, portanto, é possível que uma única consulta simples para todos os objetos retorne GB de uma resposta.
Outro cenário não é especificar os atributos reais necessários em uma consulta. Se não for especificado, todos os atributos dos objetos poderão ser retornados (exceto para os atributos construídos), e um objeto AD poderá ter um monte de atributos.
A carga útil de 3 MB é realmente interessante, pois se você tiver o Exchange, essa seria a quantidade de dados retornados pelo DC para uma estação de trabalho quando alguém faz logon. Esses são os atributos de esquema do ADSI. Se você estiver em uma rede local, isso provavelmente não será perceptível, mas se você tiver clientes remotos e largura de banda de rede limitada, o download dos atributos de esquema do ADSI todos os dias poderá ser muito perceptível.
Mais informações sobre o download do cache do esquema ADSI:
Quando um usuário faz logon em uma estação de trabalho, a estação de trabalho verifica se os atributos do esquema ADSI não foram baixados ou se o atributo modifyTimestamp salvo no Registro é mais antigo do que o armazenado no AD. O registro se parece com isso:
[HKEY_CURRENT_USER\Software\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=contoso,DC=com]
"Time"="20141114030449.0Z"
O atributo do AD que é comparado:
DN: CN = Esquema, CN = Configuração, DC = contoso, DC = com
Atributo: modifyTimestamp
modifyTimestamp é um atributo "construído". O AD pega a data whenChanged mais recente dos outros atributos para determinar modifyTimestamp. Você pode ver as datas whenChanged executando repadmin / showObjMeta CN = Esquema, CN = Configuração, DC = contoso, DC = com
Uma pessoa razoável presumiria que um usuário baixaria o cache do esquema ADSI uma vez e não precisaria fazer o download novamente porque o esquema do AD não é alterado com frequência. No entanto, o modifyTimestamp não indica apenas quando o esquema do AD é atualizado, porque um cliente pode executar suas próprias atualizações de esquema.
Quando isso se torna um problema, são os backups. Quando um backup de estado do sistema é executado em um controlador de domínio, as informações de backup são registradas no atributo dsaSignature na partição. Isso, por sua vez, resulta em estações de trabalho clientes e servidores membros para determinar se eles precisam fazer o download do cache de esquema do ADSI novamente. Em uma rede local, isso não é perceptível, mas se você tiver uma WAN com largura de banda limitada separando seus clientes e os controladores de domínio, isso pode ser muito doloroso.
Para complicar ainda mais, quando o 2008 R2 SP1 foi lançado, a funcionalidade modifyTimestamp realmente não funcionou corretamente. A Microsoft corrigiu isso com um hotfix, que pode, na verdade, fazer com que o impacto no desempenho do cache do esquema ADSI se manifeste.
Como solução alternativa, é possível definir um sinalizador no atributo dsaSignature na partição de esquema para indicar ao backup a não atualização do atributo dsaSignature quando o backup for concluído. Isso evitará que o modifyTimestamp programe continuamente e interromperá os downloads dos atributos do esquema ADSI. Desvantagem é o seu aplicativo de monitoramento pode reclamar que a partição do esquema não está sendo submetida a backup. Outra alternativa é você pode criar um GPO para marcar o valor do registro "Time" para uma data distante no futuro, mas isso seria um kluge.