Toute différence entre DOMAIN \ nom d'utilisateur et nom d'utilisateur@domaine.local?

J'essaie de résoudre une erreur d'authentification obscure et j'ai besoin d'informations de fond.

• Existe-t-il une différence entre la façon dont Windows (et les programmes comme Outlook) traitent DOMAIN\usernameet username@domain.local?

• Quels sont les termes appropriés pour ces deux formats de nom d'utilisateur?

• Edit : En particulier, existe-t-il des différences dans la manière dont Windows authentifie les deux formats de nom d'utilisateur?

En supposant que vous ayez un environnement Active Directory:

Je crois que le format de barre oblique inversée DOMAIN \ USERNAME cherchera dans le domaine DOMAIN un objet utilisateur dont le nom de compte SAM est USERNAME.

Le nom d'utilisateur @ domain au format UPN recherchera dans la forêt un objet utilisateur dont le nom de principe d'utilisateur est username @ domain.

Maintenant, normalement, un compte utilisateur avec un nom de compte SAM USERNAME a un UPN USERNAME @ DOMAIN. Par conséquent, le format doit localiser le même compte, du moins si l’AD est pleinement fonctionnel. S'il existe des problèmes de réplication ou si vous ne parvenez pas à atteindre un catalogue global, le format de la barre oblique inverse peut fonctionner dans les cas où le format UPN échouera. Il peut également y avoir des conditions (anormales) dans lesquelles l'inverse s'applique - par exemple, si aucun contrôleur de domaine ne peut être atteint pour le domaine cible.

Toutefois, vous pouvez également configurer explicitement un compte d'utilisateur pour avoir un UPN dont le composant nom d'utilisateur est différent du nom de compte SAM et dont le composant de domaine est différent du nom du domaine.

L'onglet Compte dans Utilisateurs et ordinateurs Active Directory affiche le UPN sous le titre "Nom de connexion de l'utilisateur" et le Nom du compte SAM sous le titre "Nom de connexion de l'utilisateur (avant Windows 2000)". Donc, si vous rencontrez des problèmes avec des utilisateurs particuliers, je vérifierais qu'il n'y a pas de différences entre ces deux valeurs.

Remarque: il est possible que des recherches supplémentaires soient effectuées si la recherche que je décris ci-dessus ne trouve pas le compte d'utilisateur. Par exemple, le nom d'utilisateur spécifié est peut-être converti dans l'autre format (de manière évidente) pour voir si cela produit une correspondance. Il doit également exister une procédure permettant de rechercher des comptes dans des domaines approuvés ne figurant pas dans la forêt. Je ne sais pas où / si le comportement exact est documenté.

Pour compliquer encore les choses, les clients Windows mettent par défaut en cache les informations relatives aux ouvertures de session interactives, de sorte que vous puissiez vous connecter au même client même si les informations de votre compte utilisateur dans Active Directory sont inaccessibles.

On me corrigera peut-être à ce sujet, mais il n'y a pas vraiment de grande différence.

Domain \ User est le "vieux" format de connexion, appelé nom de connexion de niveau inférieur . Également connu sous les noms SAMAccountName et nom d'ouverture de session antérieure à Windows 2000 .

Utilisateur@Domaine.com est un nom principal d'utilisateur (UPN) . C'est le format de connexion "préféré", plus récent. C'est un nom de connexion de type Internet, qui doit correspondre au nom de messagerie de l'utilisateur. ( Voir MSDN )

Je pense que les raisons de se connecter avec des UPN sont essentiellement esthétiques: elles donnent en principe à vos utilisateurs de votre entreprise un nom unique leur permettant de se connecter à leurs postes de travail et pouvant également servir d’adresse électronique professionnelle.

edit: Plus d’élaboration - un autre avantage des UPN est que vous pouvez configurer plusieurs UPN valides avec lesquels vos utilisateurs peuvent se connecter. Encore une fois, en grande partie esthétique. Mais l’important est que toutes les applications ne sont pas compatibles avec les UPN, et c’est peut-être ce que vous rencontrez.

Edit # 2: J'aime la réponse de Harry Johnston ci-dessous sur les deux formats de recherche légèrement différents effectués. Cela a du sens, et surtout, cela pourrait en fait expliquer votre problème. :)

Le format barré ( DOMAIN\username) est en réalité l' NetBIOSéquivalent du nom DNS du domaine ( domain.mycompany.local).
Le NetBIOSnom est limité à 15 caractères et ne peut pas contenir de points, de traits de soulignement, etc.

Cette page explique plus en détail:
* Jeff Schertz, 2012-08-20, Présentation des formats de dénomination Active Directory (archivé ici .)

Comme mentionné par @ harry-johnston ci-dessus, il ne s’agit que du vieux format compatible avec NT4 et Windows 2000, mais il semble être resté comme un format favori (c’est moins difficile à taper!). Finalement, le support du format hérité peut passer de Windows.

C'est probablement une bonne idée de donner aux utilisateurs l'habitude d'utiliser le format UPN, car cela évite également les problèmes de connexion à un PC avec leur nom d'utilisateur et ne réalise pas que la zone de connexion Windows est définie par défaut sur l'adresse locale. Domaine PC (par exemple pc01\fred) ou lorsqu’ils se connectent à différents hôtes de postes de travail distants et doivent se rappeler d’inclure le domaine ainsi que leur nom d’utilisateur, car le client Bureau à distance peut mettre en cache un autre nom de domaine précédemment utilisé. Si vous vous en tenez au format UPN à chaque fois, le nombre d'appels au support technique diminue.

Il y a bien une différence entre ces deux là, seulement 99% des utilisateurs n'auront pas de problème avec ça. Je vais essayer d'expliquer la différence et quand un tel problème peut survenir.

Si vous utilisez domaine \ nom d'utilisateur lorsque vous essayez d'accéder à un partage de fichiers, DNS commence par résoudre le domaine, puis vérifie le nom d'utilisateur. Si vous utilisez nomutilisateur @ domaine, il vérifiera directement si l'utilisateur est sur la liste de contrôle d'accès (ACL) et a accès. Alors, qu'importe que vous puissiez penser ... eh bien, imaginez ceci:

1 contrôleur de domaine avec le nom DC01 et tous les clients reçoivent des DNS et se trouvent dans ce domaine. Vous voulez migrer et quelqu'un a ajouté un autre serveur du même nom. Ce dernier serveur deviendra également un contrôleur de domaine afin que le SAM local ne soit plus utilisé et dispose également d'un partage de fichiers.

Lorsque les utilisateurs se connectent au serveur, ils sont invités à fournir leurs informations d'identification. Si vous utilisez domaine \ nom d'utilisateur, il vérifiera d'abord le domaine actuel au lieu d'utiliser le nouveau domaine. Nous avons utilisé les comptes du nouveau domaine sur le partage de fichiers. Donc, une fois le courant continu trouvé et le nom d'utilisateur vérifié, il est introuvable. (Même si le nom d'utilisateur et le mot de passe sont trouvés et sont exactement identiques, cela ne fonctionnera pas, car il ne l'utilisera pas pour vérifier s'il est autorisé dans la liste de contrôle d'accès, mais il utilisera le SID. Le sid sera créé à la heure de création d'utilisateur dans AD et vous avez un changement de 1 dans un billion de dollars, c'est la même chose, c'est génial hein :-P).