J'essaie de résoudre une obscure erreur d'authentification et j'ai besoin de quelques informations de base.
Y a-t-il une différence entre la façon dont Windows (et des programmes comme Outlook) traite DOMAIN\username y username@domain.local ?
Quels sont les termes appropriés pour ces deux formats de nom d'utilisateur ?
Modifier : En particulier, y a-t-il des différences dans la façon dont Windows authentifie les deux formats de nom d'utilisateur ?
En supposant que vous avez un environnement Active Directory :
Je crois que le format backslash DOMAIN \USERNAME recherchera le domaine DOMAIN pour un objet utilisateur dont le nom de compte SAM est USERNAME.
Le format UPN username@domain recherchera dans la forêt un objet utilisateur dont le nom de principe utilisateur est username@domain.
Maintenant, normalement un compte utilisateur dont le nom de compte SAM est USERNAME a un UPN de USERNAME@DOMAIN, donc l'un ou l'autre format devrait localiser le même compte, du moins si l'AD est pleinement fonctionnel. S'il y a des problèmes de réplication ou si vous ne pouvez pas atteindre un catalogue global, le format backslash peut fonctionner dans les cas où le format UPN échoue. Il peut également y avoir des conditions (anormales) dans lesquelles l'inverse s'applique - peut-être si aucun contrôleur de domaine ne peut être atteint pour le domaine cible, par exemple.
Cependant : vous pouvez aussi configurer explicitement un compte utilisateur pour qu'il ait un UPN dont le composant username est différent du nom de compte SAM et dont le composant domain est différent du nom du domaine.
L'onglet Compte dans Active Directory Users and Computers montre le UPN sous la rubrique "Nom de connexion de l'utilisateur" et le nom de compte SAM sous la rubrique "Nom de connexion de l'utilisateur (pré-Windows 2000)". Donc, si vous avez des problèmes avec des utilisateurs particuliers, je vérifierais qu'il n'y a pas de divergence entre ces deux valeurs.
Note : 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 utilisateur. Par exemple, peut-être que le nom d'utilisateur spécifié est converti dans l'autre format (de la manière évidente) pour voir si cela produit une correspondance. Il doit également y avoir une procédure pour trouver les comptes dans les domaines de confiance qui ne sont pas dans la forêt. Je ne sais pas où/si le comportement exact est documenté.
Pour compliquer encore le dépannage, les clients Windows mettent par défaut en cache les informations relatives aux connexions interactives réussies, de sorte que vous pouvez vous connecter au même client même si les informations relatives à votre compte utilisateur dans l'Active Directory sont inaccessibles.
On me corrigera peut-être sur ce point, mais il n'y a pas vraiment de différence.
Domaine \User est l'"ancien" format d'ouverture de session, appelé nom de connexion de niveau inférieur . Également connu sous les noms SAMAccountName y nom de connexion pré-Windows 2000 .
User@Domain.com est un UPN - Nom principal de l'utilisateur . C'est le format de connexion "préféré", plus récent. Il s'agit d'un nom de connexion de style Internet, qui devrait correspondre au nom de courriel de l'utilisateur. ( Réf. à MSDN )
Je pense que les raisons de se connecter avec des NUP sont surtout d'ordre cosmétique - ils donnent hypothétiquement aux utilisateurs de votre entreprise un nom unique avec lequel ils peuvent se connecter à leurs postes de travail et qui peut également servir d'adresse électronique d'entreprise.
éditer : Plus de détails - un autre avantage des UPN est que vous pouvez définir plusieurs UPN valides pour que vos utilisateurs puissent se connecter. Là encore, il s'agit d'une question d'ordre cosmétique. Mais l'important est que toutes les applications ne sont pas compatibles avec les NUP, et c'est peut-être ce que vous rencontrez.
edit #2 : J'aime la réponse de Harry Johnston ci-dessous concernant les deux formats de recherche légèrement différents effectués. Elle est logique et, surtout, elle pourrait expliquer votre problème :)
Il n'est pas fait mention des UPN dans la RFC 822, "Standard for the format of ARPA Internet text messages". Les UPN sont une "invention" d'Active Directory qui lie les informations Kerberos et LDAP afin de fournir des services de signature unique (SSO) à travers un domaine (ou "realm") de systèmes informatiques associés.
Ah, désolé je tirais mes informations de msdn.microsoft.com/fr/us/library/Windows/desktop/ ... Je modifierai ma réponse si je trouve la bonne.
Le format barré ( DOMAIN\username ) est en fait le NetBIOS équivalent du nom DNS du domaine ( domain.mycompany.local ).
Le site NetBIOS Le nom est limité à 15 caractères et ne peut pas contenir de points, de caractères de soulignement, etc.
Cette page l'explique plus en détail :
Comme l'a mentionné @harry-johnston ci-dessus, il s'agit en fait uniquement de l'ancien format compatible avec NT4 et Windows 2000, mais il semble être resté le format préféré (il est moins long à taper !). A terme, le support de l'ancien format pourrait être abandonné par Windows.
C'est probablement une bonne idée de donner aux utilisateurs l'habitude d'utiliser le format UPN, car cela permet également d'éviter les problèmes lorsqu'ils ont des difficultés à se connecter à un PC avec leur nom d'utilisateur et qu'ils ne réalisent pas que la boîte de connexion de Windows a choisi par défaut le domaine du PC local (par exemple. pc01\fred ) ou lorsqu'ils se connectent à différents hôtes de bureau à distance et doivent se rappeler d'inclure le domaine ainsi que leur nom d'utilisateur parce que le client du bureau à distance peut mettre en mémoire cache un autre nom de domaine précédemment utilisé. S'en tenir au format UPN à chaque fois permet de réduire le nombre d'appels au support technique.
Il y a définitivement une différence entre ces deux-là, mais 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 le domaine \username Lorsque vous essayez d'accéder à un partage de fichiers, le DNS résout d'abord le domaine, puis vérifie le nom d'utilisateur. Si vous utilisez username@domain, il vérifiera directement si l'utilisateur figure dans la liste de contrôle d'accès (ACL) et s'il a le droit d'accès. Vous vous demandez peut-être ce que cela change... Eh bien, imaginez ceci :
1 contrôleur de domaine avec le nom DC01 et tous les clients obtiennent des noms de domaine et sont dans ce domaine. Vous voulez migrer et quelqu'un a ajouté un autre serveur avec le même nom. Ce dernier serveur deviendra également un DC, de sorte que le SAM local ne sera plus utilisé et possède également un partage de fichiers.
Lorsque les utilisateurs se connectent au serveur, ils sont invités à fournir des informations d'identification. Si vous utilisez le domaine \username il vérifiera d'abord le domaine actuel au lieu d'utiliser le nouveau domaine et nous avons utilisé les comptes du nouveau domaine sur le partage de fichiers. Donc, une fois qu'il a trouvé le domaine actuel et vérifié le nom d'utilisateur, il ne peut pas être trouvé. ( même si le nom d'utilisateur et le mot de passe sont trouvés et sont exactement les mêmes, cela ne fonctionnera pas car il n'utilisera pas le nom d'utilisateur pour vérifier s'il est autorisé dans l'ACL mais il utilisera le SID. Le sid sera créé au moment de la création de l'utilisateur dans AD et vous avez une chance sur un billion qu'il soit le même, super hein:-P ).
-1. Je n'arrive vraiment pas à suivre ce que tu dis là. Lorsque vous dites "Lorsque les utilisateurs se connecteront au serveur", de quel serveur parlez-vous, l'ancien DC01 ou le nouveau DC01 ? Qu'est-il arrivé à l'ancien DC01 de toute façon, a-t-il été mis hors service, renommé, retiré du domaine, ou quoi ? A-t-il d'abord été correctement rétrogradé ? Qu'entendez-vous par "nouveau domaine", puisque vous n'avez décrit la création d'un nouveau domaine à aucun moment ? Si vous utilisez "domaine \username " il devrait recherche toujours le domaine que vous avez explicitement spécifié, décrivez-vous un cas où il ne le fait pas ?
De plus, "il n'utilisera pas le nom d'utilisateur pour vérifier s'il est autorisé dans l'ACL mais il utilisera le SID" est le comportement attendu - il devrait toujours le faire, que vous utilisiez ou non le domaine. \username ou nom d'utilisateur@domaine. Parlez-vous d'un cas où il y a deux domaines avec le même nom, ou quelque chose de pathologique similaire ?
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
0 votes
Vous pourriez être intéressé par l'un de mes question précédente s.