Whoever works with Microsofts cloud offerings and has a role that is somewhat impacted by Security, must have heard of Conditional Access (CA) by now. It is a very essential part of Microsofts Security offering and Zero-Trust-implementation. Rightly, planning, defining, and implementing CA-policies has a lot of coverage on the internet. I’ll try to add a little something which might seem dry, but is essential: How to handle exclusions?
All CA-policies are assigned to groups, users, and machines. With exclusions, CA offers a way to define policies that don’t apply to certain subsets of your landscape. In my example, I will create an exclusion process around a policy that blocks access from certain countries.
Adele Vance, employee extraordinaire, and often protagonist in Microsoft tutorials, will have to visit a conference in one of those blocked countries.
The exclusion process will achieve the following goals:
- Secure: the process is configured in a secure manner and operational risks are minimized.
- Auditable: the exclusion is logged and can be audited.
- Approvals: the exclusion has to be approved by Adeles line manager Megan.
- Automated: No administrative intervention is necessary.
As a side goal, we will implement it all based on standard Microsoft functionality. Oftentimes, enterprises use dedicated Identity and Access Management (IAM) solutions, to achieve a comparable goal for more platforms than Microsoft.
First Consideration: Security
Exclusions can be based on direct assignment, or groups. Those groups can be synced from you local Active Directory (AD), or cloud-only groups from Azure AD (AAD). Azure AD groups can either be Security groups, or Microsoft 365 groups1. I’d strongly advise to use dedicated Azure AD groups, as it minimizes the risk, that an groups is populated withouth knowing it will lead to a CA exclusions. Imagine having a Microsoft 365 group which a Teams owner can populate. Madness.
I would even go a step further, and define the exclusion group as a Privileged Access Group (PAG). These are commonly used to manage privileged permissions in Privileged Identity Management (PIM), but offer security advantages in handling CA exclusion groups. Whilst normal groups can be populated by a large amound of admin roles, think Servicedesk/Helpdesk, PAGs can only be managed by Global admins or Privileged Identity admins, greatly reducing the risk of misconfiguration.
This screenshot shows that a User Administrator role can’t add members to a PAG:
I usually have seen two different groups. One group for temporary exclusions, like our conference example, and one for more permanent exclusions, say an administration workflow does not yet support Privileged Access Workstations (PAW) and needs to be updated in a project. Both groups have different lifecycles and management requirements, but we will get to that.
Second Consideration: Self Service
We now have a secure configuration for CA exclusions. But we don’t want to impact users with the need to find a Global admin. So we offer Self Service, where appropriate2.
For our example we use Access Packages by Microsoft, a Azure AD Premium offering see more.
The process of defining an Access Package, is described well by Microsoft itself.
Third Consideration: Automation
While defining an Access Package, we have to configure the lifecycle of said package. And that is a very important aspect for CA exclusions. As mentioned, I often see two types of exceptions: temporary or permanent. The first type of duration should be solved through automation. Something the lifecycle portion of Access Packages can do.
Depending on the policy, the lifecycle can be configured differently. In this case3, or any case that relates to a exception like holidays, etc. I would recommend something like 15 days. For more critical policies, like anything MFA related, this period could even be shorter.
For the second type of exclusions, I typically use a disconnected Exception To Policy process which might or might not be tool supported. Access Reviews could be leveraged for that case, but I rather have a defined owner per exception and leave tracking and mitigation to those owners.
User Experience
Access from the United Kingdom is blocked by Conditional Access
Adele knows that she needs an exception for her planned trip to the United Kingdom. She can order that exception on myaccess.microsoft.com
Her Manager Megan gets an email, to manage the exclusion request. Of course, the requests are also visible under the myaccess-portal for approvers.
Megan approves the request and adds a justification for audit purposes
Adele is automatically added to the exclusion group
Et voilà, access works after a short signin
I hope Adele has a successful conference and you found some value in that approach.