project database

I presented a webinar today on the common pitfalls in Active Directory self service.  I would link to a recording but as usual I forgot to hit that red record button at the beginning.  Luckily, Imanami has a blog so that we can save the ideas for posterity.

First off, why do you want to offer self service to your users?  Because they 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.

active directory self serviceBut 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 Active Directory 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 Active Directory’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 Active Directory’s rules

One of the worst things you can do is to try to do something that Active Directory won’t let you.  For example, let your users make a distribution group as the owner of a security group in the Active Directory self service portal.  You can still make this happen but not in Active Directory’s managedby attribute.

What might be even worse is to allow something that Active Directory 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 Active Directory 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 Active Directory 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 Active Directory 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 Active Directory 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 Active Directory 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.  If you would like to see how GroupID Self Service solves these problems, please arrange for a personalized demonstration.

get a demo

0 0 votes
Article Rating
1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
11 years ago

Randy, thank you, it is pretty useful. Feel free to link to the post from your website. 🙂