Ben Ruset Sysadmin, etc.

Thoughts on Account Provisioning

A few weeks ago I gave an interview with VPNHaus (part 1) (part 2), regarding account provisioning in the enterprise. I'm writing this as a follow-up to the interview to discuss the issues in greater detail.

First of all, account provisioning is probably one of the most crucial but utterly boring parts of IT. From the perspective of the systems administrator it's a matter creating the user record and figuring out what sort of access they need to enterprise resources. In many places it's a mater of click, click, type, click, click and then press the OK button. For the new user, this will probably be the first introduction they have to the IT organization.

Since IT doesn't do the hiring for the company, this data needs to come from somewhere. That's where HR comes in. HR provides things such as the proper spelling of the user's name, whether they will need remote access to the network (ie: VPN), and a general overview of what the user will need rights to. Again, this is another entry level, boring task that generally requires someone to fill out a help request and then let IT deal with it.

I've seen, though, in many organizations where there's a breakdown in the communication that IT gets from other parts of the organization, particularly HR. The standard operating procedure at one place that I worked was that IT was informed that there was a new employee on their first day. This resulted in a mad dash to provision an account as well as provide basic resources such as a computer, phone, or in some cases even a desk.

Now, what happens when an employee leaves? IT is usually insulated from the rest of the organization either physically or logically, so again the request to terminate access needs to come from HR. In smaller organizations this is less of a problem because generally people will hear about a departure through the grapevine. This isn't a hard and fast rule, though. In a company of less than 50 employees I'd sometimes not be told of a departure until after the fact.

This presents a problem because if IT takes it upon itself to delete a user that it thinks should be deleted there's a risk that important data could be lost, or that the user has a legitimate need to retain access for one reason or another. On the other hand, if IT decides to do nothing, there's a vector for attack where, depending on the circumstances of the employees departure, they might have a motive to use the enterprises resources maliciously.

All this leads to the need to have strong policies in place that dictate the workflow of a user request. This is a policy that both HR and IT need to agree to, and it needs to be efficient, effective, and enforceable. Unfortunately this seems to not happen in many small to medium sized business, and if nobody knows to do anything the user walks into their first day on the job not having an email address, a login, or even a computer. By creating a workflow, there's the ability to first deliver correct information on time and provide accountability across all of the steps needed to create the account.

For example, the company hires a new salesperson. Presumably there will be at least a two week lead-time before they join the company. HR then fills out a request for the new account, supplies the correct spelling of the user's name, provides whatever other information is needed by IT such as contact information and necessary access levels. IT then should, with some measure of expediency, fulfill the request and confirm with HR that the account has been provisioned.

The process should be similar when the employee leaves. HR should notify IT that there's a departure and fill out a request to have the account disabled. Depending on the circumstances of the departure it might be necessary to escalate that to a higher priority level, or let IT know about any special requests (ie: do not delete but disable the account, forward email somewhere, etc.) IT then should expediently handle the request and again confirm with HR that the request has been completed.

While many folks in the trenches (including myself) bemoan the fact that IT is a "service organization," it is one that can only do it's job efficiently when given good data and good policies to follow. For the organization to work efficiently, there needs to be clear instructions and expectations on what to do, how to do it, and when. Sadly it seems that these common-sense policies generally come into effect well after there have already been issues that could have been prevented.