Many organizations control access to internal systems by simply relying on whether or not an account is enabled. However, users often change roles throughout their careers within a single organization. For example, a user might start as an intern in one department and then be hired full-time in another department. After a few years, they might go back to school for further training and then switch departments again. At this point, the user might still have access to resources in three different areas, even though most are no longer relevant to their role in the organization.
Another example of access control issues is in situations where the line between multiple roles on a single account is blurred (e.g., students, affiliates, and employees). Simply disabling someone’s account when they leave a role would mean a loss of access to resources they may still need as part of another role. For example, a university employee might quit their on-campus job but still be a student at the institution. Completely disabling this person’s account might prevent them from completing their coursework. Azure Active Directory (AD) access reviews can help with this problem by forcing the user, a manager, or an administrator to periodically attest to the user’s need for access. However, it could be several months before the user’s access is cleaned up. In addition, this approach does not scale well for groups that may include thousands of individuals.
Fortunately, Azure AD offers a solution to help automate access control.
Automated Access Control
You probably have a lot of attributes already set in your Azure AD tenant, such as department, manager, location, etc. You also have 15 built-in “extension” attributes that can contain whatever value you would like, along with the ability to extend the schema through a custom app registration. Ideally, these attributes are automatically maintained from a source of record, such as your HR system. This allows your Azure AD tenant to automatically update whenever someone in your HR department makes an update in the HR system for an employee. (As a side note, if you do not have automated inbound provisioning set up for either your on-premises AD or Azure AD environment, reach out to our experts for help.)
You can leverage your automated attributes to create an “access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy” (NIST 800-162). In more informal language, you should set up access to be automatically controlled based on the values of those attributes, instead of using manually maintained groups.
Let’s get started!
Natural Language Policy
When automating access control policies, whether you are using dynamic membership rules on a group in Azure AD, a different automated group management tool, or even custom scripts, you should first think about and describe the access you want to grant in “natural language.”
For example, rather than saying “I want the group to be populated by all users that have extensionAttribute12 set to ‘yes’,” consider using clearer or more natural language such as “I want the group to be populated by all users who have completed security training.”
Outlining your access policies in natural language does two things. First, it allows you to talk about the policies at a level that everyone in the organization can understand. For example, how many people outside your identity and access management (IAM) team know what extensionAttribute12 means or what specific values mean? Second, outlining your policies keeps you from jumping to a technical solution before fully understanding and vetting with stakeholders what the policy might entail. For example, suppose there is more to completing compliance training than you originally thought—such as the training is only required for employees working in Wisconsin. Your original description of the policy on a technical level probably would not have met that requirement, but you wouldn’t have realized it if you had not discussed the potential policy in “natural language” first.
Once you have written out your policy in natural language and vetted it with the relevant stakeholders, you can use dynamic membership rules on a group in Azure AD to implement the policy.
Dynamic Membership Rules in Azure AD
Azure AD’s dynamic membership rules feature allows you to use any attributes from Azure AD’s base set or custom extension properties from an app registration to construct groups that automatically add and remove members based on those attributes’ values. Groups with dynamic memberships can be either Microsoft 365 or Security groups.
To use dynamic membership rules, you need at least enough Azure AD P1 or P2 licenses for the number of members that will be in the group. However, each user does not need a P1 license assigned in order to be added to a group with a dynamic membership as long as there are at least as many P1/P2 licenses as members to be added.
We have a variety of query operators to work with and are not constrained by simple attribute = value. For example, we can set up expressions based on an attribute containing a certain string, starting with a particular value, or being in a list of values. We can even use a match operator and use a regular expression for extra-complicated rules.
Membership rules can contain multiple expressions joined by or, and, and not. However, we discourage the use of not whenever possible and suggest constructing only positive rules in order to avoid accidentally removing someone.
For instance, suppose a user has two locations represented as “Medical Center ; Business School” in a single-valued attribute and we set up a rule to include everyone who is not in the medical school. Although our intention is to still include this person since they also have a location in the business school, we have accidentally removed them. In this case, it would be better to use the “-contains” operator on the location attribute to positively represent all the buildings joined together by “-or” instead of trying to subtract only the medical center.
In Part 2 of this blog post, we will dive into a couple of examples for building out access policies using Azure AD’s dynamic membership rules feature.
Now that you know the basics of what to consider and what tools to use to automate access control, are you ready to get started? Whether you want to clean up access in an existing environment or you are starting fresh, the experts at Ravenswood Technology Group have the business and technical expertise you need. We can take you through all the stages of making automated access control a reality in your organization. Part 2 includes a follow-up on implementing your access policy as dynamic membership rules on an Azure AD group.
Can’t wait for the follow-up? Contact our experts today!