Conditional Access for Zero Trust – Complete Implementation Guide

Introduction – Zero trust is not a product/feature rather a Roadmap to design and implement the 3 basic principles “Verify explicitly”, “Use least privilege access”,”Assume breach” for an organization.

With many different Components of Zero Trust like ZTNA , SIEM & SOAR Solution, Microsegmentation one of the Key Component (I call it Heart of Zero Trust) is the Conditional Access Policies which we will discuss in this documentation.

Planning a Conditional Access Policies (CAP) is a very critical and daunting task to achieve your organization’s access strategies for your applications and resources.

Conditional Access Policies analyze signals from user, device, and location to automate decisions and enforce access policies to organizational resources. Conditional Access policies allow you to create conditions that manage security controls that can block access, require multi-factor authentication, or restrict the user session if necessary and bypass the user if not.

Requirements – Different Organization has different set of resources to protect hence will have different set of CAP requirement. For example, one Organization wants to completely block the access of resources from an unknown Device and the other Organization wants to allow with required security mechanism inplace for e.g MFA. The guidance includes principles that are related to Zero Trust that you can use as Baseline and then address specific company requirements and policies and adjust the architecture accordingly.

Teams to Involve – CISO, Infosec, Governance Team, Identity and Access Management Team, Conditional Access Administrators, Application Team, Service Desk

Questions to Brainstorm –

1. Which users personas, groups, directory roles and workload identities will be included or excluded from the policy?
2. What emergency access accounts or groups should be excluded from policy?
3. Will this policy apply to any application, user action, or authentication context? If yes-
4. What application(s) will the policy apply to?
5. What user actions will be subject to this policy?
6. What authentication contexts does this policy will be applied to?
7. Which device platforms will be included in or excluded from the policy?
8. What are the organization’s trusted locations?
9. What locations will be included in or excluded from the policy?
10. What client app types will be included in or excluded from the policy?
11. Do you have policies that would drive excluding Azure AD joined devices or Hybrid Azure AD joined devices from policies?
12. If using Identity Protection, do you want to incorporate sign-in risk protection?
13. Do you want to grant access to resources by requiring one or more of the following?
    1. Require MFA
    2. Require device to be marked as compliant
    3. Require hybrid Azure AD joined device
    4. Require approved client app
    5. Require app protection policy
    6. Require password change
    7. Use Terms of Use
14. Do you want to enforce any of the following access controls on cloud apps?
    1. Use app enforced restrictions
    2. Use Conditional Access App control
    3. Enforce sign-in frequency
    4. Use persistent browser sessions
    5. Customize continuous access evaluation

License Requirement – Most of the suggested policies are based on E3, with the enforcement of CA policies based on user risk, sign-in risk and device-risk being the exception. So if you don’t have E5 you will have to leave out these Identity related CA policies.

Now, let’s move to Design phase and see what all tasks needs to be completed.

While working on Conditional Access Policies (CAP) with some of my Clients, I noticed that just by looking into the CAP names you can’t easily identify what that CAP policy does, which means either you have to dig into all the CAP settings or try to reproduce the issue to figure out which CAP policy is getting triggered. In order to overcome those challenges, we have to ensure that we design our CAP policies very accurately so that it not only help me to understand but also the other Admins who will take over my responsibilities later.

In this Design phase we’ll define the correct naming convention for CA Policies, Personas/User, Devices, Apps the Policy to be applied and some Industry best practices.

Naming Convention

CA Policy – <CAP#>-<Persona type>-<PolicyType>-<AppType>-<DeviceType>-<Permission>-<OptionalDescription>

Although the current model includes a way to address user-based service accounts, it’s worth mentioning that it’s not recommended by Microsoft to use it. As documented here

The recommendation is to use Managed identities or AAD Service Principals.

Recommended Best Practices

