none
Nom d'ouverture de session de l'utilisateur (antérieur à Windows 2000) RRS feed

  • Question

  • Bonjour,

    Je viens de me rendre compte que dans les propriétés des comptes utilisateur AD de mon infra, il n'y a rien de complété dans le champ

    "Nom d'ouverture de session de l'utilisateur"

    mais seulement dans le champ

    "Nom d'ouverture de session de l'utilisateur (antérieur à Windows 2000)".

    Est-ce normal ou est-ce que cela peut poser un problème pour une quelconque raison ?

    Merci d'avance.

    jeudi 8 juillet 2021 14:24

Toutes les réponses

  • Est-ce normal ou est-ce que cela peut poser un problème pour une quelconque raison ?

    Ce n'est pas normal, mais cela arrive, par exemple suite à des migrations d'ancien domaine. L'AD vérrifie qu'il n'y a pas de noms en double, mais la valeur null n'est pas interdite. Oui il peut y avoir des impacts sur des protocoles d'authentifications comme Kerberos.

    Autre exemple la synchronisation des comptes avec Azure AD...

    un simple script Powershell permet de renseigner cette valeur.


    lundi 12 juillet 2021 05:49
    Modérateur
  • Est-ce normal ou est-ce que cela peut poser un problème pour une quelconque raison ?

    Ce n'est pas normal, mais cela arrive, par exemple suite à des migrations d'ancien domaine. L'AD vérrifie qu'il n'y a pas de noms en double, mais la valeur null n'est pas interdite. Oui il peut y avoir des impacts sur des protocoles d'authentifications comme Kerberos.

    Autre exemple la synchronisation des comptes avec Azure AD...

    un simple script Powershell permet de renseigner cette valeur.


    En fait je m'en suis rendu compte en testant justement un script powershell pour l'import des users dans l'AD.

    J'ai testé l'import sur un contrôleur de domaine en exploitation, dans une OU de test, dans lequel les users existant ont bien ce champ renseigné et l'import m'a renvoyé des erreurs concernant UPN en disant qu'ils ne sont pas unique dans la forêt. Et en effet, il y avait bien des comptes existants qui entraient en conflit au niveau de l'UPN lors de l'import, puisque les logins sont du type "première lettre du prénom+nom". Et le système ne règle pas ce problème de lui même.

    Du coup si mes users existent déjà dans l'AD, je risque d'avoir des doublons en appliquant le renseignement de ce champ pour tous les users du domaine et de la forêt car il va forcément y avoir des doublons.

    Concernant le script powershell, j'imagine que tu pensais à un foreach qui irait récupérer le username et qui l'appliquerait au champ UserPrincipalName via Set-ADuser ?

    Merci.

    • Modifié Support57 lundi 12 juillet 2021 06:59
    lundi 12 juillet 2021 06:49
  • Bonjour Support57,

    J'espère que tu vas bien.


    Le nom de connexion pré-Windows 2000 s'appelle le nom de compte SAM et existe pour la compatibilité avec les anciens systèmes (bien qu'il soit encore très couramment utilisé dans les configurations modernes), il a une limite de 20 caractères et fonctionne en conjonction avec le nom de domaine NETBIOS, en votre exemple, LZ pour donner le nom d'utilisateur LZ\nom d'utilisateur
               


    Salutations,
    Pont Karthick
    lundi 12 juillet 2021 07:13
  • Du coup si mes users existent déjà dans l'AD, je risque d'avoir des doublons en appliquant le renseignement de ce champ pour tous les users du domaine et de la forêt car il va forcément y avoir des doublons.

    Non tu devrais avoir des erreurs mais pas  de doublon des UPN dans la forêt.

    Concernant le script powershell, j'imagine que tu pensais à un foreach qui irait récupérer le username et qui l'appliquerait au champ UserPrincipalName via Set-ADuser ?

    Dans ce genre, en commençant par un get-aduser pour récupérer tous les comptes qui n'ont pas d'UPN de renseigner.


    lundi 12 juillet 2021 11:37
    Modérateur
  • Les comptes en erreurs par contre je vais devoir les supprimer et les recréer pour ne pas qu'ils se heurtent à un UPN déjà existant ?

    Lors d'un import d'utilisateurs avec powershell, faut-il implicitement définir le champ UPN dans les paramètres ?
    Le contrôleur ne le fait pas de lui même ?

     
    lundi 12 juillet 2021 16:16
  • Bonjour Pont,

    En effet, je connais NETBIOS, je me posais seulement la question de savoir si cela pouvait avoir un impact de ne pas utiliser le champ UPN dans la mesure où je n'ai jamais vraiment rencontré de problème sans ça.

    Cordialement,

    lundi 12 juillet 2021 16:18
  • Les comptes en erreurs par contre je vais devoir les supprimer et les recréer pour ne pas qu'ils se heurtent à un UPN déjà existant ?

    Non on peut mettre à jour les comptes existants

    Lors d'un import d'utilisateurs avec powershell, faut-il implicitement définir le champ UPN dans les paramètres ?

    Oui

    Le contrôleur ne le fait pas de lui même ?

    Non avec Powershelll, il n'y a rien d'autre que la commande, rien n'est fait automatiquement par le DC.

    lundi 12 juillet 2021 16:42
    Modérateur
  • Et pour la modification des comptes existants avec powershell, je prends quoi comme source pour le champ UPN? Le SamAccountName ?


    • Modifié Support57 lundi 12 juillet 2021 17:31
    lundi 12 juillet 2021 17:23
  • SamAccounname + "@" + nom_de_domaine par exemple

    L'UPN a un format email ...

    Tu peux aussi créer des suffixes personnalisés 

    http://pbarth.fr/node/17

    lundi 12 juillet 2021 20:21
    Modérateur