Лучшие практики в стандартах имени пользователя: избежание проблем

Мне интересно узнать, как люди воспринимают стандартные имена пользователей. Я всегда был в местах, которые использовали {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 в ближайшем будущем. будущее.

ОБНОВЛЕНИЕ: я должен упомянуть (для полноты), что я видел этот вопрос (хотя он не ответил на мой заданный вопрос), а также этот веб-пост , оба из которых были очень информативными.

Это хроническая проблема с большими системами Identity Management, пытающимися склеить гетерогенные системы. Неизменно, вы будете ограничены наименьшим общим знаменателем, который слишком часто является 8-символьным ASCII-буквенно-цифровым пределом благодаря некоторой (возможно, устаревшей) Unix-подобной системе где-то в недрах центра обработки данных. Эти модные современные системы могут принимать произвольную длину. UTF8-имена пользователей вряд ли будут использоваться.

Я провел 7 лет в высшем учебном заведении, где нам приходилось подбирать 8-символьные имена пользователей для 5000 новых студентов каждый год. К тому времени, когда я ушел, нам удалось придумать уникальные имена для 15-летних студентов. Это можно сделать, мистер smitj510

Вещи, которые сделают вашу жизнь неизмеримо проще:

• Выясните, какой у вас наименьший общий знаменатель, для чего необходимо проанализировать каждую часть вашей системы управления идентификацией, чтобы узнать, каковы ограничения.
  • Эта старая система Solaris 7 требует ограничения в 8 символов.
  • Критические приложения, которые используют идентификационные данные, имеют свои собственные ограничения, которые вы должны учитывать.
    • Возможно, они ожидают, что пользовательские данные из LDAP будут соответствовать уникальному для них «стандарту».
    • Возможно, база данных аутентификации, которую они используют, может обрабатывать только определенные отформатированные данные.
• Имейте таблицу базы данных со списком Единого Истинного Идентификатора (это 8-символьное имя учетной записи), со ссылками / полями, перечисляющими альтернативные идентификаторы типа firstname.lastnameили что-нибудь еще, что может появиться.
  • Готовое программное обеспечение может делать некоторые действительно странные и недружественные IDM вещи, такие как использование числового идентификатора для имени учетной записи или автоматическое создание идентификаторов учетной записи на основе данных профиля. Все это также входит в таблицу базы данных.
  • Это также помогает людям с не [az | 0-9] символами в их именах, такими как Harry O'Neil, или не-ASCII, такими как Alžbêta.
• Когда вы создаете процессы синхронизации своих учетных записей, используйте эту таблицу базы данных, чтобы гарантировать, что нужные учетные записи получают нужные обновления. Когда имена меняются (брак, развод, другие), вы хотите, чтобы эти изменения распространялись в нужных местах.
  • Сконфигурируйте действительные базы данных идентичности, чтобы предотвратить локальные изменения, где это возможно, и бизнес-процесс, чтобы не поощрять это, когда это невозможно. Полагайтесь на центральный процесс синхронизации учетных записей для всего, что вы можете.
• Используйте системы псевдонимов везде, где можете, например, в электронной почте.
• Считайте 8-значный идентификатор неизменным, так как изменение этого поля может вызвать ОЧЕНЬ сильную боль у ИТ-персонала, так как учетные записи должны быть воссозданы.
  • Это предполагает, что идентификатор учетной записи не получен из данных имени, поскольку брак / развод / постановление суда могут со временем изменить данные имени.
• Создайте систему исключений, поскольку она всегда будет.
  • Ужасный развод и что сгенерированный 8-символьный UID с именами-данными каждый раз вводит в себя ужасные воспоминания? Будьте добры к своим пользователям и разрешите механизм для этих изменений, но храните его в тайне.
• Делайте все возможное, чтобы разрешить несколько входов в систему с именами пользователей в тех системах, где это возможно
  • Некоторым нравится их 8-символьный идентификатор, другим нравится firstname.lastname@example.com. Будьте гибкими, заводите друзей.
  • Иногда для этого требуется, чтобы ваши веб-системы работали с платформой единого входа, такой как CAS . Вы будете удивлены тем, как много готовых систем могут поддерживать такие SSO-структуры, поэтому не расстраивайтесь.

То есть, относитесь к этому как к проблеме базы данных, потому что это то, что есть. Выберите первичный ключ для максимальной совместимости с вашими системами (вероятно, 8 символов), создайте справочную таблицу, чтобы позволить системам преобразовывать локальные идентификаторы в первичный ключ, и спроектируйте ваши системы синхронизации данных для обработки различных идентификаторов.

Ваши вопросы конкретно:

• Какое ограничение длины имени пользователя лучше всего использовать для обеспечения совместимости при любом использовании?

Нет такого понятия. Существует только «ваше» использование, которое может включать ваше будущее использование. Мы понятия не имеем, что это такое.

• Каких персонажей следует избегать?

Это будет зависеть от того, с какими компьютерными системами вы имеете дело. В Windows, например, нет проблем с точкой в ​​имени пользователя. На самом деле, UPN форматируется как адрес электронной почты, что позволяет точку.

Мои дальнейшие мысли:

• Не позволяйте пользователям спрашивать - скажите им, что такое стандарт, и будьте открыты для бизнеса (не отдельных пользователей), запрашивающего изменения в стандарте при изменении требований.
• Сделайте «политику исключений» в стандарте, чтобы вы могли помогать бедным Сьюзен Пенингтон и Мэри Утт (из комментариев выше) без необходимости привлекать вице-президента. Сделай так, чтобы ЭТО выглядело хорошо, верно?

Мой опыт показывает, что для достаточно крупного предприятия любое решение, которое вы принимаете, всегда будет иметь проблемы. Даже если это работает сегодня, всегда есть система, которую вы внедряете завтра, у которой есть проблемы с предыдущим стандартом (проблемы длины, проблемы персонажа и т. Д.).

Обязательно выясните, относится ли push для 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 и ожидаете появления реальных имен пользователей, вам следует быть осторожным с длинами имен (в противном случае вы будете вносить хаки в свой код чтобы PS сделал правильную вещь).

Например:

Вот формат столбца по умолчанию для полного списка форматов. Обратите внимание, что мой идентификатор в числовом формате, потому что мое имя пользователя> 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

Давайте переместим пользователя в конец строки. Расширяется до «правильного» выхода.

[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), имя пользователя должно быть легко различимо. Однако, с деловой точки зрения, имя пользователя (псевдоним / k / a электронной почты) должно быть легко запомнено или вызвано другими.

Это может быть как:

• first.last.index@domain
• первый (начальный) .last.index @ домен