Determining a comprehensive view of access rights in a Microsoft network can be a difficult task – as anyone that has undergone a recent audit can attest. The collection and organization of security data into detailed reports can take significant time and effort. There are multiple reasons that the process of gathering the data is difficult and time consuming, but the common factor is that security information is dispersed throughout multiple security stores.
In a Windows environment, security store information is dispersed in the following methods:
- Security principals (users and groups) are dispersed across Active Directory and member server security databases (SAM)
- Groups can be deeply nested (e.g. group A is in group B is in group C is in ….)
- Group membership can span security databases (e.g. domain\domain admins is in server\Administrators)
- A Windows domain can trust other Windows domains and external Kerberos realms
- Access Control Lists (ACLs) exist on an object being secured
While it is efficient to store the information into a single store, it can present challenges to report on the information. Today’s administrative tools lack the sophistication necessary to provide true access reporting as they are a step or two away from providing a holistic view of access. The following statements point out some of the administrative tool limitations that prevent the ability to effectively report on access.
- Administrative tools impose a limited view of the administrative process and focus on the immediate task instead of the entire identity and access management life cycle. This leaves it up to administrators to validate settings in another tool or trust that the other processes were performed correctly.
- Administrative tools do not provide the linkage necessary to report on identity usage in the environment.
- Administrative tools rely that other provisioning functions have been correctly performed. (e.g. adding a group to an ACL does not allow the administrator to adjust group membership as that requires a separate tool with a separate purpose)
As current administrative tools do not extend beyond their current security context, administrative staff must visit each store, extract the data, and manually merge the data into meaningful reports.
Solving the challenge(s)
As I went about creating a solution, which CSS released last year as a software tool called Distributed Authorization Reporting Tool (DART), I ran across numerous challenges that needed to be solved. Group discovery was perhaps the most significant obstacle faced during development of the solution. Some of the things that made the coding process really interesting were the way that groups functioned and interacted, for instance:
Groups have multiple types (local, global, and universal) and can be security enabled
- Groups can have (sub) groups as members
- Groups can be deeply nested. As the level of nesting increases, the amount of groups that a user needs to be associated with in the reports increases exponentially. For instance, a domain with 20,000 users and 12,000 groups can quickly become 1,600,000 security relations.
- Groups can be nested across security databases (e.g. Domain Admins in a member server’s Administrators group)
- Groups can have more than 5,000 members which requires special handling when enumerating the membership
- User membership in a group is not necessarily granted by being a “member of” a group. Group membership can also be calculated.
Not all users are part of the calculated group “domain users.” A user’s primary group can be reassigned to another group. The lesson being – you can’t treat all users as being a member of the group just because they belong to that domain.
As I broached each issue, I quickly began to see that the inter-relationships of the security data would be pivotal to developing a solution. As I would discover, the key to the solution was to construct a table that showed the relationship of users to groups that could be easily matched against an ACL. I like to refer to these associations as “security chains,” as it shows the user and how they became a member of a particular group.
Stay tuned for my next blog post in the series: The SID remains the same…
