Not to pick on Microsoft, but I tend to point out, in my talks on regulatory compliance, that two of the most common targets of security auditors are Sharepoint and Active Directory. Both are commonplace, both are easy to use, and therefore both are heavily abused. Sharepoint sites tend to crop up like cockroaches, and too, too often they’re governed by Active Directory groups, which also crop up like cockroaches. Sharepoint’s a great way to leak out documents that should only be shared with a discrete group. If I’m the boss and I say to you, “too many people have access to your department’s docs through your Sharepoint site and the AD group attached to it,” you may say, “besides being tall and handsome, you are also quite correct. I will remedy this problem by creating a second Sharepoint site, and publish a lesser set of docs there, and create an AD group to govern access.” And now you have yet another AD group.
You might also be using internal Sharepoint security, but therein lies a different problem: security that is Sharepoint-specific. In other words, a silo’d solution that doesn’t participate in the larger, enterprise environment.
It can also be quite difficult to track WHO is using a particular group, and for what purpose: single sign-on, authentication, authorization, email list, etc.
I once worked with a company that broke my personally recorded record for Active Directory groups. They had 120,000. Yeah, say it again. They had 120,000 AD groups. That was my all-time high, until I ran into another company, also in the Midwest, with 180,000.
The first customer told me they failed three different audits each year just based on those groups. I told them how we could use Oracle Identity Analytics to help them identify redundant or useless groups, but that cleaning those up would be predictably painful. Otherwise, they would go on doing what they’ve done for years: pay the regulatory fines.
The second company had a completely different approach. They wanted to get rid of their extraneous AD groups. So they started identifying their target groups, and turning them off, a few at a time, and waiting to hear who screamed. If nobody complained about a particular AD group disappearing on them after a month or so, they would nuke that group permanently.
It’s a brute force solution, AND assumes you’ve got a few years to clean up your AD. When you’ve got 180,000 groups, you can’t turn them off fast enough.
Far easier to identify and nuke are rogue accounts or users. If a user account in a target app is not associated with a live user in the enterprise directory, then you’ve got an orphaned (or zombie) account. It has life of its own, even if it has no corporate soul. A simple reconciliation, such as you might run in Oracle Identity Manager, would find that. You can also specify the remedy, either automatic destruction OR a notification to an admin who would have the task of deciding how to handle it.
If you have a whole bunch of users and/or target accounts that may be out of whack for legacy reasons, i.e. you’ve inherited an up-to-now ungoverned mess, you might also consider running an attestation cycle. All the designated managers would automatically be assigned a list of their users, or perhaps a list of the users provisioned to the resources governed by those managers, and the managers would then review their lists, and check off the users or accounts that needed to go away. If the attestation is hooked to the provisioning system, these accounts would then be deprovisioned.
Auditors don’t glumly trudge home after they find piles of AD groups, or hordes of rogue accounts in your system. They go the bar and celebrate all the extra hours they will bill you for ensuring that you fix all the crap they’ve found in your system. Don’t give them reason to celebrate. Identify and exterminate those groups, those accounts. And then YOU can go to the bar. I give you my permission.