¿Hay alguna diferencia entre DOMINIO \ nombre de usuario y nombre de usuario@dominio.local?

Estoy tratando de solucionar un oscuro error de autenticación y necesito información de fondo.

• ¿Hay alguna diferencia entre cómo procesan Windows (y programas como Outlook) DOMAIN\usernamey username@domain.local?

• ¿Cuáles son los términos adecuados para estos dos formatos de nombre de usuario?

• Editar : En particular, ¿hay alguna diferencia en cómo Windows autentica los dos formatos de nombre de usuario?

Suponiendo que tiene un entorno de Active Directory:

Creo que el formato de barra diagonal inversa DOMINIO \ NOMBRE DE USUARIO buscará en el dominio DOMINIO un objeto de usuario cuyo nombre de cuenta SAM sea USERNAME.

El formato nombre de usuario @ dominio UPN buscará en el bosque un objeto de usuario cuyo nombre de usuario principal sea nombre de usuario @ dominio.

Ahora, normalmente una cuenta de usuario con un Nombre de cuenta SAM de USERNAME tiene un UPN de USERNAME @ DOMAIN, por lo que cualquier formato debe ubicar la misma cuenta, al menos siempre que el AD sea completamente funcional. Si hay problemas de replicación o no puede llegar a un catálogo global, el formato de barra invertida podría funcionar en casos en los que fallará el formato UPN. También puede haber condiciones (anormales) en las que se aplica lo contrario, tal vez si no se puede llegar a los controladores de dominio para el dominio de destino, por ejemplo.

Sin embargo: también puede configurar explícitamente una cuenta de usuario para que tenga un UPN cuyo componente de nombre de usuario sea diferente del Nombre de cuenta SAM y cuyo componente de dominio sea diferente del nombre del dominio.

La pestaña Cuenta en Usuarios y equipos de Active Directory muestra el UPN bajo el encabezado "Nombre de inicio de sesión de usuario" y el Nombre de cuenta SAM bajo el encabezado "Nombre de inicio de sesión de usuario (anterior a Windows 2000)". Entonces, si tiene problemas con usuarios particulares, comprobaría que no haya discrepancias entre estos dos valores.

Nota: es posible que se realicen búsquedas adicionales si la búsqueda que describo anteriormente no encuentra la cuenta de usuario. Por ejemplo, quizás el nombre de usuario especificado se convierta al otro formato (de manera obvia) para ver si eso produce una coincidencia. También debe haber algún procedimiento para encontrar cuentas en dominios de confianza que no están en el bosque. No sé dónde / si se documenta el comportamiento exacto.

Solo para complicar aún más la solución de problemas, los clientes de Windows almacenarán de forma predeterminada información de caché sobre inicios de sesión interactivos exitosos, para que pueda iniciar sesión en el mismo cliente incluso si la información de su cuenta de usuario en Active Directory es inaccesible.

Puede que me corrijan en esto, pero en realidad no hay mucha diferencia.

Dominio \ Usuario es el formato de inicio de sesión "antiguo", denominado nombre de inicio de sesión de nivel inferior . También conocido por los nombres SAMAccountName y el nombre de inicio de sesión anterior a Windows 2000 .

User@Domain.com es un UPN - Nombre principal del usuario . Es el formato de inicio de sesión "preferido" más nuevo. Es un nombre de inicio de sesión de estilo de Internet, que debe correlacionarse con el nombre de correo electrónico del usuario. ( Ref. En MSDN )

Las razones para iniciar sesión con UPN creo que son en su mayoría cosméticas: hipotéticamente les dan a los usuarios de su empresa un solo nombre con el que iniciar sesión en sus estaciones de trabajo, que también pueden actuar como su dirección de correo electrónico corporativo.

editar: Más elaboración: otra ventaja de los UPN es que puede configurar más de un UPN válido para que sus usuarios inicien sesión. De nuevo, en gran parte cosmético. Pero lo importante es que no todas las aplicaciones son compatibles con UPN, y eso podría ser lo que está experimentando.

editar # 2: Me gusta la respuesta de Harry Johnston a continuación sobre los dos formatos de búsqueda ligeramente diferentes realizados. Tiene sentido, y lo más importante, podría explicar su problema. :)

El formato recortado ( DOMAIN\username) es en realidad el NetBIOSequivalente del nombre DNS del dominio ( domain.mycompany.local).
El NetBIOSnombre está limitado a 15 caracteres y no puede contener puntos, guiones bajos, etc.

Esta página explica con más detalle:
* Jeff Schertz, 2012-08-20, Descripción de los formatos de nomenclatura de Active Directory (Archivado aquí ).

Como se mencionó anteriormente en @ harry-johnston, en realidad es solo el antiguo formato compatible con NT4 y Windows 2000, pero parece haberse pegado como un formato favorito (¡menos escribir!). Eventualmente, el soporte para el formato heredado puede ir de Windows.

Probablemente sea una buena idea acostumbrar a los usuarios a usar el formato UPN, ya que también evita problemas en los que tienen problemas para iniciar sesión en una PC con su nombre de usuario y no se dan cuenta de que el cuadro de inicio de sesión de Windows está predeterminado en el local Dominio de PC (p. Ej. pc01\fred) O cuando se conectan a diferentes hosts de escritorio remoto y deben recordar incluir el dominio y su nombre de usuario porque el Cliente de escritorio remoto puede almacenar en caché otro nombre de dominio utilizado anteriormente. Cumplir con el formato UPN cada vez hace menos llamadas de soporte al final.

Definitivamente hay una diferencia entre esos dos, solo el 99% de los usuarios no tendrán problemas. Trataré de explicar la diferencia y cuándo puede ocurrir tal problema.

Si usa dominio \ nombre de usuario cuando intenta acceder a un recurso compartido de archivos, DNS primero resolverá el dominio y luego verificará el nombre de usuario. Si usa username @ domain, verificará directamente si el usuario está en la ACL (lista de control de acceso) y tiene acceso. Entonces, ¿qué importa que pienses ... bueno, imagina esto:

1 controlador de dominio con el nombre DC01 y todos los clientes obtienen dns y están en este dominio. Desea migrar y alguien agregó otro servidor con el mismo nombre. El último servidor también se convertirá en un DC, por lo que el SAM local ya no se usará y también tiene un recurso compartido de archivos.

Cuando los usuarios se conectan al servidor, se les solicita credenciales. Si usa dominio \ nombre de usuario, primero verificará el dominio actual en lugar de usar el nuevo dominio y usamos cuentas del nuevo dominio en el recurso compartido de archivos. Entonces, una vez que ha encontrado el CC actual y verifica el nombre de usuario, no se puede encontrar. (incluso si el nombre de usuario y la contraseña se encuentran y son exactamente iguales, no funcionará, ya que no usará el nombre de usuario para verificar si está permitido en la ACL, pero usará el SID. El sid se creará en el tiempo de creación de usuario en AD y tiene un cambio de 1 en un trillón que es lo mismo, genial eh :-P).