project database

We get role attestation as a customer requirement in Active Directory group management constantly.  The problem is that it seems to mean something different to everyone.  Bob Bobel describes attestation very well:

“Attestation describes any certification review process where an individual swears to or witness/confirm something important. This term is almost universally used to describe a review/certification process that requires resource owners to verify their authorized users during on an on-going basis.”

Active Directory attestationBasically, group owners need to certify that the membership of their group is correct every once in a while.  The problem is that in any type of large environment, attestation is usually just paying lip service to the auditors.

For example, I have a security group granting access to Oracle Financials; 324 out of 4,000 employees at the company have access to it.  And once a quarter I look at the membership and say, “yep, it’s OK.”.  Do I really know anything about those 324 group members?  Do I know if one is missing or one more should be added?  Nope.  I need more information on those users.

  • What if I knew that all of the users were in the accounting department?  That would help.
  • What if I knew the 5 users that were added this quarter and the 6 that were removed?  That would make my attestation much easier and ensure that I actually looked at it.
  • What if I had a compelling event to make me actually look at the group instead of just firing off an email to IT?  Aha, the holy grail.

How do I accomplish these three things?  Let’s go in order.

What if I knew that all of the users were in the accounting department?   There are two ways to go about this one: 1) expose the department name or other identity attribute in your Active Directory self service portal or 2) make it a dynamic security group that queries the appropriate identity attributes.  With 1, your group owner can just scan the list of members and see who does and doesn’t belong.  With 2, they don’t even have to think about it (you just need to make sure that AD and all source data is accurate).

What if I knew the 5 users that were added this quarter and the 6 that were removed?   You can have group owners scour Active Directory logs or, better yet, expose Active Directory history to them with GroupID Self Service.  Each group will have its history laid out in a convenient easy to read format showing all new and removed members and other changes to the group (like mail enabling it).  This works even on the dynamic groups referenced above.

What if I had a compelling event to make me actually look at the group instead of just firing off an email to IT?  This is the holy grail, how do you get group owners to actually check?  By initiating an expiration/renewal lifecycle.  Every 90 days, this group is going to expire unless the group owner renews it.  If they don’t renew the group, it’s going to break but still give them a chance to renew it and get all the rights and membership back.

As alwas in this blog, there are ways to do each of these things without GroupID but you really should check it out if our definition of group and role attestation is the same as yours.  To summarize, you do three things:

  1. give group owners a way to know more about the group members;
  2. give group history showing all changes to the group;
  3. initiate group lifecycle to force action on the group when you need it attested.

This method is more than attestation to make the auditors happy, this is actual attestation that works for the business.  Your group memberhips are going to be more accurate, your group owners will know more about their groups, and you can get rid of groups that you don’t need any more.  Win win win.

Active Directory group attestation