Hi All, We are embarking on a project to redesigning our Active Directory (AD). Part of the project is to define/standardise the AD user account “User Login Name”. At the moment we have many different formats. Some are 3 characters, example initials and first letter of surname, while others are much more descriptive, example name and first letter of surname.
The next challenge, and hopefully we can align to the AD standard, is to standardise user names format to business systems which don’t authenticate via the AD account, i.e. single sign-on.
I would appreciate it if anyone can please share their experiences in this regard, or possibly a best practice or generally accepted format/governance rules for user account login names.
A desirable format is if you can match AD creds to Exchange creds (i.e. email address) and then try to align as many other systems that don’t use AD-passthrough to the same format.
That way there is effectively only a single “identity” for each user to manage.
Philip I led a similar exercise in a N Sea Oil & Gas company I worked for. Regardless of what you do there will be some disruption. My advice is to accept that disruption and get over it as quickly as possible. I don’t know of any standards which apply to userids but whatever you choose to do, make sure it is for the long term.
– Choose your userid pattern
– Make it unique
– Don’t let well-meaning administrators re-use AD ids. That may work for AD but it won’t work if you want traceability into applications. Having said that remember that AD has a unique SID as well as a userid and you may not want these orphans hanging around if there is no real person attached.
– Make it easy to understand and administer
– Beware of gotchas such as applications with special requirements eg for userid or password length or complexity.
– Consider who is the master
– AD or the HR system.
Do you want the master to drive all other id creation? What about non-staff who need access to your network. I’m afraid I haven’t given you any answers – there are more than one way to skin this particular cat – but I hope I’ve given you some useful pointers.
It is typically not considered a good practice, from an information security standpoint, to utilize your AD user ID in email addresses. It gives a hacker half of the equation too easily. Though, from the application side, it can sure make life a lot easier. Also from an Info Sec standpoint and in this same vein, you may not want to make the user ID “guessable”.
Uniqueness is very much desirable in that some application audit logs are keyed off the user ID. Depending on how long your retention requirements are for your logs may define how long before you can reuse an ID after someone leaves.
Depending on size of your company you may want to limit the size of AD in terms of the number of fields you administer in the directory (database). That may mean you will need a separate database for tracking what other critical applications the individual has access to that may not be tied to AD authentication. That becomes real important when it comes to “aligning the standard”. From an application standpoint you might need an Identity Manager application but they can be quite expensive. Microsoft’s Identity Manager is relatively inexpensive, at least Forefront 2010 R2 was, but implementing anything like this is going to cost you.
Hopefully that is helpful.
—————————— CITGO Petroleum Corp