1. The MOST Important Best Practice is to use “Report-only mode” before putting a policy into production.
2. You may also simulate the sign-ins using “WhatIfTool”.
3. Setup Breakglassaccounts in order to mitigate the impact of accidental administrator lockout.
4. Test both positive and negative scenarios and discuss the outcomes with the Business.
5. Always have a Roll back plan ready for a CAP policy, by either Disabling/Excluding/Deleting the policy.
6. Use change and revision control on CAP.
7. Apply Zero Trust principles to Conditional Access.
8. Limited use of block mode for general access, only if/where needed.
9. Assure all applications and platform are protected (CAP has no implicit “deny all”).
10. Minimize the number of CAP.
11. Protect privileged users in all M365 RBAC systems.
12. Require password change and MFA for high-risk users and sign-ins.
13. Block countries from which you never expect a sign-in.
14. Restrict access from devices with high risk (Intune compliance policy with compliance check in Conditional Access).
15. Protect privileged systems (like Azure Mgt. Portal, AWS, GCP).
16. Prevent persistent browser sessions for admins and on untrusted devices.
17. Block legacy authentication.
18. Restrict access from unknown or unsupported device platforms.
19. Restrict strong credential registration.
20. Automate the management of CAP using tools like Azure DevOps/GitHub or Logic Apps.

Conditional Access Policies Exclusions

1. Use security groups for exclusions (cloud-based groups are optimal as changes to such groups would be applied quickly as opposed to a group that is synced from on-premises).
2. Exclude your Breakglassaccounts from all policies with a Breakglassaccounts exclusion group.
3. Regularly review your exclusion group members (e.g. Access Reviews).
4. Exclude your Azure AD Connect service accounts from policies that would prevent it from syncing with an AADC service accounts exclusion group.

Conditional Access Policies Architecture type

This is an important consideration to choose which architecture to follow “Targeted” or “Zero Trust”. The below figure shows the idea of the two architectures (from Microsoft).

There are many arguments and justification given about both the Architectures, however below mentioned this is my own recommendation. (Please perform your own due diligence before Implementation)

Start with CAP for Targeted Apps and in the first phase target all the Microsoft related apps like O365, EXO, SPO, Yammer, Team, Yammer etc.

In the next phases start adding other SaaS based Applications and once all the Apps are included (Microsoft + 3rd Party SaaS Apps) then move to CAP for “All Cloud Apps” (Zero Trust).

(Reason is as per my own experience, we have seen that many of these SaaS vendors have their own MFA using different Authenticator Apps/Device. Educating the end Users to transition from 3rd Party MFA to Azure AD MFA requires lot of communication and effort.)

Summary – Azure MFA can be enabled in two ways :

• “Per-user MFA” on AAD Users page.
• “Conditional Access Policy” on the Conditional Access page.

For all Personas/Users, it is recommended to use “Conditional Access Policy” however for Breakglassaccounts it should be enabled via “Per-user MFA” with one account configured with Microsoft App and other configured with FIDO2/Hardware token.

In this phase, we will now create all the Conditional Access Policies for different scenarios. This is just a recommended guideline and may vary for different Organizations.

***PLEASE all the Policies which we will create have to be first created in “Report-Only” mode, then tested in the real Production environment and then only deployed to the larger audience. ***

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Global Policy

Policy Type: Global Base Protection

Policy Name: CAP001-Global-BaseProtection-AllApps-AnyPlatform-BlockNonPersonas

Summary: This policy limit/restrict access from identities who are not part of any User Personas in Azure AD. Some may want to have the grant control being “Require compliant device” or “Require Multifactor Authentication” as opposed to totally block the access. The below policy suggests blocking all such personas.

Parameters: 

• Users:
  • Include: All Users
  • Exclude: BreakglassAccounts, Admins, Internals, Externals, Guests, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts, Global-BaseProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Grant: Block

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Admins Policy

