How do you discover what permissions an AD group has, if you have no documentation?

Question

You just got hired at company A and the old administrator is no longer there. Requests start coming through for adding users to the internet restrict group. When you look at the groups none of the names make sense and there is no documentation out there to explain what each group has rights to and what it does. That would raise concern to me. For security how do you know if everyone has the correct rights.

How would you discover what the groups have rights to? Is there a tool out there that will find this information for you?

Answer 1

Let me preface what will probably be a longish answer with "There is no simple solution".
Solving this will take some strategic work (which is why I recommended not moving this to SF).

Now I will explain why.

Windows, at its core, is mostly based on the DAC model of access control.
Everything in the OS is securable with an ACL - files, folders, registry, named pipes, sockets, shares, etc etc.

Using AD groups allows you to abstract that into an RBAC-type model, but internally it's still a DAC model. (What I mean is, you can create an ACE (access control entry) for a group (i.e. role), but you're still creating an ACE - and that is what will be verified on access).

Emphasis on "mostly".
There are a few distinct exceptions to this:

1. There is some implementation of MAC - i.e. Integrity Levels (in Vista/7/2008).
   However, this is usually and internal OS protection mechanism, and is usually not leveraged for real access control (other than the built-in UAC). Usually.
2. OS-level privileges. (Though it is possible to specify a specific user to grant these privileges to, it is intended - and functions as - a RBAC model).

But wait, that's just in the OS itself...
Windows, as a platform, allows and encourages applications (3rd party, MS products, and OS addons) to use AD group membership as an RBAC mechanism:

1. 3rd party applications can verify group membership via a simple AD/LDAP lookup - these apps might be storing the group name and resolving on that, or saving the group's SID and querying directly for that.
2. Don't forget SQL Server - this is mainly based on (several different types of) roles, however best practice is usually recommended to add AD groups to these roles, and not the users directly.
3. As long as we're at it, COM+ also manages access by RBAC, but again best practice is to add groups, not users, to COM+ roles.
4. Sharepoint also manages access to sites according to roles / groups / and mailing lists...

Starting to see my point?
I don't want to say it's hopeless, BUT...

To recap:
In order to find the definitive list of permissions a specific group has, you (or a tool) would need to recursively check ALL of the following (and, dont forget to recurse on group membership, too):

• For each server in your org:
  • recursively check ACL on all folders and files
  • recursively check SACL on all folders and files (system access control lists - these control auditing)
  • recursively check owner on all folders and files
  • recursively check ACL, SACL, and owner on all registry keys
  • recursively check ACL, SACL, and owner on all named pipes, processes and threads, services, jobs, etc.
  • Check all OS level privileges (though it is possible this can be made easier using GPOs...)
  • Check all COM+ roles, MSMQ roles, etc.
• For each domain in your AD:
  • Check all domain-level privileges
  • check all GPOs (group policy objects)
• For each database server:
  • Check all server roles
  • check all database roles
  • check all application roles (in MSSQL)
• For each Sharepoint portal:
  • check all server-level roles and privileges
  • check all site-level and list-level roles and privileges
• For each 3rd party application:
  • Check any use of AD groups
  • verify how the app uses these roles:
    -> Group name vs. DN vs. group SID vs. ... e.g. group GUID
    -> does the app explictly check direct role membership, or does it use the "smarter" recursive methods?
  • Note that this applies both to 3rd party packaged products and platforms (e.g. Oracle, SAP, MQSeries, WebSphere... ), and to custom developed business apps.

Is this complete?
Sadly, no. For example I didnt include reviewing all desktops in the org, since those shouldnt have specific AD-group level permissions set on them (except for e.g. Administrators and HelpDesk) - but note that they often do.
But this is not a complete list...

This is the big disadvantage to using a DAC model - the "D" could just as well have been for "Distributed", since there is not central place to look up all these ACLs.
As I noted in What is the difference between RBAC and DAC/ACL?:

