User Provisioning


As systems sprawl has taken place, we have had the unfortunate task of implementing products that do not or did not utilize a central store for information, such as Active Directory. As a result, we have numerous products that have their own information stores. This becomes frustrating as an administrator, because there is a greater burden when doing simple tasks such as user provisioning. Currently, our new user process works like this:

HR notification arrives
Create Active Directory Account using custom tool
Create eDirectory Account using ConsoleOne
Create Groupwise Account with ConsoleOne
Notify another system analyst to create more Active Directory accounts in an untrusted standalone forest.
Notify another group altogether to get externally hosted web application account(s) set up
Create home folder
Assign computer

I’m sure there is something I’ve left out, but it isn’t pretty. We’re currently looking at products such as Microsoft Identity Lifecycle Manager. Several management folks have become very hot on the idea, however, what they are failing to realize is a very simple fact: We don’t have a good data source to do automated provisioning.

The HR system, which tracks all sorts of information including payroll and employee information, has data fields that aren’t used well. As an outsider looking in on that system as someone who has received a data extract from it, I would describe the data as “a nightmare”. From there, we only have more difficulties. Fortunately for us, we made our “clean” source Active Directory – that is until we realize that information there will be out of date for many users until such time that we have a better system for the folks doing things like user moves or renames.

All this was to get to my point: When it comes down to it, there is something eDirectory has over Active Directory that seems so obvious – user templates. They include all sorts of fancy settings like office, address, and even home directory (with a variable, of course). The best we can do with AD is copy a user, and even when doing that, not all fields are copied. Quite frustrating. Additionally, provisioning user folders for AD hasn’t been particularly fun in Server 2008. I had to disable UAC because of a feature known as “Local User Access”. This was a very frustrating decision, because I find UAC to be pretty valuable on my Vista machine so I thought it would be a similar beast for Server 2008.

Leave a comment

Your email address will not be published.