Summary: For all administrative roles assigned we require a known device as well as a known user and additionally MFA for admins. This is to mitigate against various attacks for admins and mitigate use-cases where end-users are also using the admin accounts from the same workstation/device as their end-user. Microsoft guidance is not to use admin accounts on a standard PC, but rather using a Privileged Access Workstation (PAW), but in practice we see many customers still using two identities on one PC. Device based conditional access works fine when setup correctly for the primary user of the PC, whereas a second browser session running as admin can’t prove device compliance for the admin unless special setup is used.

Policy Type: Admins Base Protection

Policy Name: CAP100-Admins-BaseProtection-AllApps-AnyPlatform-CompliantorAADHJ

Parameters: 

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts , AdminsBaseProtection-Exclusions
• Cloud Apps: All Cloud Apps
  • Exclude: Microsoft Intune Enrollment, SCCM Server App
• Platform: Any Platform
• Grant: Compliant or AADHJ

Policy Name: CAP101-Admins-BaseProtection-AllApps-AnyPlatform-MFA

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts , AdminsBaseProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Grant: MFA

Policy Type: Admins Identity Protection

Policy Name: CAP102-Admins-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts, AdminsIdentityProtection-Exclusions
• Cloud Apps/User Actions: Require security information
• Location: Include: Any
  • Exclude: AVD/Citrix Trusted IPs (whatever relevant)
• Platform: Any Platform
• Grant: Require Compliant or AADHJ

Policy Name: CAP103-Admins-IdentityProtection-AllApps-AnyPlatform-MFAandPWDforMediumandHighUserRisk

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts, AdminsIdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: User risk: Medium, High
• Grant: Require Multifactor Authentication and Password Change

Policy Name: CAP104-Admins-IdentityProtection-AllApps-AnyPlatform-MFAforMediumandHighSignInRisk

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts , AdminsIdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: Sign-In Risk: Medium, High
• Grant: Require Multifactor Authentication

Policy Name: CAP105-Admins-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts , AdminsIdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Client Apps: Exchange Active Sync clients, Other Clients
• Grant: Block

Policy Type: Admins Data and App protection 

Policy Name: CAP106-Admins-AppProtection-MicrosoftIntuneEnrollment-AnyPlatform-MFA

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts, AdminsAppProtection-Exclusions
• Cloud Apps: Microsoft Intune Enrollment
• Platform: Any
• Grant: Require multi-factor authentication

Policy Name: CAP107-Admins-DataandAppProtection-AllApps-iOSorAndroid-ClientAppandAPP

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts , AdminsDataProtection-Exclusions, Admins-AppProtection-Exclusions
• Cloud Apps:
  • Include: All Cloud Apps
  • Exclude: Microsoft Intune Enrollment
• Platform: iOS and Android
• Grant: Require Approved Client App OR Require App Protection Policy

Policy Name: CAP108-Admins-DataProtection-AllApps-AnyPlatform-SignInFrequency

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts, AdminsDataProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any
• Session: Sign-in frequency: 4 hours

Policy Type: Admins Attack Surface Reduction

Policy Name: CAP109-Admins-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms

Parameters:

• Users:
  • Include: Admins
  • Exclude: BreakGlassAccounts, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts, AdminsAttackSurfaceReduction-Exclusions
• Cloud Apps: All Cloud Apps
• Platform:
  • Include: Any platform
  • Exclude: Android, iOS, Windows, macOS
• Grant: Block access

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Internals Policy

Summary: The Internals are users from AD synced to Azure AD who are employees. Require known user and Compliant or Azure AD Hybrid Joined device from any device.

Policy Type: Internals Base Protection

Policy Name: CAP200-Internals-BaseProtection-AllApps-AnyPlatform-CompliantorAADHJ

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-BaseProtection-Exclusions
• Cloud Apps: Include: All Cloud Apps
  • Exclude: Microsoft Intune Enrollment, SCCM Server App
• Platforms: Any Platform
• Grant: Require Compliant or AADHJ

Policy Type: Internals Identity Protection

