Ligar uma VM do Azure ao Entra Domain Services: decidir primeiro

Três decisões estão diante de uma VM Windows Server que tem de usar um diretório gerido, e o comando de ligação é a menor delas. Escolha o modelo de diretório errado e a ligação consegue enquanto a aplicação ainda não consegue autenticar. Falhe a resolução de nomes e a falha aparece num ponto que parece um problema de credenciais.

Resolva o modelo, a resolução e a conta antes de tocar no servidor, e depois o comando corre uma vez.

Qual das três ligações realmente quer

A ligação de dispositivo registra uma máquina no Microsoft Entra ID para acesso condicional e início de sessão único, e não dá à carga de trabalho qualquer bilhete Kerberos para um domínio ao estilo local. A ligação de domínio tradicional vincula um objeto de computador a um diretório e dá-lhe uma conta de máquina, política de grupo e autenticação de domínio. Um domínio gerido fornece esse segundo modelo como serviço. Os nomes soam parecidos e os resultados não.

Apenas as duas últimas envolvem um controlador de domínio no sentido usual, e apenas a opção gerida retira os servidores da sua lista de patches.

A decisão depende geralmente da aplicação e não da preferência. O software que quer uma ligação LDAP, uma conta de serviço com um SPN ou objetos de política de grupo pertence ao modelo de domínio. O software que só precisa de saber a identidade do utilizador num dispositivo empresarial normalmente não pertence.

O caminho DNS decide se a ligação pode terminar

Uma ligação de domínio começa com uma pesquisa de localizador dos registos do controlador do domínio, pelo que a resolução de nomes tem de funcionar antes de qualquer credencial ser verificada. Aponte a VM para os endereços de diretório do domínio gerido, quer através das definições DNS da rede virtual, quer através de um reencaminhador condicional que só envia esse espaço de nomes para lá. Um reencaminhador limitado ao espaço de nomes é geralmente a escolha mais segura, porque deixa o resto da resolução da VM em paz.

Teste o localizador e não um nome de anfitrião nu. Um ping ao nome do domínio não prova quase nada, enquanto uma consulta SRV dos registos do controlador do domínio ou devolve os destinos esperados ou falha de imediato:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53

Substitua o nome do domínio e os dois endereços pelos valores da configuração do seu domínio gerido; os números aqui são exemplos. Se a consulta devolver respostas de outra zona, a VM usa um resolvedor que não reencaminha o espaço de nomes gerido, e nenhuma quantidade de repetições da ligação o mudará.

Mantenha a carga de trabalho fora da sub-rede que o domínio gerido reserva para os seus próprios recursos de serviço, e mantenha as portas do diretório no caminho privado. A exposição pública dessas portas não é um atalho; é um desenho diferente com um perfil de risco diferente.

A elegibilidade da conta é verificada antes da máquina

A conta que efetua a ligação precisa de permissão para criar um objeto de computador no contentor de destino, e tem de conseguir autenticar-se contra o domínio gerido. Uma conta apenas na nuvem criada antes de o domínio gerido existir pode não ter o material derivado da palavra-passe de que o domínio precisa, e uma alteração ou reposição da palavra-passe regenera-o. Esse detalhe explica uma classe de falhas de ligação que parecem palavras-passe erradas quando a palavra-passe está correta. Teste a credencial contra o domínio antes de a janela de manutenção abrir.

As contas híbridas sincronizadas têm os seus próprios pré-requisitos que um objeto de utilizador visível não satisfaz sozinho. Estar listado no diretório não é o mesmo que conseguir obter um bilhete dele, por isso teste a conta antes da janela de manutenção e não durante.

Delegue o direito de ligação de forma estreita. Dar a cada futuro utilizador de servidor a pertença de administrador de domínio para que ocorra uma única inscrição é uma concessão permanente para um problema temporário.

A ligação em si é um único comando

Com o modelo escolhido, o DNS a responder e a conta elegível, a operação é a habitual do Windows. O prompt mantém a palavra-passe fora de scripts e do histórico da shell:

Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru

O comando não reinicia a máquina sozinho nesta forma, pelo que o reinício ocorre ao abrigo do plano de manutenção e com o caminho de recuperação ainda disponível. Um servidor já ligado a outro domínio precisa de um plano de migração, não de uma segunda ligação sobre a primeira.

Registe o contentor onde o objeto de computador ficou e a conta que o criou. Ambos importam quando a máquina tem de ser novamente ligada após uma reconstrução, e nenhum deles é óbvio a partir do servidor depois.

O que a pertença não concede

A pertença ao domínio não torna ninguém administrador local e não concede acesso ao ambiente de trabalho remoto ou a partilhas de ficheiros. Esses direitos configuram-se em separado, e num domínio gerido ficam dentro do seu âmbito administrativo suportado.

O caminho de rede é uma dependência contínua e não um passo de configuração. Se a ligação privada desaparecer, o servidor continua a funcionar com credenciais em cache até algo precisar do diretório, e então a falha chega num registo de aplicação e não ao lado da configuração que mudou.

O guia da Microsoft para a ligação de Windows Server enumera os pré-requisitos suportados para o fluxo de trabalho do domínio gerido. Leia-o à luz das três decisões acima e trate qualquer discrepância como motivo para parar e não como detalhe a contornar.