• DAC definitions are typically attached to the data/resource, whereas RBAC is usually defined in two places: in code/configuration/metadata (the roles access), and on the user object (or table - the roles each user has).

---

Now, a little about solutions:

• There are several tools to collect different parts of the above lists, e.g. @Ian's answer using powershell scripts to collect folder ACLs. There are many other tools for that (I've been known to use CACLS in the past), some are noted here.
  For requesting a tool/script for a specific part of the list, you might get better ideas at ServerFault. However take into account that it's only one part of the list.
• There are "role management" and "role discovery" products out there, from some of the big vendors, usually in the Identity Management space - I cant specifically recommend one, but worth looking into: CA (formerly Eurekify which was a decent (though not complete) tool), IBM, Oracle.
  Of course there are others, and I would lean heavily towards finding best-of-breed smaller vendors, even from a startup (okay, maybe I am biased ;) ). I mean, from those that havent been bought out by the bigger vendors.
• You could (and probably should, though this is far from trivial) start the process of mapping out the organization, business requirements, and such - aiming for what privileges they should get, and not just what the status quo is right now. Some of the tools mentioned in the previous point could help here.
• If the previous roles analysis and modeling goes well, consider going for a full-blown IdM/IAM/EAM solution. Again, my comments wrt vendors still stands.
• In any event, aim towards minimizing the distribution of ACLs all over the place, and push for minimal RBAC, centralized as much as possible.

And, a final word of warning to those who are lucky enough to be before the unpleasant situation you currently find yourself in:
Definitely look into a centralized authorization platform, such as IdM/IAM/EAM products. (Note that some are much better than others, and some wouldn't even solve this situation either.)

---

tl;dr: You are rightly and truly screwed. See above. ;)
(but all hope is not lost...)

Answer 2

The answer to this depends on exactly how you'd like to see/manage this data. My recommendation would be PowerShell to get all of this.

If you do choose to user PowerShell, you can either use the native AD Cmdlets or Quest's free Cmdlets (http://www.quest.com/powershell/activeroles-server.aspx). To use the native Cmdlets, you must have at least one Windows Server 2008 R2 domain controller in your domain or at least one instance in an AD LDS configuration set that is running on a Windows Server 2008 R2 server - see http://technet.microsoft.com/en-us/library/ee617195.aspx for details.

Effectively, all you have to do is recursively check folder ACLs for a particular Group's access level. There are a few places (here and here) where people make attempts, but given that this is possibly an incredibly large amount of file structure that the script has to navigate, it could definitely take some time. It gets even more complicated for nested groups.

EDIT: @AviD is spot-on about the original command syntax, and it was doing the wrong thing entirely! Edited to be more on-topic.

Answer 3

This can be done through the Windows command prompt as follows:

• Go to the directory you want to save your report to, if none selected it should default to the logged-in user's directory. An example would be cd C:\Users\Administrator\Desktop

• Generate a report using the following command:

  gpresult /s servername /user INTERNAL\user1 /h gpreport.html
  

• The above command will generate a report based on the GPOS and rules applied to the user the report is selected for. This user should be someone who is the member of a certain group or you could create a test user to test the settings of a certain group.

• Another way you could find this information is by editing the GPO and on Windows 2008 you should have an option to see all settings and sort them by status, you could then record all the enabled settings of the GPO.

Answer 4

For the example you give, the fastest DIY way IMO is to:

1. Look at an existing user's account for which you know is already in the internet restrict group and check what groups they are members of.
2. Create a test account.
3. Make this test account a member of one of the same groups found in step 1.
4. On a separate PC, log in to the test account and check if the internet restrict group kicked in.
5. Continue adding groups one at a time, until you find the internet restrict group.

Please note, you will need to logout/login each time you add a group. Also, depending on the size of your organization, you may have to wait a bit for the permissions to propagate among the cluster of servers before you're able to test each group you add successfully. To get an idea of how long this can take, create your own security group that does something like preventing the launching of MS Word or the creation of a PST, and see how long it takes to implement the security group on the test account.