O blog da AWS

AWS AD Connector – o curioso caso de falha em localização de objetos

Por Divyank Pandya e Caio Ribeiro César

 

Este blog post foi criado para auxiliar clientes, parceiros e engenheiros de suporte AWS com conhecimentos de Active Directory no contexto de cenários sobre AWS AD Connector. Iremos descrever algumas das funcionalidades do produto e elaborar um plano de ação para um problema conhecido em empresas de pequeno, médio e grande porte.

Muitos dos clientes AWS utilizam a solução de Active Directory Connector para conectar o diretório existente na AWS.  Utilizamos esta solução como um “gateway” em que podemos direcionar as solicitações para o AD local, removendo a necessidade de manter informações em cache na nuvem.

Criamos um ambiente seguindo os conceitos de pré-requisitos: VPC com diferentes subnets que possuem rota e conectividade nas portas selecionadas, uma conta de serviço com permissionamento correto em um domínio com um nível funcional acima de WS2003, objetos com a configuração padrão de pré-autenticação Kerberos.

Assim que terminamos as configurações de pré-requisitos, eliminamos alguns problemas de networking instalando uma nova instância EC2 e executando os testes de DirectoryServicePortTest em uma subnet que seria utilizada pelo AD Connector.

Podemos validar no teste abaixo, que efetuamos uma conexão nas portas dos serviços de DNS, Kerberos e LDAP:

DirectoryServicePortTest.exe -d <domain_name> -ip <server_IP_address> -tcp "53,88,389" -udp "53,88,389"

Prosseguimos então para a criação do AD Connector no Directory Service:

A instância que executou o teste de DirectoryServicePortTest.exe estava em uma das subnets acima.

 

Validamos que o diretório foi criado com sucesso:

Seguimos o procedimento para a criação de um Workspace simples. Modelo seguido para um teste de utilização do diretório sincronizado pelo AD Connector.

Ao entrar na tela inicial do Workspaces, visualizamos o nosso diretório listado como “ativo”:

Prosseguimos com a etapa de teste e selecionamos a opção “Launch Workspaces”. Selecionamos o diretório criado e assim que tentamos localizar usuários em uma query específica, recebemos um erro genérico (juntamente com o load interminável no processo de procura pelo objeto “aws”):

Como o erro da console de pesquisa era genérico, precisamos de uma coleta de logs específica nos Domain Controllers do nosso ambiente.

Foi feita a instalação e execução do WireShark para a coleta de trace de rede juntamente com um filtro simples para pacotes “ldap”. Nesta coleta, podemos analizar que a query é feita para o dc=caiorc,dc=corp e existe uma falha específica de “unavailableCriticalExtension”.

Se expandirmos o pacote com o erro, temos mais informações da falha:

ldap.errorMessage 00000057: LdapErr: DSID-0C090AF4, comment: Error processing control, data 0, v4563

O código de erro LDAP 12 indica que o servidor LDAP não pôde atender a uma solicitação porque uma ou mais extensões críticas não estavam disponíveis. Em outras palavras, o servidor não suporta o controle ou o controle não é apropriado para o tipo de operação (LDAP RFC).

Vamos então focar em controles suportados pelo protocolo, ou seja, elementos que existem na mensagem LDAP que definem como a operação deve ser processada.

Quando coletamos resultados de objetos de um servidor (LDAP searchRequest), o controle de VLV nos chamou a atenção (Virtual View List).

O que é o Virtual View List? É uma operação de pesquisa LDAP que permite ao cliente soliticar uma pesquisa classificada com um número específico de resutaldo antes resultado real. Ou seja, em uma pesquisa de 800k objetos (que é o número aproximado de objetos existentes neste laboratório), consigo criar um subconjunto de 80 objetos – permitindo assim que eu tenha resultados mais rapidamente, sem o armazenamento de um milhao de objetos em uma única query.

Em um aplicativo, o desenvolvedor pode configurar um VLV para a visualização de algumas entradas por vez – atualizando a lista com a interação do usuário (descendo a tela, inserindo mais informações na pesquisa, etc).

Dica: uma boa estratégia em troubleshooting é ter um ambiente funcionando e coletar o trace. Assim que coletar, comparar o pacote e validar o que exatamente está sendo feito. A última imagem deste post mostra como isso pode facilitar no escopo do problema.

Sempre que o WorksPace (e outros aplicativos que utilizam ldap) fizer uma query no Active Directory local, ele pequisa a opção de controle LDAP_CONTROL_VLVREQUEST. Se não tivermos VLV, a query irá falhar.

Para o Microsoft Active Directory, o VLV vem habilitado por padrão, porém, como possuímos customizações no nosso ambiente de teste, fomos validar a configuração:

a. Efetuamos o login no DC com a permissão de Enterprise admin.

b. Abrimos o ADISEDIT, partição de Configuration.

c. Expandimos o objeto CN=Configuration,DC=DomainNamecontainer,CN=Services, CN=Windows NT.

d. Com o botão direito, selecionamos a opção de propriedades em CN=Directory Service.

e. Na lista de atributos, selecionamos a opção “msds-Other-Settings”.

f. Alteramos a opção de DisableVLVSupport=1 para DisableVLVSupport=0 (padrão).

Efetuamos então um novo teste no WorksPaces:

O novo trace mostra também qual o comportamento padrão deste search:

 

Conclusão

A implementação do AWS AD Connector é necessária para a utilização de um gateway em ambientes que conectam seu diretório existente na AWS. Neste post, discutimos algumas etapas de troubleshooting e também como resolver um problema de erro genérico no portal.

Discutimos como efetuar uma análise de trace ldap utilizando WireShark e sobre o Virtual List View e seus impactos caso desabilitado em uma implementação de AWS AD Connector.

Para mais informações sobre AWS AD Connector, recomendamos a leitura  deste blog.

 


 

Sobre o autor

Caio Ribeiro Cesar

Caio atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 12 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.

 

 

Divyank Pandya

Divyank Pandya é engenheiro de suporte em nuvem da Amazon Web Services, ajudando os clientes a projetar soluções, cargas de trabalho e a utilizar os serviços da AWS para melhor se adequar ao seu ambiente