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

59

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

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

Mei
источник
4
Вы не упомянули операционную систему / приложение. Вы хотите сделать его слишком общим для применения к любой ОС / приложению?
Халед
13
Наша компания из 80 000 человек использовала стандарт {firstInitial} {фамилия} для входа и адреса электронной почты. Мы изменили ситуацию после гневного звонка мистера Томаса Уоттса, чья электронная почта была заблокирована нашим брандмауэром. Имейте достаточно людей, и будет проблема.
MaskedPlant
13
@MaskedPlant: я люблю смешные имена пользователей. Однажды у нас был Заказчик, который использовал стандарт IBM RACFID «первые четыре символа фамилии, первого инициала, среднего инициала». "Сьюзен Пенингтон" не была счастлива с этим, как вы можете себе представить. Также «Мэри Утт» не была довольна своим именем / фамилией на другом сайте ...> улыбка <
Эван Андерсон
4
{first initial} {фамилия} представляется наиболее распространенной и относительно безопасной для малого и среднего бизнеса. Облегчает жизнь отделу продаж, так как при совершении этих телефонных звонков и общении по B2B требуется общее соглашение.
Чад Харрисон
2
Мне вспоминается полоса Дилберта: search.dilbert.com/comic/Utthead
KeithS

Ответы:

65

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

sysadmin1138
источник
4
Фантастический и хорошо написанный (и яркий) ответ!
Мэй
12
+1 Для того, чтобы не получать имена пользователей из данных имени. Необходимость переименования домашних каталогов из-за брака / развода раздражает. Ваше высказывание о «странных персонажах» заставляет меня думать о Литтл Бобби Таблиц и уборщике в моей старой школе, у которого, я уверен, есть проблемы с покупками в Интернете, мистер Роберт Налл (я не шучу).
Эван Андерсон
Мне нравится «иметь систему для исключений, потому что она всегда будет». часть. Это определенно очень верно. Хотя я не вижу, как smithj510получается отличное имя пользователя из восьми символов;)
scherand
2
+1 за решение брака и развода. Это вызвало так много проблем. Многие компании действуют так, как будто сотрудники первыми должны изменить свое имя.
mhoran_psprep
5
@mhoran_psprep и если вы достаточно большой, вы собираетесь получить кто - то делает юридическое первое изменение названия. Многие системы, настроенные на изменение фамилии, в этом случае ломаются.
sysadmin1138
26

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

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

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

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

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

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

  • Не позволяйте пользователям спрашивать - скажите им, что такое стандарт, и будьте открыты для бизнеса (не отдельных пользователей), запрашивающего изменения в стандарте при изменении требований.
  • Сделайте «политику исключений» в стандарте, чтобы вы могли помогать бедным Сьюзен Пенингтон и Мэри Утт (из комментариев выше) без необходимости привлекать вице-президента. Сделай так, чтобы ЭТО выглядело хорошо, верно?
mfinni
источник
15
Этот последний комментарий стоит +50 :)
Мэй
2
Придумать разумные исключения имеет решающее значение. За прошедшие годы у нас было много исключений: несколько пользователей с одинаковыми именами и фамилиями, пользователи с очень длинными фамилиями, пользователи, чьи имена и фамилии были одинаковыми, пользователи, посещающие Китай и HR, полностью зашифровали свое имя, кто-то чье имя было написано 'Raymond Luxury-Yacht', но произносится как 'Throatwobbler Mangrove' ...
Опека
BobHope, BobHope01, BobHope3, BobHopeAccounting, BobHopeHartford
mfinni
2
Да, для исключения! Некоторые страны Африки даже не знают понятия «имя» и «фамилия»: имя отца становится фамилией сына, а сын получает новое имя ...
Конерак
2
Я бы рекомендовал не только иметь политику исключений, но и идентифицировать пользователей, которые, вероятно, извлекут выгоду из нее при первоначальном создании учетной записи. «Мое имя пользователя ужасно» не должно быть чем-то, что новый наемник должен волновать в первый день. Объяснение стандартной политики в сочетании с признанием того, что она может не подходить для отдельного человека вместе с предложенной альтернативой, гораздо менее напряженно. Возможно, даже получить контактную информацию от HR, чтобы вы могли решить проблему до их первого дня.
Дэн Нили
20

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

Обязательно выясните, относится ли push для Firstname.Lastname к электронной почте, а не к логинам. Мне было бы трудно поверить, что пользователь хочет ввести «John.Smith» вместо «jsmith» при входе в систему, но я гораздо больше убежден, что он хочет »John.Smith@company.com "как его адрес электронной почты. Как указывает @Mfinni, у пользователей всегда есть возможность иметь несколько псевдонимов электронной почты, переадресацию и т. Д. Простое уведомление пользователей о том, что существует возможность отсоединить свое имя пользователя от своего адреса электронной почты, может изменить динамику запроса.

Эван Андерсон
источник
1
И это не значит, что пользователи могут иметь только один адрес электронной почты. Там всегда псевдонимы и переадресация.
mfinni
3
UPN и основные адреса электронной почты наших пользователей всегда идентичны, поэтому мы просто просим наших пользователей входить со своими адресами электронной почты, где бы они ни пытались войти. Прекрасно работает, поскольку у нас нет старого программного обеспечения, которое опирается на NetBIOS.
pauska
Мой опыт показывает, что для достаточно крупного предприятия любое решение, которое вы принимаете, всегда будет иметь проблемы. Даже если это работает сегодня, всегда есть система, которую вы внедряете завтра, у которой есть проблемы ». - Можем ли мы назвать этот закон Андерсона?
Freiheit
@Freiheit: Мое утверждение не заслуживает своего имени ...> smile <Это на самом деле просто вызвано общим применением закона Мерфи к ИТ. Мерфи живет в IT ...
Эван Андерсон
1
Жаль, что у меня нет сообщества Wiki'd сейчас ...> улыбка <
Эван Андерсон
13

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

...

по причинам, которые должны быть очевидны из названия, связанного с этим аккаунтом.

Роберт Оот
источник
3
Я не согласен, но вы можете объяснить, почему вы это говорите?
mfinni
На самом деле я не согласен. В системах AIX на моей последней работе мы были ограничены 8 символами. Таким образом, mfinnigan был бы невозможен; Я должен был быть мфиннига. Поэтому, пожалуйста, расширьте свой ответ немного.
mfinni
2
Это субъективный ответ без объяснения причин. Можно так же легко сказать, что для UNIX {firstInitial} {middleInitial} {lastInitial} является «идеальным», поскольку именно с этого начиналась UNIX и так было в течение многих лет (пока корпорации с тысячами сотрудников с именами пользователей не начали использовать ее ...).
Мэй
10
Я думаю, это может быть шутка. Его имя будет «root», значительный пользователь в системах Unix.
Джеффри
4
... R Оберт OOT ... Ой! ВЕСЕЛАЯ! Не знаю, как я это пропустил.
Мэй
7

При настройке стандартов именования на разных платформах следует учитывать одну особую косметическую проблему в 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
Трэвис Кэмпбелл
источник
К какой операционной системе это относится?
mfinni
Интересно! Я всегда задавался вопросом об этом - почему числа использовались. У lastкоманды есть связанная проблема: она усекает свои записи до 8 символов.
Мэй
Отредактировано, чтобы отразить, что я говорил о Linux. Не знаю, как это ускользнуло в моих первоначальных изменениях.
Трэвис Кэмпбелл
-1

[несколько букв от имени] [несколько букв от фамилии] [nnn]

foreg: если зовут Билл Гейтс, вы можете использовать ' biga00 ' или bilgat000

если придет следующий счет Гейтса, для него это будет 'biga01' или bilgat001 '

SKumar
источник
-1

Ну, с точки зрения эксплуатации, администрирования и обслуживания (OAM), имя пользователя должно быть легко различимо. Однако, с деловой точки зрения, имя пользователя (псевдоним / k / a электронной почты) должно быть легко запомнено или вызвано другими.

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

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