Entonces tengo dos bosques, llamémoslosalfa.ejemplo.comybravo.ejemplo.com. Los nombres NETBIOS de los dominios son ALPHA y BRAVO, respectivamente. Eso parecería implicar que no hay problema con el nombre del dominio, tienen dos nombres diferentes, tanto en lo que respecta a DNS como a NETBIOS.
Tengo los siguientes servidores como controladores de dominio:
- dc01.alpha.ejemplo.com
- dc02.alpha.ejemplo.com
- dc01.bravo.ejemplo.com
Cuando intento establecer una confianza forestal entre ALPHA y BRAVO como esta, aparece el mensaje "No hay servidores de inicio de sesión disponibles para atender la solicitud de inicio de sesión" cuando se trata de verificar la confianza. He encontradoalgunos hilos del foroen línea y escuché alguna evidencia anecdótica de que hay problemas al conectar dos dominios donde hay los mismos nombres para los controladores de dominio en ambos dominios. Esto no me parece tener sentido y parece que es un error en las herramientas de Microsoft.
No pensé que esto debería ser un problema, ya que dc01.alpha.example.com y dc01.bravo.example.com son obviamente dos máquinas diferentes, pero Windows no parece estar de acuerdo conmigo.
¿Me falta algún dato que me permita hacer funcionar esta configuración? Desafortunadamente, cambiar el nombre de los controladores de dominio es una mala respuesta para nosotros, porque el objetivo final es conectar muchos bosques y todos tienen controladores de dominio con el mismo nombre. Eso significaría cambiar el nombre de un montón de DC:.
Para que conste, cambiar el nombre de uno de los controladores de dominio me permite establecer una confianza, pero realmente no quiero tener que hacerlo en el mundo real si puedo evitarlo.
Todas las máquinas del laboratorio ejecutan Windows Server 2012 R2 actualizado con parches, pero sin revisiones especiales instaladas.
DNS se configura de la siguiente manera: en el dominio ALPHA, se agrega una zona auxiliar para bravo.example.com, que apunta a la dirección IP de dc01.bravo.example.com. A su vez, dc01.bravo.example.com utiliza dc01.alpha.example.com y dc01.bravo.example.com como DNS ascendente. Es una configuración un poco complicada (porque es un laboratorio...), pero el resultado funciona correctamente con la resolución DNS en ambos sentidos. dc01.bravo.example.com puede resolver nombres en bravo.example.com (porque tiene autoridad) y los nombres de alpha.exaple.com se resuelven correctamente porque el DNS ascendente tiene autoridad para ello. Los solucionadores en alfa pueden resolver los nombres de bravo correctamente debido a la zona stub (que se agrega a AD para que ambos servidores DNS la obtengan).
Además he probado:
- Cambiar de una zona stub a un reenviador condicional
- Administrar un fideicomiso forestal en lugar de un fideicomiso externo
Sin cambios en los síntomas.
Respuesta1
Sus problemas se deben a lo que se llama enrutamiento de sufijo de nombre. El siguiente artículo describe el problema: https://technet.microsoft.com/en-us/library/cc784334%28v=ws.10%29.aspx Afirma que netdom se puede utilizar para abordar el problema.
El artículo dice en parte
Sufijos de nombres de rutas a través de bosques
El enrutamiento de sufijo de nombre es un mecanismo utilizado para administrar cómo se enrutan las solicitudes de autenticación a través de bosques de Windows Server 2003 unidos por confianzas de bosque. Para simplificar la administración de las solicitudes de autenticación, cuando se crea inicialmente una confianza de bosque, todos los sufijos de nombres únicos se enrutan de forma predeterminada. Un sufijo de nombre único es un sufijo de nombre dentro de un bosque, como un sufijo de nombre principal de usuario (UPN), un sufijo de nombre principal de servicio (SPN) o un bosque DNS o un nombre de árbol de dominio, que no está subordinado a ningún otro sufijo de nombre. Por ejemplo, el nombre del bosque DNS microsoft.com es un sufijo de nombre único dentro del bosque microsoft.com.
Los bosques pueden contener varios sufijos de nombres únicos y todos los hijos de sufijos de nombres únicos se enrutan implícitamente. En dominios y confianzas de Active Directory, los sufijos de nombres aparecen con un asterisco (*) al principio debido a esto. Por ejemplo, si su bosque utiliza.microsoft.com como sufijo de nombre único, luego solicitudes de autenticación para todos los hijos de microsoft.com (.child.microsoft.com) se enrutará porque los dominios secundarios forman parte del sufijo de nombre microsoft.com.
Si existe una confianza de bosque entre dos bosques, entonces se pueden usar sufijos de nombres que no existen en un bosque para enrutar solicitudes de autenticación a un segundo bosque. Cuando un nuevo sufijo de nombre de niño (.child.widgets.com) se agrega a un sufijo de nombre único (.widgets.com), el sufijo del nombre secundario heredará la configuración de enrutamiento del sufijo de nombre único al que pertenece. Cualquier nuevo sufijo de nombre único que se cree después de que se haya establecido una confianza de bosque será visible en el cuadro de diálogo Propiedades de confianza de bosque después de verificar la confianza. Sin embargo, el enrutamiento para esos nuevos sufijos de nombres únicos estará deshabilitado de forma predeterminada. Para obtener más información sobre cómo verificar una confianza, consulte Verificar una confianza.
Cuando se detecta un sufijo de nombre duplicado, el enrutamiento para el sufijo de nombre más nuevo se desactivará de forma predeterminada. Para obtener más información sobre cómo enrutar sufijos de nombres, consulte Habilitar o deshabilitar el enrutamiento de un sufijo de nombre existente. Los administradores pueden utilizar el cuadro de diálogo Propiedades de confianza del bosque para evitar manualmente que las solicitudes de autenticación para sufijos de nombres específicos se enruten a un bosque.
Notas • No agregue el signo @ al sufijo UPN ni a un nombre de usuario. Cuando las solicitudes de autenticación se enrutan a un bosque confiable, todos los caracteres antes del primer símbolo @ se interpretan como el nombre de usuario y todo lo que sigue al primer símbolo @ como el sufijo UPN.
• La Autoridad de Seguridad Local (LSA) bloqueará el enrutamiento a cualquier sufijo UPN que no sea un nombre DNS válido. Por ejemplo, agregar un símbolo @ a un sufijo UPN hará que se deshabilite automáticamente.