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

  • 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?

    This sounds more like a ServerFault question to me - looking for tools to interpret and refine the current configuration. The security side of this would be deciding what you want users to have access to, but that doesn't seem to be what you're asking about.

    maybe you are correct, I should post this question also on that site. I put it on this site because of my concern of security since, the person would not know what the groups have access to.

    I disagree - this is not a simple technical question of which tool to use. Working on answer that will explain this...

    I didn't say it was an easy answer question. That is probably why i have not found much information out there about it. I appreciate your information and advice.

  • 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...)

    @Ambar, I hope my answer didnt depress you too much...

    Also, please note that I described *worst case scenario* (or at least a direction for higher assurance) - while common, it is possible that its not your case... 'Course, you have no real way of knowing that, but the question is how much is it worth to you (to the org) to find out.

    My answer is a kid in a sandbox compared to this - amazing, AviD.

    Might also want to check out Varonis DatAdvantage. You can determine, by double-clicking a group, exactly which resources its members can access, the level of access, and also show you *actual* access activity (among other things). It will handle with file servers (Windows, NAS, UNIX/Linux), NAS, Exchange, and SharePoint. It currently won't do third-party apps or databases.

    Thanks @RobSobers, I'm familiar with Varonis - they are one of the startups I was referring to - but while they do give a huge improvement, and a great running start, it is still far from complete - especially considering the lack of any support for business apps (the actual majority of sensitive access management), but also beyond that.

  • 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 ( 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 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.

    as I understand it, the OP is asking how to discover what permissions a given group has, whereas the query you show will only find groups that a user is a member of. (Also, btw I believe the syntax is `-ContainsMember`...)

    AviD, absolutely correct.

  • 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.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM