用户名标准的最佳实践:避免问题

Mei*_*Mei 60 user-accounts best-practices

我有兴趣了解人们对标准用户名的体验。我一直在使用{firstInitial}{lastname} 的地方(有时有长度限制)。现在我有用户想要{firstname}.{lastname} - 现在出现这个时期可能会导致问题。

具体来说:

  • 用于保持所有用途的兼容性的最佳用户名长度限制是多少?
  • 应该避免哪些字符?

更新:我没有提到具体细节的原因是我想要足够通用来处理将来可能出现的任何事情。然而,这可能是一个过于笼统的要求(任何事情都可能发生,对吧?)。

这是我们的环境:Ubuntu Server Lucid Lynx 10.04 LTS、Red Hat Enterprise Linux 5.6 及更高版本、Windows Server 2003 和 Windows 2000 Server(在 Windows 2000 Native Mode 中使用 Active Directory)、用于邮件的 Zimbra 7.x,以及附近的 OpenLDAP未来。

更新:我应该提到(为了完整性)我看到了这个问题(尽管它没有回答我提出的问题)以及这个网络帖子,两者都非常有用。

sys*_*138 66

对于试图将异构系统粘合在一起的大型身份管理系统来说,这是一个长期存在的问题。总是,您将被限制为最小公分母,由于数据中心内部某处的某些(可能是遗留的)类 Unix 系统,这通常是 8 个字符的 ASCII-字母数字限制。那些花哨的现代系统可以采用任意长度的 UTF8 用户名,不太可能被使用。

我在高等教育机构工作了 7 年,每年我们必须为 5000 名新生找出 8 个字符的用户名。到我离开时,我们已经为 15 年的学生想出了独特的名字。这个可以,smitj510先生

