Meilleures pratiques en matière de normes de noms d'utilisateur : Éviter les problèmes

C'est un problème chronique avec les grands systèmes de gestion des identités qui tentent de coller ensemble des systèmes hétérogènes. Invariablement, vous serez limité au plus petit dénominateur commun, qui est trop souvent une limite de 8 caractères ASCII-alpha-numériques grâce à un système (probablement ancien) de type Unix situé quelque part dans les entrailles du centre de données. Il est peu probable que ces systèmes modernes sophistiqués, capables de prendre des noms d'utilisateur UTF8 de longueur arbitraire, soient utilisés.

J'ai passé 7 ans dans un établissement d'enseignement supérieur où nous devions trouver des noms d'utilisateur à 8 caractères pour 5000 nouveaux étudiants chaque année. Au moment où je suis parti, nous avions réussi à trouver des noms uniques pour 15 années d'étudiants. C'est possible, M. smitj510.

Des choses qui vous rendront la vie infiniment plus facile :

• Déterminez quel est votre plus petit dénominateur commun, ce qui nécessite d'analyser chaque partie de votre système de gestion de l'identité pour découvrir quelles sont les limites.
  • Ce vieux système Solaris 7 impose la limite de 8 caractères.
  • Les applications critiques qui utilisent les données d'identité ont leurs propres limites que vous devrez prendre en compte.
    • Peut-être s'attendent-ils à ce que les données utilisateur provenant de LDAP soient conformes à une "norme" qui leur est propre.
    • Peut-être que la base de données d'authentification qu'ils utilisent ne peut traiter que certaines données formatées.
    • Peut-être que ce système compatible avec Windows utilise encore SAMAccountName deux décennies après que cela ait cessé d'être une bonne idée.
• Disposez d'une table de base de données avec une liste du seul véritable identifiant (ce nom de compte à 8 caractères), avec des liens/champs listant les identifiants alternatifs tels que firstname.lastname ou tout autre chose qui pourrait survenir.
  • Un logiciel standard peut faire des choses vraiment bizarres et peu conviviales pour l'IDM, comme utiliser un identifiant numérique pour le nom du compte, ou générer automatiquement des identifiants de compte sur la base des données du profil. Tout cela se retrouve également dans la table de la base de données.
  • Cela aide également les personnes dont le nom comporte des caractères non [a-z|0-9], comme Harry O'Neil, ou des caractères non ASCII, comme Alžbêta.
• Lorsque vous élaborez vos processus de synchronisation des comptes, exploitez cette table de base de données pour vous assurer que les bons comptes reçoivent les bonnes mises à jour. Lorsque les noms changent (mariage, divorce, autres), vous voulez que ces changements se propagent aux bons endroits.
  • Configurez les bases de données d'identité elles-mêmes pour empêcher les modifications locales lorsque c'est possible, et les processus d'entreprise pour les décourager fortement lorsque ce n'est pas possible. Appuyez-vous sur le processus central de synchronisation des comptes pour tout ce que vous pouvez.
• Exploitez les systèmes d'alias partout où vous le pouvez, par exemple dans les courriers électroniques.
• Considérez que l'identifiant à 8 caractères est immuable, car la modification de ce champ peut provoquer de nombreux maux de tête chez le personnel informatique, qui doit recréer des comptes.
  • Cela suggère un identifiant de compte pas dérivées des données nominatives, puisque le mariage/divorce/ordonnance judiciaire peuvent modifier les données nominatives au fil du temps.
• Mettez en place un système pour les exceptions, car il y en aura toujours.
  • Un divorce horrible et cet UID de 8 caractères généré par les données du nom vous rappelle des souvenirs douloureux chaque fois que vous devez le saisir ? Soyez gentil avec vos utilisateurs et prévoyez un mécanisme pour ces changements, mais restez discret.
• Faites ce que vous pouvez pour autoriser les connexions à plusieurs noms d'utilisateur dans les systèmes où cette option est possible.
  • Certaines personnes aiment leur uid à 8 caractères, d'autres préfèrent firstname.lastname@example.com. Soyez flexible, faites-vous des amis.
  • Parfois, cela nécessite de mettre en avant vos systèmes basés sur le web avec un système de gestion de l'information. authentification unique comme CAS ou un effet de levier saml . Vous serez surpris de voir combien de systèmes standard peuvent prendre en charge des cadres SSO de ce type, alors ne vous découragez pas.

En d'autres termes, traitez-le comme un problème de base de données, car c'est ce qu'il est. Choisissez une clé primaire pour une compatibilité maximale avec vos systèmes (probablement 8 caractères), construisez une table de consultation pour permettre aux systèmes de traduire les identifiants locaux en clé primaire, et concevez vos systèmes de synchronisation des données pour qu'ils puissent gérer différents identifiants.

Vos questions en particulier :

