Looking at doing an integration and discussing the sAMAccountName attribute that is being populated in AD with usernames.
Currently the system is using first initial and last name if a duplicate account is detected with that username it adds a letter for example Robert McKay would be: rmckay. The first account created would work fine however if there is a second account it would be romckay and continue down a strange path of additional letters and numbers forcing uniqueness for the users. The client is wanting to move to a completely numeric username. Instead of rmckay it would now be 0000001 (for logins to everything that is AD connected or pulling from AD).
Also there are systems that derive their account login and generation from the sAMAccountName – so even though in the case of emails and systems where AD login has been setup the down stream systems that rely on the sAMAccountName will still required a login of: Employee ID + password vs friendly username + password.
Additionally there has been common consensus among the staff about user friendliness drop – however the one major concern was the issues that could arise for emails, however that will be addressed through the use of aliases. Anyone aware of anywhere that successfully was able to implement an Employee ID as sAMAccountName and found that the net result was positive (give the reduction in user friendliness?) Or can point to best practices that can be reviewed to share?
Best Answer
Common best practices for user ID generation and assignment state that ID's should be:
Unique within the administrative domain itself and over time (i.e. no duplicates).
Consistent in that they should not contain information that may change in the future (e.g. the role of the employee, employment status, etc.).
Persistent in that the user should use the same ID for their entire employment term.
Memorable in that the ID should be easy for the user to remember.
It is possible to create a user ID system based on assigned numbers (e.g. an employee ID number) that conforms to the best practices mentioned above. The strengths and weaknesses of doing so could be summarized as follows:
Strengths
The ID contains no personal information (i.e. the name of the user).
Users sometimes change their legal name (e.g. due to marriage, gender reassignment, etc.) and may insist that their username be updated accordingly. A numeric ID system would allow you to avoid this hassle.
ID generation/assignment is simplified (i.e. you don't have to worry about instances where people share the same name).
Drawbacks
It may be difficult for users to remember.
If employee numbers are used, you must decide how contractors and temporary work staff will be treated. Also, what will happen if such staff become full-time employees.
My two cents is that a username system based on numeric ID's would be especially strong on aforementioned best practice points 2 and 3, but weak on point 4. However, I feel that this will not be a big deal if the number of user ID/password combinations that the user must memorize are kept to a minimum (e.g. each user is assigned a single universal numeric ID/PW pair that can be used for all systems including domain, email, etc.). If there are multiple independent systems that require separate logon credentials, I think that throwing in a numeric ID in addition to a name-based one would be burdensome to users.
References: Best Practices in User ID Formation