First off, why do you want to offer self service to your users? Because users are often the most accurate source of identity data; you want the information that they know about themselves. And, help desk calls are expensive: if you rely on a help desk to update phone numbers, create distribution lists, or add users to groups, you are spending a lot of money on something that can be done for you faster and cheaper.
But it isn’t that easy, there are a lot of things that can go wrong by offering too much rope to your end users so you have to be cognizant of some of the pitfalls. They almost all have to do with lack of control by IT. If you are offering AD self service, you need to have IT controls in place. Active Directory is too important to let it get out of control.
The most common pitfalls:
Exposing too much information
Not respecting AD’s rules
Loose workflow rules
Group glut, changes run amok
Compatibility with Exchange’s ever-changing moods
Pitfall: exposing too much information
To limit exposing too much information, field level security is key. Let users update only what you want them to update, let them view what they should be able to view, and hide anything you don’t want them to see. You need to have built-in roles so that a manager can change things about her direct reports that the users themselves can only view. And maybe have other users not even see that information.
Pitfall: not respecting AD’s rules
One of the worst things you can do is to try to do something that AD won’t let you. For example, let your users make a distribution group as the owner of a security group in the AD self service portal. You can still make this happen but not in AD’s managedby attribute.
What might be even worse is to allow something that AD does allow! For example, don’t let your users have the ability to change a security group to a distribution group or change group scope from universal to global; they probably don’t know the damage that will cause.
Pitfall: Loose workflow rules
Your AD self service portal is like a coil of rope, you don’t want your users to have too much of it. Workflow allows you to have rules associated with changes and you want rules, lots of them. Best (or at least good) practice is to start with everything workflowed and then turn them off one by one. If your user wants to change his phone number, make sure his manager has to approve it. If a manager wants to change her employee’s title, make sure someone in HR approves it.
If you are going to rely on workflow (and you will) make sure that you have a solid means for users to approve the requests. Have multiple owners on AD groups (or even groups owning groups); have a default approver if someone isn’t answering the request; have notifications of requests and have an inbox in the self service portal for users to track requests.
Pitfall: group glut, changes run amok
Groups are like bunnies, they will multiply and multiply quickly. You need a group lifecycle solution to make sure that groups only exist as long as they are useful to the business. Put a workflow on group creation. Make sure that groups expire and that group owners have the ability to renew them. And make sure that during the group’s expired state, that group doesn’t work to give incentive for group owners to take action. Track and expire distribution lists that aren’t being used. Just make sure that the only AD groups that you have are the ones you want.
Pitfall: compatibility with Exchange’s ever-changing moods
Make sure that your solution keeps up with what Exchange and AD are doing. The best example is when Exchange 2007 came out, they got rid of the Recipient Update Service, breaking all provisioning with most vendors and home-made solutions. So, be sure that you are working on updating your AD self service solution along with your Exchange and/or Active Directory upgrades.
These are just a few of the most common pitfalls in Active Directory self service. To avoid these pitfalls, consider an Active Directory Self Service tool from Imanami, the publisher of these tips.