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

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

我很想知道人们对于标准用户名的体验如何。我一直都去过一些使用{名字首字母}{姓氏}(有时有长度限制)。现在我有用户想要{名字}.{姓氏}- 现在看来,这段时间可能会引发问题。

具体来说:

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

更新:我之所以没有提到具体细节,是因为我希望能够足够通用,以处理将来可能出现的任何问题。但是,这个要求可能太过通用(任何事情都可能发生,对吧?)。

这是我们的环境:Ubuntu Server Lucid Lynx 10.04 LTS、Red Hat Enterprise Linux 5.6 及更高版本、Windows Server 2003 和 Windows 2000 Server(在 Windows 2000 本机模式下使用 Active Directory)、用于邮件的 Zimbra 7.x 以及不久的将来的 OpenLDAP。

更新:我应该提到(为了完整性)我看到这个问题(虽然它没有回答我的问题)还有这个网络帖子,这两篇文章都非常有启发性。

答案1

这是大型身份管理系统试图将异构系统粘合在一起时的一个长期问题。不可避免地,您将被限制在最低公分母,这通常是 8 个字符的 ASCII 字母数字限制,这要归功于数据中心内部某个地方的某些(可能是遗留的)类 Unix 系统。那些花哨的现代系统可以接受任意长度的 UTF8 用户名不太可能被使用。

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

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

  • 弄清楚你的最低共同点是什么,这需要分析你的身份管理系统的每个部分来发现其限制是什么。
    • 旧的 Solaris 7 系统强制执行 8 个字符的限制。
    • 使用身份数据的关键应用程序有其自身的限制,您必须考虑这些限制。
      • 也许他们希望来自 LDAP 的用户数据符合他们独有的“标准”。
      • 也许他们使用的身份验证数据库只能处理某些格式的数据。
      • 也许与 Windows 兼容的系统在二十年后仍然使用 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,其他人喜欢[电子邮件保护]. 灵活变通,广交朋友。
    • 有时这需要在基于 Web 的系统前面安装类似框架中科院或杠杆。您会惊讶于有多少现成的系统可以支持这样的 SSO 框架,所以不要气馁。

也就是说,将其视为数据库问题,因为它就是数据库问题。选择一个主键以最大程度地兼容您的系统(可能是 8 个字符),构建一个查找表以允许系统将本地 ID 转换为主键,并设计您的数据同步系统以处理各种 ID。

答案2

您的问题具体如下:

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

没有这种事。只有“你的”用途,可能包括你将来的用途。我们不知道那些是什么。

  • 应该避免使用哪些字符?

这取决于您使用的计算机系统。例如,Windows 不会对用户名中的句点产生任何问题。事实上,UPN 的格式类似于电子邮件地址,允许使用句点。

我的进一步想法:

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

答案3

我的经验是,对于一个足够大的企业来说,你做出的任何决定总是会有问题。即使今天行得通,你明天实施的系统也总会与之前的标准存在问题(长度问题、字符问题等)。

一定要弄清楚 Firstname.Lastname 的推送是否与电子邮件有关,而不一定与登录名有关。我很难相信用户在登录时会输入“John.Smith”而不是“jsmith”,但我更相信他想要“[电子邮件保护]“作为他的电子邮件地址。正如@Mfinni 指出的那样,用户总是可以选择多个电子邮件别名、转发等。只要让用户知道存在将他们的用户名与电子邮件地址分离的选项,就可以改变请求的动态。

答案4

在跨平台设置命名标准时要注意的一件事是 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

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

相关内容