At STEALTHbits, we often describe Active Directory as holding ‘the keys to the kingdom’. It stores the users and groups that grant access to an organization’s most sensitive information and should be protected for this very reason. From an access management perspective, most administrators will stand behind the best practice of assigning access to groups instead of users. This is because it not only makes administration and management of this access more efficient for them but also has real benefits in terms of the system impact it has on the repositories to which access is being granted.
While using groups to assign access to resources is a well-known best practice, it can be a quite difficult model to adopt. This blog post will take you through some practical ways to accomplish a resource-based groups model with proper AGDLP nesting practices.
The Problem with Direct User Permissions
A common example of this problem is on a file system ACL. Imagine a file share that contains corporate documents that need to be accessible to everyone in the organization, and imagine that your organization has over 500 users. Directly applying 500 permissions on the folder ACL will be overly taxing on the operating system, and will force it to enumerate each and every user SID in the ACL anytime someone is trying to access the given resource. Imagine instead that all users are added to Active Directory security groups, and only a handful of security groups are added to the ACL. Now the system has a lot fewer SIDs to enumerate and can match a user based on their session ticket’s SID entries, which is significantly more efficient than the previously described approach.
Now let’s go back to the example of 500 direct user permissions. This quickly becomes an administrative nightmare in the case of offboarding employees or contractors. Let’s say it’s the organization’s policy to delete users in these cases. The file system ACLs quickly become a list of unresolved SIDs which are time-consuming to track down and clean up, especially if not leveraging third party software like StealthAUDIT.
But maybe the organization is tiny and has less than 50 users today – the admins might be tempted to just directly assign permissions to users. They will quickly be given a reality check when the company grows, more employees and contractors are onboarded, and they end up with the same gigantic and unmanageable ACL.
The Importance of Group Scope
Before diving in too deep with leveraging Active Directory groups to provision access to resources, it’s important to understand group scope. The scope of a group determines where the group can be applied and is especially important in a multi-domain forest. There are three group scopes that can be used when you are creating an Active Directory Group: universal, global, and domain local. The group scope dictates the possible members of the group and where the group can be granted access within the domain. Refer to the table below or this Microsoft article for more details on each scope.
|Scope||Possible Members||Scope Conversion||Can Grant Permissions||Possible Member of|
|Universal||Accounts from any domain in the same forest Global groups from any domain in the same forest Other Universal groups from any domain in the same forest||Can be converted to Domain Local scope Can be converted to Global scope if the group does not contain any other Universal groups||On any domain in the same forest or trusting forests||Other Universal groups in the same forest Domain Local groups in the same forest or trusting forests Local groups on computers in the same forest or trusting forests|
|Global||Accounts from the same domain Other Global groups from the same domain||Can be converted to Universal scope if the group is not a member of any other global group||On any domain in the same forest, or trusting domains or forests||Universal groups from any domain in the same forest Other Global groups from the same domain Domain Local groups from any domain in the same forest, or from any trusting domain|
|Domain Local||Accounts from any domain or any trusted domain Global groups from any domain or any trusted domain Universal groups from any domain in the same forest Other Domain Local groups from the same domain Accounts, Global groups, and Universal groups from other forests and from external domains||Can be converted to Universal scope if the group does not contain any other Domain Local groups||Within the same domain||Other Domain Local groups from the same domain Local groups on computers in the same domain, excluding built-in groups that have well-known SIDs|
Microsoft Best Practice for AD Group Nesting
One of the ultimate goals of any data access governance strategy is to be able to leverage a least privilege model where the appropriate users are granted no more or no less than the necessary levels of access to the data they need to be able to do their jobs. A great way to achieve this is by leveraging a Resource-Based Groups security model where individual groups are used to grant the necessary levels of access to specific shared resources.
While in theory, this sounds straight forward, this can become tricky when group nesting comes into play. The AGDLP model by Microsoft describes the following best practice: User and computer Accounts should be members of Global groups, which are in turn members of Domain Local groups that are used to grant specific Permissions to resources. Refer to our blog post for a deeper explanation into the AGDLP best practice.
For the purpose of this blog post with the goal of achieving a resource-based groups access model, I will reiterate the best practice in a slightly different way: Users and computer Accounts should be direct members of Global groups that represent business roles such as Marketing, Finance, etc, which should then be made members of Domain Local groups which should represent a specific set of Permissions for a specific resource or set of resources such as Marketing_Folder_Read or Finance_Folder_Write.
Things start to get complicated with this “best practice” when it’s not as straight forward as the Marketing department needing access to the Marketing share. What about the folks on the Product Management team who are helping with the upcoming marketing campaign, or the Documentation team members who are helping with creating the collateral? This is when it becomes necessary to take some additional steps to achieve a least privilege access model beyond just the basics.
Practical Steps to Achieve a Least Privilege Access Model
A Resource-Based Group model is the easiest to manage and most suitable for facilitating entitlement reviews and self-service access requests enabling data custodians to control the access to their data, and ensuring that any least privilege model stays that way in the future.
It goes without saying that if least privilege access isn’t a day one initiative being done during the planning phases of an organization’s Active Directory and application or system deployment, then there are several steps that should be taken to prior to creating and assigning any resource-based groups.
Cleanup the Active Directory Mess
There are bound to be several conditions worth cleaning up in Active Directory that should be addressed before exponentiating the issue with more groups and group memberships to manage.
- Empty, Duplicate, or Single Member Groups – These groups are not adding any value but instead are adding to the headache and mess. Locate and get rid of these groups
- Circular Nesting – Circular nesting is an example of when nesting AD groups have gone wrong. Not only can this lead to excessive privileges being assigned to users unknowingly, but can also have detrimental effects on the applications or scripts that leverage these groups. Identify where this condition exists and clean it up.
- Stale Groups – For simplicity, a stale group can be thought of as a group that has stale group members, users that have not authenticated to the domain in a large period of time. Remove the stale users or the entire group in the case that all of its members are stale.
Another key piece of cleaning up Active Directory groups is understanding where these groups are being used, whether that be in a File System server, or a SharePoint farm, or even within Group Policy. This needs to be understood to avoid any unexpected impact from cleaning up a group that is being used for a critical application.
Prioritize Your Efforts
Understanding that there will be a lot to get done, organizations will need to prioritize their efforts based on factors such as data sensitivity. Least privilege access models will be most important when protecting access to critical data assets such as PII or PCI data, or intellectual property.
Organizations should use native or third-party tools to understand their data landscape from the perspective of where sensitive data exists. Understanding who has access to this data is important, but even more important is understanding who actually needs access to this data.
Monitor User Activity
Monitoring user activity is a key step in the journey of understanding who needs access to what resource. This will help to make educated decisions not only on the who but on what level of access is required.
For example, If Ann from Product Management has Read&Write access to the Marketing Folder, but through activity monitoring, it is determined that she has only ever performed Reads against that folder, then an informed decision can be made to reduce Ann’s rights from Read&Write to Read.
This type of monitoring also helps to avoid the byproducts of methodologies such as role-based permissioning which can assume that two people serving similar roles require the same level of access to the same things. Just because Ann requires Read access to the Marketing folder, doesn’t mean that Sal from Product Management does as well.
Understanding the activity events that are taking place, or better yet not taking place, can lead to much more informed access-related decisions. In this case, instead of adding the entire Product Management global group as a member of the Marketing_Folder_Read domain local group, it may be a better idea to add specific exception groups that will have these outliers, such as Ann, as members.
Identify Data Owners
Organizations should identify these data owners before deploying a resource-based groups model, which will ensure that these efforts can last the test of time. Using data points such as file and folder ownership and organizational hierarchy can lead to well-informed decisions of who these data owners are. Once determined these data owners can make the informed decisions on a periodic basis. Data owners, or Data Custodians, serve a pivotal role in the Governance process that no one else can do as well as they can, which is determine who does and who doesn’t get access to THEIR data.
Maintain Data Access Governance for the Long term
With all of the key pieces in place including a clean active directory, data custodian identification, understanding of where sensitive data exists, and an understanding of the activity that is occurring within the environment, organizations can be prepared to deploy a resource-based groups model that will help to maintain data access governance in the long run.
This type of model puts organizations in the position to perform the key tasks associated with a proper governance strategy including things such as
- Self-Service Access Requests – This process allows end-user access requests to data resources to be routed directly to data custodians for approval, rather than to IT resources – saving lots of time and bolstering proper decision-making with regards to data access. End users can request the level of access they require and can consequently be placed in the appropriate resource based group.
- Entitlement Reviews – This process allows for periodic review and adjustment of access rights by data custodians to ensure access privileges and permissions remain at proper levels. With the appropriate resource-based groups in place, user access levels can be adjusted with ease based on the level of access end-users actually require.
To learn more about how to achieve least privilege access using a Resource-Based Groups model, visit our website
Farrah Vijayan is a Director of Technical Product Management at STEALTHbits Technologies. She is responsible for building and delivering on the roadmap of STEALTHbits products and solutions.
Since joining STEALTHbits in 2012, Farrah has held multiple technical roles, including Scrum Master and Quality Assurance Manager. Farrah holds a Bachelor of Science degree in Industrial Engineering from Rutgers University