Design scenario based Conditional Access Policies notes from the field

Note: This article was first published on www.procloudguru.com by Alpesh .Since the website is down, I am publishing it here.

This blog has taken long to write as compared to the other blogs I usually write. I was unable to foresee how to write this as the topic is vast and the scenarios can be unlimited. However, I am going to try my best to not confuse you and I hope to meet the objective that I set before writing this blog (which is to share a sample design for Azure AD Conditional Access Policies aka AAD CP).

I trust and believe that most of the common scenarios affecting financial orgs will be covered by the policies in this blog. Therefore, please take out some time to go through the complete write-up. I have tried to provide as much reference material for deeper understanding as well. You can comment below if you need any clarifications or want me to help you with any specific scenarios.

Before I share the scenarios let me share a little bit about Azure AD Conditional access policies. You may read more about it here. These are very powerful and provide a greater level of protection in terms of which devices you allow; from which locations you allow; if you want to enforce multifactor based on locations or sign-in risks or if you want to only allow access via certain apps so that the O365 data is secure.

In my experience of implementing these policies I have noticed that it also helps secure the “Azure Portal” and likewise you can control from where the users can access the Azure Cli if your Microsoft Azure subscriptions is integrated with the same Azure AD as your O365. You can enforce all administration activities for Azure and O365 to be done only via corporate network and all administrators must required MFA at all times. Azure AD Conditional access policies in conjunction with Intune MDM/MAM provide greater level of device and data control.

Do note that whatever I describe in this article, to achieve it, you must have at least EMS E3 plan and an O365 subscription. I deployed these policies in production with 15k plus users and we had O365 E5 and EMS E5 subscription. Please do validate what kind of subscription plan you are enrolled into before going any further in this document.

Understanding below terminologies/technologies which come together to provide you the control, can help you further understand the deployment of the policies

Azure AD Conditional Access Policies. Read here and here

AADCP What-If: Read here

Hybrid Azure AD Join: Read here

Intune App Protection Policies; Read here and here

Azure MFA: Read here

Azure AD Application Proxy: Read here; here and here

Managed/Edge Browser from Intune: Read here

Key assumptions for this setup. If these assumptions are same to your environment, then these policies may help you too.

a) Hybrid setup. That is you sync your identities from On-Prem to Azure AD.

b) Intune is your chosen device management or application management solution.

c) You have necessary EMS/O365 licenses to proceed.

d) You have a federated setup (ADFS is in use). Though I believe if you have pass through authentication setup that should also work. But the infra in which this setup is done we had ADFS.

e) You understand that Azure AD conditional Access policies can cause issues so you will test this in lab first before you touch production. If you do not have a lab infra, please test the policies on groups first. When we deployed these policies, we already had lot of pilot users. We managed to get these tested using groups and when we were satisfied that the policies are setup correctly, we changed the policy scopes to include the rest.

Pre-Requisites:

a) Azure AD Tenant must be setup.

b) Azure AAD connect must be up and running and synchronizing your identities to your cloud.

c) Microsoft Intune must be setup as the device management tool.

d) You already have some of the O365 services up and running or are in pilot phase to test these settings on.

e) Identify naming convention for the Azure AD Conditional access policies and Intune App Protection policies so that you easily understand and identify them.

f) You assign O365 and Intune licenses via On-Prem AD groups. You may use Azure AD groups as well. Create group Global-IntuneUsers to allocate licenses. It is a best practice to allocate licenses on AD group membership rather than assigning the licenses directly from portal. Your IAM process should then take care of license allocation and removal by simply adding or removing the users to the above group while onboarding or off boarding an employee. This saves valuable time and also helps with reporting in future.

g) Administration accounts such as Global Administrators; Exchange Administrators; Sharepoint; Intune etc. are separate accounts. They should not be same as the normal AD account which are used to logon to laptops/desktops for accessing email and other services. Segregation of accounts is a must.

Before you start configuring the policies and deploy in production make note of these accounts so that you don’t end up locking yourselves. Please be extra careful.

a) Account used by AAD sync (default/custom). Also make sure to ensure the security of your O365 deployment the server where AAD connect is running is Hybrid Azure AD joined. If you are using default account, you will have to exclude the account from certain policies. I will share that when we configure each policy.

b) Global Admin accounts.

c) Default Global Admin Account.

Most of the policies and scenarios described here are for a financial institution with below requirements:

a) Block access to all O365 services from internet if users do not have “Intune” licenses. Do note by default all O365 services are accessible from the internet. And therefore it becomes very important to have right set of policies to ensure data is protected and only accessible in controlled manner. Only allow from corporate domain joined laptops.

