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?