Policy Name: CAP201-Internals-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-IdentityProtection-Exclusions
• Platforms: Any Platform
• Cloud Apps/User Actions: Require security information
• Platform: Any Platform
• Grant: Require Compliant or AADHJ

Policy Name: CAP202-Internals-IdentityProtection-AllApps-AnyPlatform-MFAandPWDforHighUserRisk

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: User risk: High
• Grant: Require Multifactor Authentication and Password Change

Policy Name: CAP203-Internals-IdentityProtection-AllApps-AnyPlatform-MFAforHighSignInRisk

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: Sign-in risk: High
• Grant: Require Multifactor Authentication

Policy Name: CAP204-Internals-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Client Apps: Exchange Active Sync clients, Other Clients
• Grant: Block

Policy Type: Internals App and Data Protection

Policy Name: CAP205-Internals-AppProtection-MicrosoftIntuneEnrollment-AnyPlatform-MFA

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-AppProtection-Exclusions
• Cloud Apps: Microsoft Intune Enrollment
• Platform: Any
• Grant: Require multi-factor authentication

Policy Name: CAP206-Internals-DataandAppProtection-AllApps-iOSorAndroid-ClientAppORAPP

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-DataProtection, PersonaInternals-AppProtection-Exclusions
• Cloud Apps:
  • Include: Office 365
  • Exclude: Microsoft Intune Enrollment
• Platform: iOS and Android
• Grant: Require Approved Client App or Require App Protection Policy

Policy Type: Internals Attack Surface Reduction

Policy Name: CAP207-Internals-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms

Parameters:

• Users:
  • Include: Internals
  • Exclude: BreakGlassAccounts, Internals-AttackSurfaceReduction-Exclusions
• Cloud Apps: All Cloud Apps
• Platform:
  • Include: Any platform
  • Exclude: Android, iOS, Windows Phone, Windows, macOS
• Grant: Block access

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Externals Policy

Summary: The Externals are users in AD synced to Azure AD who are not employees, like a consultant.

Policy Type: External Base Protection

Policy Name: CAP300-Externals-BaseProtection-AllApps-AnyPlatform-CompliantorAADHJ

Parameters:

• Users:
  • Include: Externals
  • Exclude: BreakGlassAccounts, Externals-BaseProtection-Exclusions
• Cloud Apps:
  • Include: All Cloud Apps
  • Exclude: Microsoft Intune Enrollment, SCCM Server App
• Platforms: Any Platform
• Location:
  • Include: Any
  • Exclude: AVD/Citrix Trusted IPs (whatever relevant)
• Grant: Compliant or AADHJ

Policy Type: Externals Identity Protection

Policy Name: CAP301-Externals-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration

Parameters:

• Users:
  • Include: Externals
  • Exclude: BreakGlassAccounts, Externals-IdentityProtection-Exclusions
• Platforms: Any Platform
• Cloud Apps/User Actions: Require security information
• Platform: Any Platform
• Location:
  • Include: Any
  • Exclude: AVD/Citrix Trusted IPs (whatever relevant)
• Grant: Require Compliant or AADHJ

Policy Name: CAP302-Externals-IdentityProtection-AllApps-AnyPlatform-MFAandPWDforHighUserRisk

Parameters:

• Users:
  • Include: Externals
  • Exclude: BreakGlassAccounts, Externals-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: User risk: High
• Grant: Require Multifactor Authentication and password change

Policy Name: CAP303-Externals-IdentityProtection-AllApps-AnyPlatform-MFAforHighSignInRisk

Parameters:

• Users:
  • Include: Externals
  • Exclude: BreakGlassAccounts, Externals-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: Sign-in risk: High
• Grant: Require Multifactor Authentication

Policy Name: CAP304-Externals-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth

Parameters:

• Users:
  • Include: Externals
  • Exclude: BreakGlassAccounts, Externals-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Client Apps: Exchange Active Sync clients, Other Clients
• Grant: Block

Policy Type: Externals App and Data Protection

