Unir un equipo a un dominio por una VPN de usuario y sobrevivir al reinicio
Una VPN de punto a sitio puede transportar la unión al dominio. No obstante, no seguirá conectada durante el reinicio, así que pruebe el primer inicio de sesión de dominio antes de la entrega.
Puede ejecutar una unión al dominio a través de una VPN de punto a sitio. Lo que esa conexión normalmente no puede hacer es mantenerse activa durante el reinicio posterior, que es cuando el primer usuario de dominio intenta iniciar sesión. Ahora recorro la unión en tres etapas: demostrar la ruta y el descubrimiento mientras hay un administrador local con sesión iniciada, ejecutar la unión y, después, probar el primer inicio de sesión de dominio antes de entregar el portátil. Cada etapa tiene una prueba que falla en un lugar distinto.
Separar esas etapas es lo que evita que el proyecto termine con un portátil que se unió correctamente y no se puede usar.
Antes de conectar: edición, administrador local, DNS
La máquina necesita una edición que admita la unión al dominio y un administrador local autorizado a realizarla. La VPN debe estar activa en esa misma sesión, porque la unión se ejecuta en el contexto de seguridad que está utilizando.
Apunte el cliente al DNS del directorio de la organización, no a un resolutor público ni a una entrada del archivo hosts. La unión necesita encontrar los registros de servicio y luego llegar a los equipos que esos registros nombran. Un sufijo obsoleto o un resolutor público envían el descubrimiento a otro lugar por completo.
Revise también el reloj. Kerberos no tolera desviaciones horarias, y un portátil que ha estado un mes sin conexión es una fuente habitual de errores de unión desconcertantes.
Confirme que el dominio se puede descubrir, no solo hacer ping
Resuelva el registro LDAP SRV del dominio antes de intentar la unión. Para un entorno ilustrativo de un solo dominio llamado ad.corp.example, la consulta es:
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.exampleUn registro devuelto es necesario pero no suficiente. Resuelva cada nombre de DC que enumera y confirme que puede llegar a los servicios necesarios a través del túnel. Un ping al nombre del dominio no demuestra casi nada sobre el descubrimiento.
Permita las dependencias de AD documentadas: autenticación, tráfico SMB y RPC, además de sincronización horaria. Compruebe cada una contra las reglas de firewall que ha desplegado realmente. Publicar los puertos del controlador de dominio en internet no es un atajo que merezca la pena considerar.
Ejecute la unión y lea el error
Use el comando de unión admitido o el diálogo del sistema y capture el texto exacto del error. «El dominio especificado no existe o no se pudo contactar con él» apunta al descubrimiento o a la accesibilidad, no a las credenciales.
Si ya existe un objeto con el mismo nombre, no lo elimine por reflejo. Puede ser una cuenta precreada, y el endurecimiento de netjoin restringe algunos casos de reutilización según la propiedad y la directiva. Pida al propietario del directorio que inspeccione o corrija el objeto.
Una unión correcta es el punto medio, no la meta. El siguiente paso es el que el usuario prueba de verdad.
Planifique el primer inicio de sesión de dominio
Una unión completada no crea credenciales almacenadas en caché para cada usuario de dominio. En la primera pantalla de inicio de sesión, el portátil necesita una ruta hasta un DC antes de que ningún usuario haya iniciado sesión. Si su VPN de usuario solo arranca después del inicio de sesión, esa ruta falta. Eso es una laguna de diseño, no un fallo del cliente.
Use un flujo de trabajo admitido de antes del inicio de sesión o de túnel de dispositivo, una ruta de sitio existente o una alternativa aprobada para ese primer inicio. Después pruebe la secuencia completa: reinicie, llegue a la pantalla de credenciales, inicie sesión como el usuario de dominio previsto y confirme que el túnel se comporta según lo diseñado.
El cambio de usuario y la persistencia de la VPN varían según el cliente. No dé por hecho que una conexión iniciada como administrador local sobreviva a la sesión de otro usuario.
Conserve el acceso local de recuperación
Preserve una ruta de recuperación local aprobada antes de entregar el portátil. Si el primer inicio de sesión de dominio falla, querrá una forma de volver a entrar que no dependa del mismo túnel que acaba de fallar.
Anote lo que ha demostrado: resolución SRV, accesibilidad del DC, el error de unión, el método del primer inicio de sesión y la cuenta de recuperación. Ese registro es la diferencia entre una construcción repetible y un portátil que solo funciona en la oficina.