Найкращі практики в стандартах імені користувачів: уникнення проблем

Мені цікаво дізнатися, що таке досвід людей зі стандартними іменами користувачів. Я завжди був у місцях, де використовувався {firstInitial} {прізвище} (іноді з обмеженням довжини). Зараз у мене є користувачі, які хочуть {ім'я}. {Lastname} - і тепер з'ясувалося, що період може спричинити проблеми.

Конкретно:

• Яке найкраще обмеження довжини імені користувача для підтримки сумісності для всіх застосувань?
• Яких персонажів слід уникати?

ОНОВЛЕННЯ: Причиною я не зазначив конкретики є те, що я хотів бути достатньо загальним, щоб вирішити все, що може з’явитися в майбутньому. Однак це може бути занадто загальним вимогою (що-небудь може статися, правда?).

Це наше середовище: Ubuntu Server Lucid Lynx 10.04 LTS, Red Hat Enterprise Linux 5.6 та новіших версій, Windows Server 2003 та Windows 2000 Server (з Active Directory у рідному режимі Windows 2000), Zimbra 7.x для пошти та OpenLDAP найближчим часом майбутнє

ОНОВЛЕННЯ: Я мушу зазначити (для повноти), що я бачив це питання (хоча воно не відповіло на моє запитане питання), а також це веб-повідомлення , яке було дуже інформативним.

Це хронічна проблема, коли великі системи управління ідентичністю намагаються склеїти гетерогенні системи. Незмінно ви обмежуєтесь найнижчим загальним знаменником, який занадто часто є 8-символьним лімітним числом ASCII-альфа-чисел завдяки деякій (ймовірно, застарілій) Unix-подібній системі десь у надрах центру обробки даних. Ці модні сучасні системи можуть приймати довільні імена користувачів UTF8 довільної довжини навряд чи вдасться використати.

Я провів 7 років у вищому навчальному закладі, де нам потрібно було визначати 8-символьні імена для 5000 нових студентів щороку. До моєї поїздки нам вдалося придумати унікальні імена для 15 років студентів. Це можна зробити, пане smitj510

Речі, які полегшать ваше життя незмірно легшим:

• З’ясуйте, що таке найменший найпоширеніший знаменник, для чого потрібно проаналізувати кожну частину вашої системи управління ідентичністю, щоб виявити, які обмеження є.
  • Ця стара система Solaris 7 змушує обмежувати 8 символів.
  • Критичні програми, які використовують дані ідентичності, мають свої обмеження, які вам доведеться враховувати.
    • Можливо, вони очікують, що дані користувача від LDAP відповідатимуть унікальному для них «стандарту».
    • Можливо, база даних автентифікації, яку вони використовують, може обробляти лише певні відформатовані дані.
• Створіть таблицю бази даних зі списком Єдиного ідентифікатора (це 8-символьне ім’я облікового запису) із посиланнями / полями, що містять перелік альтернативних ідентифікаторів, подібних до firstname.lastnameбудь-якого іншого.
  • Забезпечене програмне забезпечення може робити деякі дуже дивні та недоброзичливі до речей речі, наприклад, використовувати числовий ідентифікатор для імені облікового запису або автоматично генерувати ідентифікатори облікового запису на основі даних профілю. Все, що входить і в таблицю бази даних.
  • Це також допомагає людям з не- [az | 0-9] символами у своїх іменах, як Гаррі О'Ніл, або особами, що не належать до ASCII, як Alžbêta.
• Коли ви будуєте процеси синхронізації свого облікового запису, використовуйте цю таблицю бази даних, щоб гарантувати, що правильні облікові записи отримують правильні оновлення. Коли імена змінюються (шлюб, розлучення та інші), ви хочете, щоб ці зміни поширилися в потрібні місця.
  • Налаштуйте самі фактичні бази даних, щоб запобігти локальним змінам, де це можливо, а бізнес-процес сильно перешкоджає цьому, коли це неможливо. Покладайтеся на процес синхронізації центрального облікового запису для всього, що ви можете.
• Скористайтеся системами псевдонімів, де можна, як-от електронною поштою.
• Вважайте 8-знаковий ідентифікатор непорушним, оскільки зміна цього поля може викликати багато болю в серці серед ІТ-персоналу, оскільки облікові записи потрібно відтворити.
  • Це говорить про те, що ідентифікатор облікового запису не походить від даних про ім’я, оскільки шлюб / розлучення / ухвала суду можуть змінювати дані імені з часом.
• Встановіть систему для виключень, оскільки їх завжди знайдеться.
  • Жахливе розлучення, і те, що створені 8-значним UID дані про імена приносить вигадливі спогади щоразу, коли вам доведеться вводити його? Будьте приємні до своїх користувачів і дозвольте механізму цих змін, але замовкніть.
• Зробіть все можливе, щоб дозволити кілька входів у систему користувачів у системах, де це є можливим варіантом
  • Деяким подобається їх 8-символьний uid, іншим подобається firstname.lastname@example.com. Будьте гнучкими, подружтеся.
  • Іноді для цього потрібне фронтування ваших веб-систем із системою єдиного входу на зразок CAS . Ви здивуєтеся тому, скільки систем на полицях можуть підтримувати такі рамки SSO, так що не перешкоджайте.

Що означає, трактуйте це як проблему, що базується на даних, тому що це є. Виберіть первинний ключ для максимальної сумісності з вашими системами (ймовірно, 8 символів), складіть таблицю пошуку, щоб дозволити системам переводити локальні ідентифікатори в первинний ключ, і інженіруйте свої системи синхронізації даних для обробки різних ідентифікаторів.

Ваші запитання, зокрема:

• Яке найкраще обмеження довжини імені користувача для підтримки сумісності для всіх застосувань?

Немає такого. Є лише "ваші" способи використання, які можуть включати ваші подальші використання. Ми поняття не маємо, що це.

• Яких персонажів слід уникати?

Це залежатиме від того, з якими комп’ютерними системами ви маєте справу. Наприклад, Windows не має проблем із періодом в імені користувача. Насправді, UPN відформатований як електронна адреса, яка дозволяє певний період.

Мої подальші думки:

• Не дозволяйте вашим користувачам запитувати - повідомте їм, що таке стандарт, і будьте відкриті для бізнесу (а не окремих користувачів), вимагаючи змін до стандарту, як змінюються вимоги.
• Зробіть стандарт "політики виключення" у стандарті, щоб ви могли допомогти бідним Сьюзен Пенінгтон та Мері Утт (з коментарів вище), не залучаючи віце-президента. Зробити ІТ добре, чи не так?

Мій досвід полягав у тому, що для досить великого підприємства будь-яке рішення, яке ви приймаєте, завжди матиме проблеми. Навіть якщо це працює сьогодні, завжди існує система, яку ви впроваджуєте завтра, яка має проблеми з попереднім стандартом (проблеми з довжиною, проблеми з символами тощо).

Не забудьте дізнатись, чи стосується натискання на ім’я Firstname.Lastname, пов’язане з електронною поштою, а не обов'язково входити імена. Мені важко повірити, що користувач хоче ввести "John.Smith" замість "jsmith" під час входу в систему, але я набагато більше продається на думку, що він хоче "John.Smith@company.com ", як його електронна адреса. Як зазначає @Mfinni, для користувачів завжди є можливість мати мультиплікаційні псевдоніми електронної пошти, переадресацію тощо. Лише повідомляючи користувачів про те, що існує можливість деблокування свого імені користувача з адреси електронної пошти, це може змінити динаміку запиту.

Для систем Unix та Linux {firstInitial} {lastname} явно ідеально підходить.

...

з причин, які повинні бути зрозумілі з назви, пов’язаної з цим обліковим записом.

Одне, що слід пам’ятати при встановленні стандартів іменування на платформах, - це певна косметична проблема в PS в Linux (і, можливо, в інших ОС Unix). Ви можете чи не потурбуєтесь про це (але це може насторожити того, хто цього не очікує ... На цьому я поспіпнув людей із безпеки).

У стовпці UID відображатиметься до 8 символів імені користувача. Якщо ім'я користувача більше 8 символів, воно перейде до друку фактичного числового UID. Ви МОЖЕТЕ обійти це, створивши спеціальний формат стовпців PS, який містить поле USER, але ТОЛЬКО, якщо USER - це останній стовпець (з мого емпіричного тестування).

Більшість людей, мабуть, не переймаються цим, але якщо ви робите якусь обробку виводу PS і очікуєте появи реальних імен користувачів, вам слід бути обережними з довжиною свого імені (інакше ви будете вводити хаки у свій код змусити пс зробити правильну річ).

Наприклад:

Ось формат стовпців за замовчуванням для повного переліку формату. Зауважте, що мій uid у цифровому форматі, оскільки мій ім'я користувача> 8 символів.

[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

Давайте відтворимо його за допомогою спеціального формату стовпців. Зауважте, що я додав стовпець USER. Зауважте, що він також у цифровому форматі.

[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

Давайте перемістимо USER до кінця рядка. Він розширюється до "правильного" виводу.

[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

Але, як тільки ми додаємо щось нове до кінця списку стовпців, воно повертається до числової форми.

[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

[деякі листи від імені] [деякі листи з прізвища] [nnn]

foreg: Якщо ім'я Білл Гейтс, ви можете використовувати " biga00 " або bilgat000

якщо наступні ворота рахунку, це буде "biga01" або bilgat001 "для нього

Ну, з точки зору операцій, адміністрування та обслуговування (OAM), ім'я користувача потрібно легко відрізнити. Однак з точки зору бізнесу, ім’я користувача (псевдонім електронної пошти) має бути легко запам'ятоване або відкликане іншими.

Це може бути як:

• first.last.index@domain
• перший (початковий) .last.index @ домен