用户名标准的最佳做法:避免问题

我有兴趣找出人们使用标准用户名的经验。 我一直在使用{firstInitial} {lastname} (有时限制长度)的地方。 现在我的用户需要{姓氏}。{姓氏} – 现在出现这段时间可能会导致问题。

特别:

  • 什么是最好的用户名长度限制来保持所有用途的兼容性?
  • 应该避免哪些字符?

更新:我没有提到细节的原因是我想足够普遍,以处理将来可能出现的任何事情。 然而,这可能是一个太普遍的要求(任何事情都可能发生,对吧?)。

这是我们的环境:Ubuntu服务器Lucid Lynx 10.04 LTS,红帽企业Linux 5.6及更高版本,Windows Server 2003和Windows 2000 Server(在Windows 2000本机模式下具有Active Directory),邮件Zimbra 7.x以及附近的OpenLDAP未来。

更新:我应该提到(完整性),我看到这个问题 (虽然它没有回答我问的问题),也是这个网站 ,这两个都是非常丰富的信息。

    这是大型身份pipe理系统尝试将异构系统粘合在一起的一个长期问题。 总而言之,你将被限制在最低的公分母之中,这通常是一个8字符的ASCII字母数字限制,这要归功于数据中心内部的一些(可能是传统的)类似Unix的系统。 那些奇特的现代系统可以采取任意长度的UTF8用户名不太可能被使用。

    我在一所高等教育机构度过了7年的时间,每年我们必须为每年5000名新生计算8个字符的用户名。 在我离开的时候,我们设法为15年的学生devise了独一无二的名字。 smitj510先生,可以这样做

    事情会让你的生活变得更加轻松:

    • 找出你的最低分数是什么,这需要分析你的身份pipe理系统的每个部分,以发现什么是限制。
      • 那个旧的Solaris 7系统强制限制8个字符。
      • 使用身份数据的关键应用程序有自己的限制,你将不得不考虑。
        • 也许他们希望来自LDAP的用户数据符合唯一的标准。
        • 也许他们使用的authentication数据库只能处理某些格式化的数据。
    • 有一个数据库表的一个真正的标识符(8个字符的帐户名称)列表,其中链接/字段列出备用ID像firstname.lastname或其他任何可能出现。
      • 现成的软件可以做一些非常奇怪和IDM不友好的事情,例如使用数字ID作为帐户名称,或根据configuration文件数据自动生成帐户ID。 所有进入数据库表也是如此。
      • 这也有助于人们使用像Harry O'Neil这样的名字中的非[az | 0-9]字符,或者像Alžbêta这样的非ASCII字符。
    • 在构build帐户同步过程时,请利用该数据库表以确保正确的帐户获得正确的更新。 当名字改变(婚姻,离婚,其他),你想要这些改变传播到正确的地方。
      • configuration实际的身份数据库本身以防止本地更改,如果不可能,业务stream程将极力阻止。 依靠中央帐户同步过程,尽一切可能。
    • 尽可能利用别名系统,例如在电子邮件中。
    • 考虑到8字符ID是不可变的,因为改变这个字段可能会触发IT员工中的很多心疼,因为账户必须被重新创build。
      • 这表明一个账户ID 不是从姓名数据中得到的,因为结婚/离婚/法庭命令可以随时间改变姓名数据。
    • 有一个例外的系统,因为总会有一些。
      • 可怕的离婚和这个名字 – 数据产生的8个字符的UID带来痛苦的回忆,每次你必须进入它? 对用户好,并允许这些更改的机制,但保持安静。
    • 尽你所能,让系统中的多个用户名login,这是一个选项
      • 有些人喜欢他们的8字符uid,其他人喜欢[email protected]。 要灵活,交朋友。
      • 有时候这需要使用像CAS这样的单点login框架来面向基于Web的系统。 你会惊讶于现成的系统可以支持这样的SSO框架,所以不要灰心。

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

    你的问题具体:

    • 什么是最好的用户名长度限制来保持所有用途的兼容性?

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

    • 应该避免哪些字符?

    这将取决于你正在处理的计算机系统。 例如,Windows在用户名中没有问题。 实际上,UPN的格式就像一个电子邮件地址,允许一段时间。

    我进一步的想法:

    • 不要让用户问 – 告诉他们标准是什么,并且随着需求的变化,向业务(而不是个人用户)要求更改标准。
    • 在标准中制定一个“例外政策”,所以你可以帮助可怜的苏珊·潘宁顿(Susan Penington)和玛丽·乌特(Mary Utt)(上面的评论),而不需要副总统的参与。 让IT看起来不错,对吧?

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

    请务必查明Firstname.Lastname的推送是否与电子邮件相关,而不一定是login名。 我很难相信用户在login时想要键入“John.Smith”而不是“jsmith”,但是我更愿意以“[email protected]” “作为他的电子邮件地址。 正如@Mfinni所指出的那样,用户总是可以select多个电子邮件别名,转发等等。只要让用户知道将他们的用户名和他们的电子邮件地址分开就可以改变请求的dynamic。

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

    原因应该是显而易见的与此帐户相关联的名称。

    在跨平台设置命名标准时需要注意的一点是,在Linux(也可能是其他Unix操作系统)中ps是一个特殊的问题。 你可能会也可能不会在乎这个(但是对于一个不期待它的人来说,这可能会令人震惊),我已经让安全人员抽搐了。

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

    大多数人可能不关心这一点,但如果你正在做一些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 

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

    但是,只要我们在列列表的末尾添加新的东西,它就会回到数字forms。

     [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'

    那么,从操作,pipe理和维护(OAM)angular度来看,用户名需要易于区分。 但是,从商业angular度来看,用户名(a / k / a电子邮件别名)必须容易被其他人记住或回忆。

    它可以是这样的:

    • first.last.index@domain
    • 第一(初始).last.index @域