b) Provide mobility to users in the org who have Intune licenses on iOS and Android thus enabling collaboration from any mobile device; anywhere securely. Do not control end user devices in general but manage the data on those devices so that users have full freedom to choose range of available devices in the market (at least for Android). This policy ensures that when a user for e.g. configures outlook on native mail client they will be asked to use “Outlook for iOS and Android”.

c) Allow all users in the org who may or may not have Intune licenses but need to access O365 from corporate windows devices (Windows 7 and Windows 10 BYOD supported); however, for older Windows 7 systems allow O365 services after ensuring that those devices are domain joined or hybrid azure AD joined.

d) Block access from all other OSes except iOS/Android/Windows.

e) All Admins must enroll for MFA and can only access management of Office and Azure portal from Corporate Network

f) Block access for All Admins to Office 365 and Azure portal if outside of Corporate Network (BE VERY CAREFUL WITH THIS POLICY. VALIDATE MULTIPLE TIMES BEFORE SAVING IT).

g) All Users must enroll for MFA and will be prompted for MFA only when outside of corporate network

Also make sure you configure Intune App Protection Policies for all Intune Managed apps (also approved client apps in Azure AD Portal). Please refer to the articles here to configure the app protection policies for iOS/Android and WIP  policies for Windows 10.

Intune App Protection Policy

For Windows 10: WIP

Read here –> http://eskonr.com/2017/10/intune-windows-information-protection-wip-policies-test-cases-and-notes-from-the-field/

Read here –> http://eskonr.com/2017/10/allow-3rd-party-browsers-on-windows-10-devices-that-are-applied-with-windows-information-protection-wip-policies-using-intune/

For iOS/Android: https://docs.microsoft.com/en-us/intune/app-protection-policies

Read here for Android –> https://docs.microsoft.com/en-us/intune/app-protection-policy-settings-android

Read here for iOS –> https://docs.microsoft.com/en-us/intune/app-protection-policy-settings-ios

Visualizing how the policies actually take effect in real world scenario.

Now coming back to the policies. Here is the configuration you will need for them.

a) Block access to all O365 Services from internet if users do not have “Intune” license.

Policy Objective:

Block access to all O365 services from internet if users do not have “Intune” licenses. Do note by default all O365 services are accessible from the internet. And therefore it becomes very important to have right set of policies to ensure data is protected and only accessible in controlled manner. Only allow from corporate domain joined laptops.

Technical configuration of the Policy:

Assignments:

Applied to : All Users

Excluded : Global-IntuneUsers group, Exclude the AADSync account; exclude the global admins. Explanation: Intune users group is excluded because there is another policy in step b) that will apply to intune users. For now by applying this policy to all users and excluding Intune users group what we are doing is enforcing users to enroll the devices to Intune. Because users dont have intune license they will not be able to enroll the devices. And since we are putting a condition for all users stating that they must enroll their devices to access any cloud app, now they will be denied access to any cloud app from their personal devices.

Cloud Apps: All Cloud Apps

Conditions:

Device Platforms: Select “All Platforms (including unsupported)” and Exclude “Windows and Windows Phone”

Client Apps: Select “Browser” and “Mobile Apps and Desktop Clients”

Access Controls:

Grant access if “Require device to be marked as compliant” and “Require domain joined (Hybrid Azure AD)” and select “Require one of the selected controls”

b) Provide mobility to all users in the org who have Intune licenses on iOS and Android

Policy Objective:

Provide mobility to all users in the org who have Intune licenses thus enabling collaboration from any mobile device; anywhere securely. Do not control end user devices in general but manage the data on those devices so that users have full freedom to choose range of available devices in the market (at least for Android).

Technical configuration of the Policy:

Assignments:

Applied to : Global-IntuneUsers

Excluded : Global-IntuneUsers group, Exclude the AADSync account; exclude the global admins. Explanation: This policy applies to only those users who will have intune licenses. This will allow them to “register” their mobiles to Azure AD to access O365 services only from approved client apps. Inturn, all the approved client apps will be applied the Intune App Protection Policy.

Cloud Apps: All Cloud Apps

Conditions:

Device Platforms: Select “iOS and Android”

Client Apps: Select “Browser” and “Mobile Apps and Desktop Clients”

Access Controls:

Grant access if “Require approved client app” and select “Require one of the selected controls”

c) Allow all users in the org who may or may not have Intune licenses but need to access O365 from corporate windows devices (Windows 7 and Windows 10 BYOD supported)

Policy Objective:

Allow all users in the org who may or may not have Intune licenses but need to access O365 from corporate windows devices (Windows 7 and Windows 10 BYOD supported). Those who have Intune licenses can enroll their personal windows 10 devices. Those who do not have Intune licenses can use their windows 10 or windows 7 domain joined/hybrid azure ad joined devices for O365 access.