Policy Name: CAP305-Externals-AppProtection-MicrosoftIntuneEnrollment-MFA

Parameters:

• Users:
  • Include: Externals
  • Exclude: BreakGlassAccounts, Externals-AppProtection-Exclusions
• Cloud Apps: Microsoft Intune Enrollment
• Platform: Any
• Grant: Require multi-factor authentication

Policy Name: CAP306-Externals-DataandAppProtection-AllApps-iOSorAndroid-ClientApp

Parameters:

• Users:
  • Include: Include: Externals
  • Exclude: BreakGlassAccounts, Externals-DataProtection, PersonaExternals-AppProtection-Exclusions
• Cloud Apps:
  • Include: Office 365
  • Exclude: Microsoft Intune Enrollment
• Platform: iOS and Android
• Grant: Require Approved Client App or Require App Protection Policy

Policy Type: Externals Attack Surface Reduction

Policy Name: CAP307-Externals-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms

Parameters:

• Users:
  • Include: Include: Externals
  • Exclude: BreakGlassAccounts, Externals-AttackSurfaceReduction-Exclusions
• Cloud Apps: All Cloud Apps
• Platform:
  • Include: Any platform
  • Exclude: Android, iOS, Windows Phone, Windows, macOS
• Grant: Block access

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Guests Policy

Policy Type: Guests Base Protection

Policy Name: CAP400-Guests-BaseProtection-AllApps-AnyPlatform-MFA

Parameters:

• Users:
  • Include: Guests
  • Exclude: BreakGlassAccounts , Guests-BaseProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platforms: Any Platform
• Grant: Require Multifactor Authentication

Policy Type: Guests Identity Protection

Policy Name: CAP401-Guests-IdentityProtection-AllApps-AnyPlatform-TOU-CombinedRegistration

Parameters:

• Users:
  • Include: Guests
  • Exclude: BreakGlassAccounts, Guests-IdentityProtection-Exclusions
• Cloud Apps/User Actions: Require security information
• Platform: Any Platform
• Grant: Require Special TOU

Policy Name: CAP402-Guests-IdentityProtection-AllApps-AnyPlatform-MFAforMediumandHighUserandSignInRisk

Parameters:

• Users:
  • Include: Guests
  • Exclude: BreakGlassAccounts, Guests-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: Sign-in risk: Medium, High
• User risk: Medium, High
• Grant: Require Multifactor Authentication

Policy Name: CAP403-Guests-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth

Parameters:

• Users:
  • Include: Guests
  • Exclude: BreakGlassAccounts , Guests-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Client Apps: Exchange Active Sync clients, Other Clients
• Grant: Block

Guests App and Data Protection

Empty for now as Microsoft does not support App Protection Policies and Approved Client App for guest users. Most customers would want to extend these suggested starting policies for guests with some data protection related policies, for example by using MCAS to hinder data leakage. App restriction policies should also be considered for access to SharePoint and Teams for guest users as it can provide a restricted session with read-only access for guest users.

Policy Type: Guests Attack Surface Reduction

Policy Name: CAP404-Guests-AttackSurfaceReduction-AllApps-AnyPlatform-BlockNonO365Access

Parameters:

• Users:
  • Include: Guests
  • Exclude: BreakGlassAccounts, Guests-AttackSurfaceReduction-Exclusions
• Cloud Apps: Include: All Cloud Apps
• Exclude: Office 365
• Grant: Block Access

Policy Type: Guests Compliance Protection

Policy Name: CAP405 Guests-ComplianceProtection-AllApps-AnyPlatform-RequireTOU

Parameters:

• Users:
  • Include: Guests
  • Exclude: BreakGlassAccounts, Guests-ComplianceProtection-Exclusions
• Cloud Apps: Include: All Cloud Apps
• Exclude: Microsoft Intune Enrollment
• Platform: Any Platform
• Grant: Require Terms Of Use

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

GuestAdmins Policy

Policy Type: GuestAdmins Base Protection

