Entiendo que, como usted ha indicado, usar los trabajos del IP pero no el nombre del “DNS”, o FDQN mientras que tengo gusto de llamarlo.
La diferencia en el proceso o la “encaminamiento” de la petición de authenticar es la edición como usted la ha indicado.
Examinemos las diferencias: El XP VM se abre una sesión al dominio, y por lo tanto tiene un certificado en el listo, y sabe el nombre fully-qualified y la contraseña del usuario. La conexión por lo tanto automática o del “paso”.
¿Cómo simulamos esto en el servidor?
Cuando usted abre una sesión del servidor, usar el IE incorporado, usted está utilizando el administrador (o un admin-tipo) para las credenciales.
Al IIS esto parece
[email protected] O NETBIOSNAME/username O username.domain.extension O username@NETBIOSNAME, O CN=administrator, OU=etc, OU=etc, etc.
Esto deja muchas iteraciones para encontrar la conexión apropiada para un usuario.
AL MENOS: cuando usted utiliza el IP, el IE no remite las credenciales de Windows. ESCONDE HACIA FUERA ESOS CAMPOS.
La falta más probable es que el servidor está añadiendo el dominio a un Domain Name ya existente; como esto: username.domain.com.domain.com
Este usuario no existe, y no puede abrirse una sesión. Nevermind que usted acaba de mecanografiar en el username o username.domain.com
Puesto que usted indica que el XP y los servidores arracimados todo el punto al exacto el mismo DNS, después el problema deben mentir en uno de tres lugares:
1. El IE
2. Los ajustes del dominio en el interfaz del NIC son de alguna manera diferentes que la unidad de XP. Mirar los ajustes del DNS y comparar el XP VM con el servidor. Mirar los ajustes del dominio.
3. El IIS -- esto podía ser una edición con las credenciales requeridas y las formas así como el directorio virtual.
Debe haber un error en el espectador del acontecimiento cuando la conexión falla. Le dirá qué edición usted está haciendo frente, por lo menos en el sentido que identificará nombre o contraseña incorrecto (recordar, no importa que usted la ponga en la derecha, él importa que convenga con el formato IIS lo quiera y que el formato está alterado cuando usted está en la máquina local), o algo como “requiere SSH” o algo.
Mi conjetura es: Los servidores están agregando etiquetas o algo del dominio cuando usted se abre una sesión directo de ellos. Si usted utiliza un FQDN, el DNS proporciona el IP, el SRV registra etc. etc. Esta información auto-se está agregando a las credenciales que usted mecanografía adentro. Este problema exacto sucede en intercambio no-arracimado si usted abre una sesión al servidor como admin local (cuando el servidor del intercambio no es una C.C.). El nombre del admin local es seguido por el nombre de la máquina (admin.termserver1) y entonces cuando usted intenta utilizar OWA, su nombre sale como administrator.domain.extension@termserver1
Falla. Utilizar el IP, y acepta mecanografiado en creds.