Technical configuration of the Policy:

Assignments:

Applied to : All Users

Excluded : AADSync account; exclude the global admins.

Cloud Apps: All Cloud Apps

Conditions:

Device Platforms: Select “Windows and Windows Phone”

Client Apps: Select “Browser” and “Mobile Apps and Desktop Clients”

Access Controls:

Grant access : Select “Require device to be marked as compliant” and “Require domain joined (Hybrid Azure AD)” and select “Require one of the selected controls”

d) Block access from all other OSes except iOS/Android/Windows. (Please be very careful here)

Policy Objective

Block any OS that is not iOS/Android and Windows.

Technical configuration of the Policy:

Assignments:

Applied to : All Users

Excluded : None

Cloud Apps: All Cloud Apps

Conditions:

Device Platforms: Select “All Platforms (including unsupported” and Exclude “iOS/Android/WIndows/Windows Phone”

Access Controls:

Block access

e) All Admins must enroll for MFA and can only access management of Office and Azure portal from Corporate Network

Policy Objective

Enforce Administrators to enroll for MFA and apply location based policy so that they can only access O365 Portal from corporate network.

Technical configuration of the Policy:

Assignments:

Applied to : Global Admins; Exchange Admins; SharePoint; Intune; Service Administrators; Security readers etc.

Excluded : AADSync account;

Cloud Apps: All Cloud Apps

Conditions:

Device Platforms: Select “All Platforms (including unsupported)”

Locations: All trusted locations

Client Apps: Select Browser and Select Mobile Apps and Desktop Clients

Access Controls:

Grant access: Select “Require multi-factor Authentication” and “Require domain joined (hybrid Azure AD). For multiple controls select “Require all the selected controls”.

f) Block access for All Admins to Office  365 and Azure portal if outside of Corporate Network (BE VERY CAREFUL WITH THIS POLICY. VALIDATE MULTIPLE TIMES BEFORE SAVING IT).

Policy Objective

Do not allow administrative activities outside of corporate network. In case administrative accounts are compromised this policy will help to prevent access from internet.

Technical configuration of the Policy:

Assignments:

Applied to : AADSync account; Global Admins; Exchange Admins; SharePoint; Intune; Service Administrators; Security readers etc.

Excluded : None

Cloud Apps: All Cloud Apps

Conditions:

Device Platforms: Select “All Platforms (including unsupported)”

Locations: Any Location and Exclude “All Trusted locations”.

Client Apps: Select Browser and Select Mobile Apps and Desktop Clients

Access Controls:

Block access

g) All Users must enroll for MFA and will be prompted for MFA only when outside of corporate network

Policy Objective

Enforce users to enroll for MFA and apply location based policy so that they get promoted for MFA outside of corporate network.

Technical configuration of the Policy:

Assignments:

Applied to : All Users

Excluded : AADsync account; Global Admins; Exchange Admins; SharePoint; Intune; Service Administrators; Security readers etc.

Cloud Apps: All Cloud Apps

Conditions:

Device Platforms: Select “All Platforms (including unsupported)”

Locations: Select “Any locations” except “All Trusted Locations”

Client Apps: Select Browser and Select Mobile Apps and Desktop Clients

Access Controls:

Grant access: Select “Require multi-factor Authentication” For multiple controls select “Require all the selected controls”.

With the above setup this is what we achieve:

• We blocked users who do not have Intune license to access any O365 service from internet. We only allow them to access from corporate laptops from office network or vpn.
• We allow users with Intune license to access O365 services from iOS/Android/Windows7 and windows 10 (corporate/BYOD).
• We blocked all O365 access from non-supported OS. Only iOS/Android and Windows are allowed.
• We enforced administrators of O365 Portal or Azure Portal to enroll for MFA and access from trusted zone.
• We blocked administrators to access O365 services from internet and enforce them to use MFA and only allow management from corporate network.
• We enforced MFA for all users however ensured that when they are in corporate network or trusted network they are not enforced for MFA.

Before I wrap up I would like to share with you that the what-if tool provided with the Azure AD Conditional Access policies is a very powerful tool and always use it before deciding to make any changes to the CA policies. This will help you take informed decisions. Again these policies are something that once setup should not require regular changes and therefore must fall into the Change management process. Do also note that any inadvertent changes can have quite outspread effects. So please be very careful while making any changes to the Conditional Access Policies.

These policies are in-effect for a setup with 15k plus users and quite effective.

This article was first published on www.procloudguru.com by Alpesh but the website no more exist, hence re-publishing the content.

Hope this post is useful!