• Quelle est la meilleure limite de longueur de nom d'utilisateur à utiliser pour maintenir la compatibilité entre toutes les utilisations ?

Il n'y a pas de telle chose. Il n'y a que "vos" utilisations, qui peuvent inclure vos utilisations futures. Nous n'avons aucune idée de ce qu'elles sont.

• Quels sont les personnages à éviter ?

Cela dépendra des systèmes informatiques auxquels vous avez affaire. Windows, par exemple, n'a aucun problème avec un point dans le nom d'utilisateur. En fait, l'UPN est formaté comme une adresse électronique, qui autorise un point.

Mes autres réflexions :

• Ne laissez pas vos utilisateurs vous le demander - dites-leur quelle est la norme et soyez ouvert à ce que l'entreprise (et non les utilisateurs individuels) demande des modifications de la norme en fonction de l'évolution des besoins.
• Prévoyez une "politique d'exception" dans la norme, afin de pouvoir aider les pauvres Susan Penington et Mary Utt (d'après les commentaires ci-dessus) sans avoir à impliquer un vice-président. Donner une bonne image de l'informatique, n'est-ce pas ?

Mon expérience m'a montré que, pour une entreprise suffisamment grande, toute décision que vous prenez posera toujours des problèmes. Même si cela fonctionne aujourd'hui, il y aura toujours le système que vous mettrez en place demain et qui aura des problèmes avec la norme précédente (problèmes de longueur, de caractères, etc.).

Assurez-vous de savoir si la pression exercée sur Firstname.Lastname concerne le courrier électronique et pas nécessairement les noms de connexion. J'ai du mal à croire que l'utilisateur souhaite taper "John.Smith" au lieu de "jsmith" lorsqu'il se connecte, mais je suis beaucoup plus convaincu qu'il souhaite avoir "John.Smith@company.com" comme adresse électronique. Comme le souligne @Mfinni, les utilisateurs ont toujours la possibilité d'avoir plusieurs alias de messagerie, des redirections, etc. Le simple fait de faire savoir aux utilisateurs qu'ils ont la possibilité de dissocier leur nom d'utilisateur de leur adresse électronique peut changer la dynamique de la demande.

Pour les systèmes Unix et Linux, {premierInitial}{lastname} est clairement idéal.

...

pour des raisons qui devraient être évidentes au vu du nom associé à ce compte.

Une chose dont il faut être conscient lors de l'établissement de normes de nommage entre plates-formes est un problème cosmétique particulier dans ps sous Linux (et peut-être d'autres OS Unix). Vous pouvez vous en préoccuper ou non (mais cela peut être alarmant pour quelqu'un qui ne s'y attend pas...). J'ai eu des gens de la sécurité qui ont tressailli sur ce point).

La colonne UID n'affichera que 8 caractères maximum du nom d'utilisateur. Si le nom d'utilisateur est plus long que 8 caractères, il basculera vers l'impression de l'UID numérique réel. Vous pouvez contourner ce problème en ayant un format de colonne ps personnalisé qui contient le champ USER, mais UNIQUEMENT si USER est la dernière colonne (d'après mes tests empiriques).

La plupart des gens ne se soucient probablement pas de cela, mais si vous faites une sorte de traitement de la sortie de ps et que vous vous attendez à ce que les vrais noms d'utilisateurs apparaissent, vous devriez faire attention à la longueur de vos noms (sinon, vous devrez mettre des hacks dans votre code pour que ps fasse la bonne chose).

Par exemple :

Voici le format de colonne par défaut pour le listing plein format. Notez que mon uid est au format numérique parce que mon nom d'utilisateur a > 8 caractères.

[tcampbell@tst-agg1 ~]$ ps -f
  UID        PID  PPID  C STIME TTY          TIME CMD
 2108      1368  1367  0 Jan10 pts/3    00:00:00 -bash
 2108     22303  1368  0 12:07 pts/3    00:00:00 ps -f

Recréons-le en utilisant un format de colonne personnalisé. Notez que j'ai ajouté la colonne USER. Notez qu'elle est également au format numérique.

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd    
  UID USER      C STIME TT           TIME CMD
 2108 2108      0 Jan10 pts/3    00:00:00 -bash
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty,time,cmd

Déplaçons USER à la fin de la ligne. Il sera étendu à la sortie "droite".

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd,user
  UID USER      C STIME TT           TIME CMD                         USER
 2108 2108      0 Jan10 pts/3    00:00:00 -bash                       tcampbell
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty, tcampbell

Mais, dès que nous ajoutons quelque chose de nouveau à la fin de la liste des colonnes, elle revient à la forme numérique.

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd,user,pid
  UID USER      C STIME TT           TIME CMD                         USER       PID
 2108 2108      0 Jan10 pts/3    00:00:00 -bash                       2108      1368
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty, 2108     21756