Best Practices in Username Standards: Avoiding Problems

I'm interested in finding out what people's experiences with standard usernames is. I've always been in places that used {firstInitial}{lastname} (sometimes with a length-limit). Now I've users that want {firstname}.{lastname} - and now it comes up that the period may cause problems.

Specifically:

• What is the best username length limit to use to maintain compatibility across all uses?
• What characters should be avoided?

UPDATE: The reason I didn't mention specifics is that I wanted to be general enough to handle anything that might come up in the future. However, that may be too general of a requirement (anything can happen, right?).

This is our environment: Ubuntu Server Lucid Lynx 10.04 LTS, Red Hat Enterprise Linux 5.6 and up, Windows Server 2003 and Windows 2000 Server (with Active Directory in Windows 2000 Native Mode), Zimbra 7.x for mail, and OpenLDAP in the near future.

UPDATE: I should mention (for completeness) that I saw this question (though it didn't answer my asked question) and also this web post, both of which were very informative.

This is a chronic problem with large Identity Management systems attempting to glue together heterogeneous systems. Invariably, you'll be limited to the lowest common denominator, which all too often is an 8-character ASCII-alpha-numeric limit thanks to some (probably legacy) Unix-like system somewhere in the bowels of the datacenter. Those fancy modern systems can take arbitrary length UTF8 usernames are unlikely to get used.

I spent 7 years at an institution of higher education where we had to figure out 8-character usernames for 5000 new students every year. We had managed to come up with unique names for 15 years of students by the time I left. This can be done, Mr. smitj510

Things that will make your life immeasurably easier:

• Figure out what your lowest-common-denominator is, which requires analyzing every part of your identity-management system to discover what the limits are.
  • That old Solaris 7 system is forcing the 8-character limit.
  • Critical applications that use identity data have their own limits you will have to consider.
    • Perhaps they expect user data from LDAP to conform to a unique-to-them 'standard'.
    • Perhaps the authentication database they use can only handle certain formatted data.
    • Perhaps that Windows-compatible system still uses SAMAccountName two decades after that stopped being a good idea.
• Have a database table with a list of the One True Identifier (that 8-character account-name), with links/fields listing alternate ID's like firstname.lastname or anything else that might come up.
  • Off-the-shelf software can do some really weird and IDM-unfriendly things like use a numerical ID for account name, or auto-generate account IDs based on profile data. All that goes into the database table too.
  • This also helps people with non-[a-z|0-9] characters in their names like Harry O'Neil, or non-ASCII ones like Alžbêta.
• When you build your account synchronization processes, leverage that database table to ensure that the right accounts are getting the right updates. When names change (marriage, divorce, others) you want those changes to propagate to the right places.
  • Configure the actual identity databases themselves to prevent local-changes where possible, and business process to strongly discourage that when it isn't possible. Rely on the central account-sync process for everything you can.
• Leverage alias systems wherever you can, such as in email.
• Consider the 8-char ID immutable, since changing that field can trigger a LOT of heart-ache among IT staff as accounts have to be recreated.
  • This suggests an account-ID not derived from name data, since marriage/divorce/court-order can change the name-data over time.
• Have a system in place for exceptions, since there will always be some.
  • Horrible divorce and that name-data generated 8-char UID brings wrenching memories every time you have to enter it? Be nice to your users and allow a mechanism for these changes, but keep it quiet.
• Do what you can to allow multiple username logins in the systems where that's an option
  • Some people like their 8-character uid, others like [email protected]. Be flexible, make friends.
  • Sometimes this requires fronting your web-based systems with a single-sign-on framework like CAS or leverage saml. You will be surprised at how many off the shelf systems can support SSO frameworks like this, so don't be discouraged.

Which is to say, treat it like a databasing problem because that's what it is. Pick a primary key for maximum compatibility with your systems (likely 8 characters), build a lookup-table to allow systems to translate local ID's to the primary key, and engineer your data synchronization systems to handle various IDs.

Your questions specifically:

• What is the best username length limit to use to maintain compatibility across all uses?

There's no such thing. There's only "your" uses, which may include your future uses. We have no idea what those are.

• What characters should be avoided?

This will depend on what computer systems you're dealing with. Windows, for example, has no problems with a period in the username. In fact, the UPN is formatted like an email address, which allows a period.

My further thoughts:

• Don't let your users ask - tell them what the standard is, and be open to the business (not individual users) requesting changes to the standard as requirements change.
• Do make an "exception policy" in the standard, so you can help out poor Susan Penington and Mary Utt (from comments above) without having to involve a vice-president. Make IT look good, right?

My experience has been that, for a sufficiently large enterprise, any decision you make will always have problems. Even if it works today, there's always the system you implement tomorrow that has problems with the prior standard (length issues, character problems, etc).

Be sure to find out if the push for Firstname.Lastname relates to email and not necessarily login names. I'd find it hard to believe that the user wants to type "John.Smith" instead of "jsmith" when logging-on, but I'm much more sold on the idea that he wants "[email protected]" as his email address. As @Mfinni points out, there's always the option for users to have mutliple email aliases, forwards, etc. Just letting users know that the option exists to de-couple their username from their email address can change the dynamic of the request.

For Unix and Linux systems, {firstInitial}{lastname} is clearly ideal.

...

for reasons that should be obvious from the name associated with this account.