Jean Carlos Bormanieri :: Website

Todos os administradores de redes sabem que o Active Directory é um dos melhores serviços que a Microsoft já desenvolveu. Já imaginou como seria manter sua rede sem ele?

Em ambientes pequenos não haveria problemas, agora imagine gerenciar uma rede com 2 mil usuários, separados em 16 sites (filiais) em 3 continentes? Pois é, agradeça todos os dias ao tio Bill por isso.

Pouca gente sabe, mas como tudo no mundo, esse serviço tem algumas limitações técnicas. Esse artigo descreve algumas das limitações que existem no Active Directory atualmente.

Número máximo de objetos:  cada controlador de domínio na floresta pode criar aproximadamente 2,15 bilhões de objetos durante sua vida;

Número máximo de SSIDs: aproximadamente 1 bilhão de SSIDs únicas;

Associação de Grupos: cada objeto (conta, grupo) pode fazer parte de no máximo 1.015 grupos. Mais informação sobre isso aqui;

Tamanho de FQDNs: Fully qualified domain names não podem exceder 64 caracteres, incluindo traços e pontos;

Tamanho de Nome de Arquivos: o nome e o path do arquivo não podem exceder 255 caracteres.

A explicação dessa e de outras limitações pode ser encontrada neste link.

Recentemente, fui solicitado a resolver um problema onde um determinado usuário não estava conseguindo identificar quais grupos de segurança um determinado usuário fazia parte.

Entendendo e simulando o problema:

Na situação reportada, um programa de terceiros precisava descobrir se uma conta de usuário fazia parte de um determinado grupo no AD. Para isso, fazia uma consulta através do protocolo LDAP usando um usuário com privilégios mínimos cadastrado neste domínio. Através dessa consulta, o programa lia o atributo memberOf dessa conta. Entretanto, o resultado obtido não era o esperado.

Primeiramente, para identificar se havia algum problema relacionado a maneira como esta equipe estava fazendo essa consulta com o LDAP, tentei atingir o ‘goal’ solicitado (retornar o grupo de usuários de um determinado login) utilizando as próprias ferramentas do Windows. Para isso, usei o utilitário dsget.exe. Esse utilitário nos permite fazer consultas aos medados do Active Directory. Para isso, executei com a seguinte sintaxe:

dsget user “CN=user1,OU=Usuarios,DC=cetil,DC=com,DC=br” -memberof

Vejam que 0 segundo parâmetro é o caminho exato desta conta no Active Directory. Utilizei o parâmetro -memberof para que fosse retornado alista de grupos deste usuário.

Verifiquei que ao executar este comando no contexto do usuário utilizado para fazer as consultas LDAP, apenas o Grupo Primário desta conta era retornado, embora ela faça parte de outros grupos. Porque isso acontece então?

Muito simples. A conta utilizada para fazer essa consulta não possui privilégios suficientes para ler os atributos necessários no Schema do Active Directory. Para resolver isso é muito simples:

1- Abra a guia Active Directoy Users and Computers (dsa.msc) , clique com o botão direito em cima do domínio desejado e escolha a opção Delegate Control;

2- Na tela de boas vindas, clique em Next;

3- Na tela de seleção de grupos e usuários, clique em Adicionar e informe a conta a qual você irá atribuir esse privilégio. Após isso, clique em Next;

4- Na tela Tasks to delegate, escolha a opção Create a custom task to delegate e depois clique no botão Next;

5- Na tela Active Directory Object Type, clique em Only the following objects in folder. Após, habilite na lista o item User Objects e clique em Next;

6- Na janela Permissions, desmarque a opção General e habilite a opção Property-specific. Após isso, habilite a opção Read MemberOf e clique em Next;

7- Na tela final, temos um sumário da operação que será realizada. Clique em Finish para que a operação seja confirmada.

8- A partir de agora, a conta de usuário que você atribuiu terá privilégios para ler o atributo MemberOf do metadados do Active Directory, como podemos identificar na imagem abaixo.

Essa operação pode ser feita para delegar o acesso (leitura ou escrita) a qualquer objeto do schema do Active Directory.