Notice that GuestAdmins are excluded from the other set of policies for Admins.

Policy Name: CAP500-GuestAdmins-BaseProtection-AllApps-AnyPlatform-MFA

Parameters:

• Users:
  • Include: GuestAdmins
  • Exclude: BreakGlassAccounts, GuestAdmins-BaseProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platforms: Any Platform
• Grant: Require Multifactor Authentication

Policy Type: GuestAdmins Identity Protection

Policy Name: CAP501-GuestAdmins-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration

Parameters:

• Users:
  • Include: GuestAdmins
  • Exclude: BreakGlassAccounts, GuestAdmins-IdentityProtection-Exclusions
• Cloud Apps/User Actions: Require security information
• Platform: Any Platform
• Grant: Require Special TOU

Policy Name: CAP502-GuestAdmins-IdentityProtection-AllApps-AnyPlatformMFforMediumandHighUserandSignInRisk

Parameters:

• Users:
  • Include: GuestAdmins
  • Exclude: BreakGlassAccounts , GuestAdmins-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Condition: Sign-in risk: Medium, High
• User risk: Medium, High
• Grant: Require Multifactor Authentication

Policy Name: CAP503-GuestAdmins-IdentityProtection-AllApps-AnyPlatform-BlockLegacyAuth

Parameters:

• Users:
  • Include: GuestAdmins
  • Exclude: BreakGlassAccounts, GuestAdmins-IdentityProtection-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Client Apps: Exchange Active Sync clients, Other Clients
• Grant: Block

GuestAdmins App and Data Protection
Empty for now as Microsoft does not support App Protection Policies and Approved Client App for guest users. Most customers would want to extend these suggested starting policies for guests with some data protection related policies, for example by using MCAS to hinder data leakage. App restriction policies should also be considered for access to SharePoint and Teams for guest users as it can provide a restricted session with read-only access for guest users.

Policy Type: GuestAdmins Attack Surface Reduction

Policy Name: CAP504-GuestAdmins-AttackSurfaceReduction-AllApps-AnyPlatformBlockNonO365andAzureAccess

Parameters:

• Users:
  • Include: GuestAdmins
  • Exclude: GuestAdmins-AttackSurfaceReduction-Exclusions
• Cloud Apps: Include: All Cloud Apps
• Exclude: Office 365, Microsoft Azure Management
• Grant: Block Access

Policy Type: GuestAdmins Compliance Protection

Policy Name: CAP505-GuestAdmins-ComplianceProtection-AnyPlatform-RequireTOU

Parameters:

• Users:
  • Include: GuestAdmins
  • Exclude: BreakGlassAccounts, GuestAdmins-Compliance-Exclusions
• Cloud Apps: All Cloud Apps
• Platform: Any Platform
• Grant: Require Terms Of Use

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Microsoft365ServiceAccounts Policy

Policy Type: Microsoft365ServiceAccounts Base Protection

Policy Name: CAP600-Microsoft365ServiceAccounts-BaseProtection-AllApps-AnyPlatformBlockUntrustedLocations

Parameters:

• Users:
  • Include: Microsoft365ServiceAccounts
  • Exclude: CA-BreakGlassAccounts
• Cloud Apps: All Cloud Apps
• Platforms: Any Platform
• Locations:
  • Include: Any
  • Exclude: All Trusted Locations (or Azure/O365 location if possible)
• Grant: Block Access

***Sometimes, you may not be able to control the location from where these accounts are used, which means that you may have to adjust policies accordingly.***

Policy Type: Microsoft365ServiceAccounts Attack Surface Reduction Protection

Policy Name: CAP601-Microsoft365ServiceAccounts-AttackSurfaceReduction-O365-AnyPlatformBlockNonO365

Parameters:

• Users:
  • Include: Microsoft365ServiceAccounts
  • Exclude: CA-BreakGlassAccounts
• Cloud Apps:
  • Include: All Cloud Apps
  • Exclude: Office 365
