Unir unha VM de Azure a Entra Domain Services: decidir primeiro

Tres decisións están diante dunha VM de Windows Server que ten que usar un directorio xestionado, e o comando de unión é a menor delas. Escolla o modelo de directorio equivocado e a unión consegue mentres a aplicación segue sen poder autenticarse. Falle na resolución de nomes e o erro aparece nun punto que parece un problema de credenciais.

Resolva o modelo, a resolución e a conta antes de tocar o servidor, e despois o comando execútase unha vez.

Cal das tres unións quere realmente

A unión de dispositivo rexistra unha máquina en Microsoft Entra ID para o acceso condicional e o inicio de sesión único, e non lle dá á carga de traballo ningún ticket Kerberos cara a un dominio ao estilo local. A unión de dominio tradicional vincula un obxecto de equipo nun directorio e dálle unha conta de máquina, política de grupo e autenticación de dominio. Un dominio xestionado ofrece ese segundo modelo como servizo. Os nomes soan parecidos e os resultados non.

Só as dúas últimas implican un controlador de dominio no sentido habitual, e só a opción xestionada saca os servidores da súa lista de parches.

A decisión adoita depender da aplicación e non da preferencia. O software que quere unha ligazón LDAP, unha conta de servizo cun SPN ou obxectos de política de grupo pertence ao modelo de dominio. O software que só precisa coñecer a identidade do usuario nun dispositivo corporativo normalmente non pertence.

A ruta DNS decide se a unión pode rematar

Unha unión de dominio comeza cunha busca de localizador dos rexistros do controlador do dominio, así que a resolución de nomes ten que funcionar antes de que se comprobe calquera credencial. Apunte a VM ás direccións de directorio do dominio xestionado, xa sexa mediante a configuración DNS da rede virtual ou mediante un reenviador condicional que só envíe ese espazo de nomes cara a elas. Un reenviador limitado ao espazo de nomes adoita ser a opción máis segura, porque deixa intacto o resto da resolución da VM.

Probe o localizador e non un nome de host espido. Un ping ao nome do dominio non demostra case nada, mentres que unha consulta SRV dos rexistros do controlador do dominio ou ben devolve os destinos esperados ou ben falla de inmediato:

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

Substitúa o nome do dominio e as dúas direccións polos valores da configuración do seu dominio xestionado; os números de aquí son exemplos. Se a consulta devolve respostas doutra zona, a VM usa un solucionador que non reenvía o espazo de nomes xestionado, e ningunha cantidade de reintentos da unión o cambiará.

Manteña a carga de traballo fóra da subrede que o dominio xestionado reserva para os seus propios recursos de servizo, e manteña os portos do directorio na ruta privada. A exposición pública deses portos non é un atallo; é un deseño distinto cun perfil de risco distinto.

A elixibilidade da conta compróbase antes que a máquina

A conta que realiza a unión necesita permiso para crear un obxecto de equipo no contedor de destino, e debe poder autenticarse contra o dominio xestionado. Unha conta só na nube creada antes de que existise o dominio xestionado pode carecer do material derivado do contrasinal que o dominio necesita, e un cambio ou restablecemento de contrasinal volve xeralo. Ese detalle explica unha clase de fallos de unión que parecen contrasinais incorrectos cando o contrasinal é correcto. Probe a credencial contra o dominio antes de que se abra a xanela de mantemento.

As contas híbridas sincronizadas teñen os seus propios requisitos previos que un obxecto de usuario visible non satisfai por si só. Estar listado no directorio non é o mesmo que poder obter un ticket del, así que probe a conta antes da xanela de mantemento e non durante ela.

Delegue o dereito de unión de forma estreita. Dar a cada futuro usuario de servidor a pertenza de administrador de dominio para que ocorra unha única inscrición é unha concesión permanente para un problema temporal.

A unión en si é un só comando

Co modelo elixido, o DNS respondendo e a conta elixible, a operación é a habitual de Windows. O indicador mantén o contrasinal fóra dos scripts e do historial do intérprete:

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

O comando non reinicia a máquina por si só nesta forma, así que o reinicio ocorre baixo o plan de mantemento e coa ruta de recuperación aínda dispoñible. Un servidor xa unido a outro dominio necesita un plan de migración, non unha segunda unión sobre a primeira.

Anote o contedor no que aterrou o obxecto de equipo e a conta que o creou. Ambos importan cando a máquina ten que volver unirse tras unha reconstrución, e ningún dos dous resulta evidente desde o servidor despois.

O que a pertenza non concede

A pertenza ao dominio non converte a ninguén en administrador local nin concede acceso ao escritorio remoto ou a recursos compartidos de ficheiros. Eses dereitos configúranse por separado, e nun dominio xestionado quedan dentro do seu ámbito administrativo admitido.

A ruta de rede é unha dependencia continua, non un paso de configuración. Se a conexión privada desaparece, o servidor segue funcionando con credenciais na caché ata que algo necesite o directorio, e entón o fallo chega nun rexistro de aplicación e non xunto á configuración que cambiou.

A guía de Microsoft para a unión de Windows Server enumera os requisitos previos admitidos para o fluxo de traballo do dominio xestionado. Léaa fronte ás tres decisións anteriores e trate calquera discrepancia como un motivo para deter e non como un detalle que sortear.