Meilleures pratiques dans les normes de nom d'utilisateur: éviter les problèmes
Je voudrais savoir ce que les gens vivent avec les noms d'utilisateur standard. J'ai toujours été dans des endroits qui utilisaient {firstInitial} {lastname} (parfois avec une limite de longueur). Maintenant, j'ai des utilisateurs qui veulent {prénom}. {Lastname} - et maintenant il apparaît que la période peut causer des problèmes.
Plus précisément:
- Quelle est la meilleure limite de longueur de nom d'utilisateur à utiliser pour maintenir la compatibilité entre toutes les utilisations?
- Quels caractères faut-il éviter?
MISE À JOUR: La raison pour laquelle je n'ai pas mentionné de détails est que je voulais être assez général pour gérer tout ce qui pourrait survenir à l'avenir. Cependant, cela peut être trop général d'une exigence (tout peut arriver, non?).
Voici notre environnement: Ubuntu Server Lucid Lynx 10.04 LTS, Red Hat Enterprise Linux 5.6 et supérieur, Windows Server 2003 et Windows 2000 Server (avec Active Directory en mode natif Windows 2000), Zimbra 7.x pour le courrier et OpenLDAP dans un proche avenir avenir.
MISE À JOUR: Je devrais mentionner (pour être complet) que j'ai vu cette question (même si cela n'a pas répondu à ma question posée) et aussi ceci publication sur le Web , tous deux très instructifs.
Il s'agit d'un problème chronique avec les grands systèmes de gestion des identités qui tentent de coller des systèmes hétérogènes. Invariablement, vous serez limité au plus petit dénominateur commun, qui est trop souvent une limite ASCII-alpha-numérique à 8 caractères grâce à un système Unix (probablement hérité) quelque part dans les entrailles du centre de données. Ces systèmes modernes sophistiqués peuvent prendre des noms d'utilisateur UTF8 de longueur arbitraire sont peu susceptibles d'être 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. Nous avions réussi à trouver des noms uniques pour 15 ans d'étudiants au moment de mon départ. Cela peut être fait, M. smitj510
Des choses qui vous faciliteront considérablement la vie:
- Déterminez quel est votre plus petit dénominateur commun, ce qui nécessite d'analyser toutes les parties de votre système de gestion des identités pour découvrir quelles sont les limites.
- Cet ancien système Solaris 7 force la limite de 8 caractères.
- Les applications critiques qui utilisent des 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 de LDAP soient conformes à un "standard" unique.
- Peut-être que la base de données d'authentification qu'ils utilisent ne peut gérer que certaines données formatées.
- Peut-être que ce système compatible avec Windows utilise toujours SAMAccountName deux décennies après que cela ne soit plus une bonne idée.
- Avoir une table de base de données avec une liste du One True Identifier (ce nom de compte à 8 caractères), avec des liens/champs listant des ID alternatifs comme
firstname.lastnameou toute autre chose qui pourrait apparaître.- Un logiciel standard peut faire des choses vraiment étranges et hostiles à l'IDM, comme utiliser un ID numérique pour le nom du compte, ou générer automatiquement des ID de compte en fonction des données de profil. Tout cela va aussi dans la table de la base de données.
- Cela aide également les personnes dont le nom n'est pas [a-z | 0-9] comme Harry O'Neil ou qui ne sont pas ASCII comme Alžbêta.
- Lorsque vous créez vos processus de synchronisation de compte, tirez parti de 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é réelles elles-mêmes pour empêcher les modifications locales lorsque cela est possible, et les processus métier pour décourager fortement cela lorsque cela n'est pas possible. Faites confiance au processus central de synchronisation des comptes pour tout ce que vous pouvez.
- Tirez parti des systèmes d'alias partout où vous le pouvez, comme dans les e-mails.
- Considérez l'ID de 8 caractères immuable, car changer ce champ peut déclencher BEAUCOUP de chagrin parmi le personnel informatique car les comptes doivent être recréés.
- Cela suggère un ID de compte non dérivé des données de nom, car le mariage/divorce/ordonnance du tribunal peut modifier les données de nom au fil du temps.
- Avoir un système en place 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 de nom vous apportent des souvenirs déchirants à chaque fois que vous devez y entrer? Soyez gentil avec vos utilisateurs et autorisez un mécanisme pour ces changements, mais gardez le silence.
- Faites ce que vous pouvez pour autoriser plusieurs connexions de nom d'utilisateur dans les systèmes où c'est une option
- Certaines personnes aiment leur UID à 8 caractères, d'autres comme [email protected]. Soyez flexible, faites-vous des amis.
- Parfois, cela nécessite de faire face à vos systèmes Web avec un cadre authentification unique comme CAS ou un effet de levier saml . Vous serez surpris du nombre de systèmes prêts à l'emploi pouvant prendre en charge des frameworks SSO comme celui-ci, ne vous découragez donc pas.
Autrement dit, traitez-le comme un problème de base de données car c'est ce que c'est. Choisissez une clé primaire pour une compatibilité maximale avec vos systèmes (probablement 8 caractères), créez une table de recherche pour permettre aux systèmes de traduire les ID locaux en clé primaire et concevez vos systèmes de synchronisation de données pour gérer divers ID.
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 rien comme ça. Il n'y a que "vos" utilisations, qui peuvent inclure vos utilisations futures. Nous n'avons aucune idée de ce que c'est.
- Quels caractères faut-il éviter?
Cela dépendra des systèmes informatiques avec lesquels vous traitez. 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 e-mail, ce qui permet une période.
Mes autres réflexions:
- Ne laissez pas vos utilisateurs demander - dites-leur quelle est la norme et soyez ouvert à l'entreprise (pas aux utilisateurs individuels) qui demande des modifications à la norme à mesure que les exigences changent.
- Faites une "politique d'exception" dans la norme, afin que vous puissiez aider les pauvres Susan Penington et Mary Utt (d'après les commentaires ci-dessus) sans avoir à faire appel à un vice-président. Faites en sorte que l'informatique soit bonne, non?
D'après mon expérience, pour une entreprise suffisamment grande, toute décision que vous prendrez aura toujours des problèmes. Même si cela fonctionne aujourd'hui, il y a toujours le système que vous implémenterez demain qui a des problèmes avec la norme précédente (problèmes de longueur, problèmes de caractères, etc.).
Assurez-vous de savoir si le Push for Firstname.Lastname se rapporte à l'e-mail et pas nécessairement aux noms de connexion. Je trouverais difficile de croire que l'utilisateur veut taper "John.Smith" au lieu de "jsmith" lors de la connexion, mais je suis beaucoup plus convaincu qu'il veut "[email protected] "comme son adresse e-mail. Comme le souligne @Mfinni, les utilisateurs ont toujours la possibilité de disposer de plusieurs alias de messagerie, de transferts, etc.
Pour les systèmes Unix et Linux, {firstInitial} {lastname} est clairement idéal.
...
pour des raisons qui devraient être évidentes d'après le nom associé à ce compte.
Une chose à savoir lors de la définition de normes de dénomination sur toutes les plates-formes est un problème cosmétique particulier dans ps sous Linux (et éventuellement d'autres systèmes d'exploitation Unix). Vous pouvez ou non vous en soucier (mais cela peut être alarmant pour quelqu'un qui ne s'y attend pas ... J'ai eu des gens de sécurité Twitch sur celui-ci).
La colonne UID n'affichera que jusqu'à 8 caractères d'un nom d'utilisateur. Si le nom d'utilisateur comporte plus de 8 caractères, il passera à l'impression de l'UID numérique réel. Vous pouvez contourner cela en ayant un format de colonne ps personnalisé qui contient le champ USER, mais UNIQUEMENT si USER est la dernière colonne (de mes tests empiriques).
La plupart des gens ne s'en soucient probablement pas, mais si vous effectuez une sorte de traitement de la sortie ps et que vous attendez que les vrais noms d'utilisateur apparaissent, vous devez faire attention à la longueur de votre nom (sinon, vous mettrez des hacks dans votre code pour faire ps faire la bonne chose).
Par exemple:
Voici le format de colonne par défaut pour la liste des formats complets. Notez que mon UID est au format numérique car mon nom d'utilisateur est> 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'il 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 est é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, il 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