• Platforms: Any Platform
• Locations: Any
• Grant: Block Access

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

AzureServiceAccounts Policy

Policy Type: AzureServiceAccounts Base Protection

Policy Name: CAP700-AzureServiceAccounts-BaseProtection-AllApps-AnyPlatform-BlockUntrustedLocations

Parameters:

• Users:
  • Include: AzureServiceAccounts
  • Exclude: BreakGlassAccounts
• Cloud Apps: All Cloud App
• Platforms: Any Platform
• Locations:
  • Include: Any
  • Exclude: All Trusted Locations (or Azure Location if possible)
• Grant: Block Access

Policy Type: AzureServiceAccounts Attack Surface Reduction Protection

Policy Name: CAP701-AzureServiceAccounts-AttackSurfaceReduction-AllApps-AnyPlatform-BlockNonAzure

Parameters:

• Users:
  • Include: AzureServiceAccounts
  • Exclude: BreakGlassAccounts
• Cloud Apps:
  • Include: All Cloud Apps
  • Exclude: Microsoft Azure Management
• Platforms: Any Platform
• Grant: Block Access

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CorpServiceAccounts Policy

Policy Type: CorpServiceAccounts Base Protection

Policy Name: CAP800-CorpServiceAccounts-BaseProtection-AllApps-AnyPlatform-BlockUntrustedLocations

Parameters:

• Users:
  • Include: CorpServiceAccounts
  • Exclude: BreakGlassAccounts
• Cloud Apps: All Cloud App
• Platforms: Any Platform
• Locations:
  • Include: Any
  • Exclude: All Trusted Locations (Corp or Azure vNET if possible)
• Grant: Block Access

Policy Type: CorpServiceAccounts Attack Surface Reduction Protection

Policy Name: CAP801-CorpServiceAccounts-AttackSurfaceReduction-AllApps-AnyPlatformBlockNonO365andAzure

Parameters:

• Users:
  • Include: CorpServiceAccounts
  • Exclude: BreakGlassAccounts
• Cloud Apps:
  • Include: All Cloud Apps
  • Exclude: Microsoft Azure Management, Office 365
• Platforms: Any Platform
• Grant: Block Access

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now when we complete our due diligence of a CA Policy using Report-Only mode, now it’s time to perform the testing with actual Personas/Users in a controlled fashion in Production environment and getting their respective feedback.

Follow the Change Management process as we will be making the changes in Production environment which will have an Impact on Users and Services.

Microsoft suggests a ring-based approach to manage CA Policies and testing of new policies in a staged approach. The suggested approach is depicted in the figure below where we introduce a given change in a ring-based approach on a per persona basis.

Depending on the number of users in each persona group and the sensitivity to changes for a given persona, you may want to introduce more rings. It is a balance between controlling risk and overhead in terms of manageability and time required for testing.

The table below shows the new ring-based approach for phased adoption for Internal Persona based on three rings used

*We assume that all CA policies are running in an enabled state for all personas.

Steps in Implementing a new CA Policy:

• Create a new CA Policy with correct naming convention, correct personas and other parameters.
• Put the policy in Report-Only mode and to the Personas Internals-Ring0, the adding Ring1 and Ring2.
• Let the policy run for 2/3 days and address all the issues which are being reported in CA Workbook.
• Potentially adjust the policy and continue running in Report-Only mode till the time all the issues are being resolved.
• Now, assign the Policy to Internals-Ring0 and enable it.
• Test and verify everything are working as expected for a few more days.
• Now, assign the Policy to Internals-Ring1.
• Test and verify everything are working as expected for a few more days.
• Now, assign the Policy to Internals-Ring2.
• Test and verify everything are working as expected for a few more days.
• Now, assign the Policy to Internals-Ring3.
• Test and verify everything are working as expected for a few more days.
• Now, Deploy the Policy to All Internal Users and for any recurring issues hand it over to BAU (Business as Usual) Team.