能让你的生活变得无比轻松的事情:

  • 弄清楚您的最低公分母是什么,这需要分析您的身份管理系统的每个部分以发现限制是什么。
    • 旧的 Solaris 7 系统强制限制为 8 个字符。
    • 您必须考虑使用身份数据的关键应用程序有其自身的限制。
      • 也许他们希望来自 LDAP 的用户数据符合他们独有的“标准”。
      • 也许他们使用的身份验证数据库只能处理某些格式化的数据。
      • 也许 Windows 兼容系统在这不再是一个好主意 20 年后仍然使用 SAMAccountName。
  • 有一个数据库表,其中包含一个真实标识符(即 8 个字符的帐户名称)的列表,链接/字段列出备用 ID 之类的firstname.lastname或任何其他可能出现的内容。
    • 现成的软件可以做一些非常奇怪和 IDM 不友好的事情,例如使用数字 ID 作为帐户名称,或根据个人资料数据自动生成帐户 ID。所有这些也都进入了数据库表。
    • 这也有助于名字中包含非 [az|0-9] 字符的人(如 Harry O'Neil)或非 ASCII 字符(如 Alžbêta)。
  • 当您构建帐户同步流程时,请利用该数据库表来确保正确的帐户获得正确的更新。当名称更改(结婚、离婚、其他)时,您希望这些更改传播到正确的地方。
    • 配置实际的身份数据库本身以在可能的情况下防止本地更改,并在不可能时强烈建议业务流程阻止这种更改。尽你所能依靠中央帐户同步过程。
  • 尽可能利用别名系统,例如在电子邮件中。
  • 考虑 8 字​​符 ID 不可变,因为更改该字段可能会在 IT 人员中引发很多心痛,因为必须重新创建帐户。
    • 这表明帐户 ID不是从姓名数据派生的,因为婚姻/离婚/法院命令可以随着时间的推移更改姓名数据。
  • 有一个系统来处理例外情况,因为总会有一些例外。
    • 可怕的离婚和名称数据生成的 8 字符 UID 每次必须输入时都会带来痛苦的回忆吗?善待你的用户并允许这些变化的机制,但保持安静。
  • 尽你所能在系统中允许多个用户名登录,这是一个选项
    • 有些人喜欢他们的 8 字符 uid,有些人喜欢 firstname.lastname@example.com。灵活点,交朋友。
    • 有时,这需要使用框架(如CAS或利用为基于 Web 的系统提供前端。您会惊讶于有多少现成的系统可以支持这样的 SSO 框架,所以不要气馁。

也就是说,把它当作一个数据库问题来对待,因为它就是这样。选择一个与您的系统具有最大兼容性的主键(可能为 8 个字符),构建一个查找表以允许系统将本地 ID 转换为主键,并设计您的数据同步系统以处理各种 ID。

  • +1 用于不从名称数据中获取用户名。由于结婚/离婚而不得不重命名主目录很烦人。你关于“奇怪的角色”的说法让我想起了小鲍比桌和我以前高中的看门人,我确信他们在网上购物有问题,罗伯特·努尔先生(我没有骗你)。 (13认同)
  • @mhoran_psprep 如果你足够大,你就会让某人进行合法的*名*更改。在这种情况下,为姓氏更改设置的许多系统都会中断。 (5认同)
  • 奇妙且写得很好(并且有启发性)的答案! (4认同)
  • +1 用于解决婚姻和离婚问题。这造成了很多问题。许多公司表现得好像员工是第一个必须改名的人。 (2认同)

mfi*_*nni 26

您的问题具体如下:

  • 用于保持所有用途的兼容性的最佳用户名长度限制是多少?

没有这样的事情。只有“您的”用途,其中可能包括您未来的用途。我们不知道那些是什么。

  • 应该避免哪些字符?

这将取决于您正在处理的计算机系统。例如,Windows 用户名中的句点没有问题。事实上,UPN 的格式类似于电子邮件地址,允许使用句点。

我的进一步想法:

  • 不要让您的用户询问 - 告诉他们标准是什么,并对要求更改标准的企业(而不是个人用户)开放。
  • 请务必在标准中制定“例外政策”,这样您就可以帮助可怜的 Susan Penington 和 Mary Utt(来自上面的评论),而无需让副总裁参与。让 IT 看起来不错,对吧?

  • 最后一条评论值得+50 :) (15认同)
  • 提出合理的例外是至关重要的。多年来,我们遇到过很多例外:多个用户的首字母和姓氏相同,姓氏很长的用户,名字和姓氏相同的用户,来自中国和 HR 的用户的名字完全打乱,有人他的名字拼写为“Raymond Luxury-Yacht”,但发音为“Throatwobbler Mangrove”…… (2认同)
  • 是的,例外!非洲有些国家甚至不知道“名字”和“姓氏”的概念:父亲的名字变成儿子的姓氏,儿子得到一个新的名字…… (2认同)
  • 我建议不要只是制定例外政策,并在初始帐户创建时识别可能从中受益的用户。“我的用户名太糟糕了”不应该是新员工在第一天就应该担心的事情。对标准政策的解释与承认它可能不适合个人以及建议的替代方案相结合,压力要小得多。甚至可以从 HR 获取联系信息,以便您可以在他们第一天之前解决问题。 (2认同)

Eva*_*son 20

我的经验是,对于一个足够大的企业,你做出的任何决定总会有问题。即使它今天有效,但您明天实施的系统总是存在先前标准的问题(长度问题、字符问题等)。

请务必查明对 Firstname.Lastname 的推送是否与电子邮件有关,而不必与登录名有关。我发现很难相信用户在登录时想要输入“John.Smith”而不是“jsmith”,但我更喜欢他想要“John.Smith@company.com”的想法"作为他的电子邮件地址。正如@Mfinni 指出的那样,用户总是可以选择拥有多个电子邮件别名、转发等。只要让用户知道存在将他们的用户名与他们的电子邮件地址分离的选项就可以改变请求的动态。

  • 我们的用户 UPN 和主电子邮件地址在任何时候都是相同的,所以我们只是告诉我们的用户无论在何处尝试登录,都使用他们的电子邮件地址登录。 效果很好,因为我们没有任何依赖于的旧软件网易生物。 (3认同)

Rob*_*Oot 13

对于 Unix 和 Linux 系统,{firstInitial}{lastname}显然是理想的。

...

从与此帐户关联的名称中可以很明显地看出原因。

  • 呃,我想这可能是个笑话。他的名字将是“root”,一个 Unix 系统上的重要用户。 (10认同)
  • ... **R** obert **Oot**... _哎哟!_ 有趣!不知道我是怎么错过的。 (4认同)
  • 我不是不同意,但你能解释一下你为什么这么说吗? (3认同)
  • 这是一个主观的答案,没有解释。人们可以很容易地说,对于 UNIX,_{firstInitial}{middleInitial}{lastInitial}_ 是“理想的”,因为这是 UNIX 的开始,也是多年来一直如此(直到拥有数千名员工的公司开始使用用户名使用它...)。 (2认同)

Tra*_*ell 7

在跨平台设置命名标准时要注意的一件事是 Linux(可能还有其他 Unix 操作系统)中 ps 中的一个特殊外观问题。您可能会或可能不会在意这一点(但对于不期望它的人来说,这可能会令人担忧......我已经让安全人员对此感到不安)。

UID 列最多只能显示用户名的 8 个字符。如果用户名超过 8 个字符,它将切换到打印实际的数字 UID。您可以通过使用包含 USER 字段的自定义 ps 列格式来解决此问题,但前提是 USER 是最后一列(来自我的经验测试)。

大多数人可能并不关心这一点,但是如果您正在对 ps 输出进​​行某种处理并希望出现真实的用户名,那么您应该小心您的名称长度(否则,您将在代码中进行黑客攻击使 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
Run Code Online (Sandbox Code Playgroud)

让我们使用自定义列格式重新创建它。请注意,我添加了 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
Run Code Online (Sandbox Code Playgroud)

让我们将 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
Run Code Online (Sandbox Code Playgroud)

但是,一旦我们在列列表的末尾添加新内容,它就会恢复为数字形式。

[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
Run Code Online (Sandbox Code Playgroud)