Conditional Access
Microsoft 365
Problem
Office 365 offers some fantastic benefits over traditional on-premise infrastructure. No costly infrastructure required, no advanced IT knowledge required, 100 GB mailbox, online meetings, document collaboration, 99.9 % uptime, flexibility allowing businesses to provide users with only the services they need and anytime and anywhere access to emails, documents, contacts, and calendars on any device.
This blog will explore the last benefit – anytime and anywhere access to Office 365.
As the image suggests, Office 365 means that we can all do our jobs from anywhere (coffee shop, pub, home) on any device we want to use. In reality, most companies do not work this way and do not want to work this way. For a lot of companies, Office 365 solves the problem of not requiring infrastructure, complicated exchange deployments and HA/DR as data is now in the cloud so is not the IT department’s problem.
The ‘Anytime and Anywhere Access to Office 365’ does, however, highlight the following security concerns for Office 365 deployed with ‘out of the box’ settings.
- Office 365 can be accessed from anywhere – not just in the office, anywhere there is internet access.
- Office 365 can be accessed from any device – not just corporate owned devices, any device (Personal Windows/Mac laptop, tablet, phone, any device with a browser or Outlook client installed).
- Office 365 can be accessed by just a username and password.
From a data loss prevention point of view, this causes the following issues:
- Emails can be cached offline and copied elsewhere on a home PC with Outlook.
- Mail can be downloaded to mobile devices and copied to other locations.
- OneDrive for Business can be synced offline to a home PC and all data copied elsewhere/shared.
- SharePoint Online can be synced offline to a home PC and all data copied elsewhere/shared.
- Multi-factor is not turned on by default for Office 365 – To login only a username and password is required.
I always highlight this issue during my first workshop with a new client about to move some services to Office 365. Some clients accept this behaviour as being the new flexible working world, most clients do not; and I can see the Security Manager fall off their chair about moving services to the cloud!
The old solution to these issues with on-premise environments used to be VPNs. VPNs control who can and cannot connect to on-premise data. However, once we start moving data/resources into the cloud, we need to implement different solutions to control access to our data.
The majority of requests for lock down of Office 365 are as follows:
- Can we lock down access to Office 365 to our company offices?
- Can we lock down access to Office 365 to our corporate devices?
- Can we provide additional security during login process – i.e., MFA?
The answer to these security questions is yes: Azure offers Conditional Access to lock down Office 365. However, as with most things in life, it will cost you a bit extra. For this additional service, each user will need an Azure AD Premium license which also comes bundled in Enterprise Mobility and Security Suite – nothing comes for free.
Solution
Microsoft introduced Conditional Access to resolve this problem. Conditional Access allows administrators to control what Office 365 apps users can gain access to based on if they pass/fail certain conditions.
Policy Conditions
The following conditions can be controlled by the policy:
- Users/Groups – What users do you want to control – Users can be included/excluded from the policy if required. You will always get the person who is too important for this policy and wants to access everything from their personal iPad. It also allows you to test policies before rolling out to the wider business avoiding locking everyone out!
- Cloud Apps– What apps do you want to control? Conditional Access does not need to apply to all of Office 365, you can be more granular and just control access to specific apps – E.g. Exchange Online.
- Client App – Control what app/software the user is connecting from to the data – E.g. allow browsers but disable mobile and desktop Outlook apps.
- Device Platform – Control what devices users can connect from – E.g. allow Windows and iOS but block Android phones.
- Location – Control what IPs can connect to Office 365 – E.g. could limit this to the office external IP.
- Sign In Risk – Control signs in if Office 365/Azure thinks the sign in is not coming from the genuine user – E.g. if someone signs in from London then New York 30 mins later.
Based on the conditions above, access can be allowed to Office 365 with the following conditions:
- Require multi-factor authentication– User is allowed in but will need to complete additional security to log in, e.g.:
- Phone call
- Text message
- Mobile app
- Require device to be marked as compliant – Device must be Intune compliant, E.g. the device must match the Intune compliance policies to be able to connect.
- Require domain joined (Hybrid Azure AD) – Devices must be Hybrid Azure AD joined – E.g. Mobile Devices Azure AD registered and domain joined machines are set to automatically register in their Azure AD.
- Require approved app – You can select the requirement to grant access only if a connection attempt was made by an approved client app. These apps support Mobile Application Management (MAM) policies, so administrators can wrap security around these apps (e.g. stop copying and pasting information out of these apps).
User Experience for requirements
The above settings offer a wide range of options for restricting access to Office 365. Let’s take our three most common requests and show the user experience if they try and access Office 365 from non-compliant devices:
- Can we lock down access to Office 365 to our company offices?
- Can we lock down access to Office 365 to our corporate devices?
- Can we provide additional security during log on process – i.e. MFA?
Can we lock down access to Office 365 to our company offices?
For this example, we have restricted access so that users can only connect to Office 365 if they are coming from the corporate IP range (external).
| The following Settings were configured in Azure Conditional Access. |
| Block access to Exchange Online based on location. |
| The following screen details the end user experience for a user accessing Office 365 from a device that is not coming from the corporate IP address. |
| User logs into Office 365 with credentials. |
| Azure Conditional Access identifies that the user is not coming from a trusted IP address and blocks access. |
Can we lock down access to Office 365 to our corporate devices?
For this example, we have restricted access so that users can only connect to Office 365 if they are on a domain-joined device or mobile device that has been enrolled in Intune/Azure AD. Below is the user experience if a user is on a non-domain joined machine:
| The following settings were configured in Azure Conditional Access. |
| Allow access to Exchange Online based on device – I.e. only allow if a device is domain joined and registered in Azure AD. |
| The following screen details the end user experience for a user accessing Office 365 from a non-domain joined machine. |
| User logs into Office 365 with credentials. |
| Azure Conditional Access identifies that the user is not coming from a domain joined machine and refuses the connection – The following screen shows the OWA experience. |
| Azure Conditional Access identifies that the user is not coming from a domain joined machine and refuses the connection – The following screen shows the Outlook 2016 experience. |
Can we provide additional security during log on process – i.e. MFA?
For this example, we have configured additional security for users accessing Office 365 if they are NOT coming from the corporate IP range (external). Please note, MFA only provides additional security if the user has the correct MFA devices they can log in to Office 365 from any device.
| The following settings were configured in Azure Conditional Access. |
| Require additional security to Office 365 if accessing from non-corporate IP range. |
| The following screen details the end user experience for a user accessing Office 365 from a device that is not coming from the corporate IP address. |
| User logs into Office 365 with credentials. |
| Azure Conditional Access identifies that the user is not coming from a trusted IP address requires additional security. |
| The user will need to approve additional security on their phone – e.g. Azure Authenticator App. |
Policy 1 of 7: Can we enforce Multifactor Authentication for users?
In this example, we have setup a policy to ensure users are only able to access the Microsoft 365 system if they have multifactor authentication setup for there account .
1. Sign In to Entra ID Portal:
– Go to the Azure portal: https://entra.microsoft.com/
– Sign in with an account that has administrative privileges.
2.Navigate to Protection:
– In the left-hand menu, click on “Protection”.
3. Conditional Access:
– In the Under the protection menu, select “Conditional Access”.
4. New Policy:
– Select “New policy from Template”
5. Secure Foundation:
– Select “Secure Foundation” from top menu
6. Require multifactor authentication for all users:
– Select “Require multifactor authentication for all users” from the items below
7. Adjust Policy state and save:
– Set policy name as per your requirements eg “CA01 – Require multifactor Authentication for all users”
– Set policy state based on your requirements
- off
- on
- report only
– Save the policy once you are happy with the settings.
Policy 2 of 7: Can we restrict access to specific countries?
In this example, we have setup additional security to ensure users are only able to access the Microsoft 365 system from there country, and block access to all other countries.
1. Sign In to Entra ID Portal:
– Go to the Azure portal: https://entra.microsoft.com/
– Sign in with an account that has administrative privileges.
2.Navigate to Protection:
– In the left-hand menu, click on “Protection”.
3. Conditional Access:
– In the Under the protection menu, select “Conditional Access”.
4. Named Locations:
– Once in the conditional access main menu, select “named locations”
– Sign in with an account that has administrative privileges.
5.Navigate to Countries location:
– In the top menu, click on “Countries location”.
6. Country Selection:
– In the right hand menu, select the countries where your offices are located.
6. Save Selection:
– Save your selection by selecting “create”.
7. Create policy:
– Select “New Policy” from the top menu.
8. Name Policy :
– Set name of policy eg”CA02 – Block Access from Other Countries”.
9. Users to affect :
– In the “Users” menu, set the include sub menu to “all users”.
10. Exclude admin account :
– To ensure you are never locked out of your Microsoft 365 tenant, select the sub menu “exclude” then select your administrator account .
12. Set Conditions :
– Select the “Conditions” menu
– Select “Locations” Menu
– Select “yes” under configure
– Select “Exclude”
– From the right hand side menu. select “Approved Countries”.
13. Set Filter for devices :
– Select the “Filter for devices” menu
– Select yes on the “Configure” Menu on the right hand side.
– Select “exclude filtered devices from policy” under configure
– Set property to “IsCompliant”
– Set Operator to “equals”
– Set Value to “True”
– Then select Done
14. Select Client Apps :
– Select the “Client apps” menu
– Select yes on the “Configure” Menu on the right hand side.
– Select “Browser” and “Mobile Apps and Desktop Clients” on the right hand side menu.
– Then select Done
Gotchas
As with most Microsoft solutions, Conditional Access is not without its flaws.
Conditional Access will not work in the following situations:
- Client App – Not all client apps support Conditional Access – the Client App needs to support Modern Authentication. e.g. Outlook 2016 or Outlook 2013 (with a reg key change).
- Outlook 2010 will not work with Conditional Access and the user will be allowed to connect in; to lock down Outlook 2010 based on IP Ranges requires ADFS claims rules.
- Upgrade to Outlook 2016 if your business is still using this; it is 2018! Any 3rd party apps (e.g. Outlook Plugins) that don’t support above Outlook 2010, put pressure on the vendor to fix this. Don’t let your Office 365 migration be hindered by a non-future-proof app.
If your organisation is thinking about your IT security, and how it can be improved, why not book a Security Workshop from TSIT? Our experts will assess and review your current security landscape, helping you to address and solve challenges, optimising the security of your IT and helping you comply with industry standards and regulations.
Our comprehensive overview will give you the knowledge and insight you need to create an IT security strategy that fits your business needs and helps you to be completely secure using tools like Microsoft Security and Microsoft 365 to stay agile.
Conditional Access
How to setup
Setting up conditional access in Microsoft 365 helps you control access to your organization’s resources based on certain conditions. It’s a crucial part of enhancing security. Here’s a general outline of the steps to set up conditional access:
Note: Microsoft’s interface and options may evolve over time, so the exact steps could vary slightly. Always refer to the official Microsoft documentation for the most up-to-date instructions.
1. Sign In to Azure Portal:
– Go to the Azure portal: https://portal.azure.com/
– Sign in with an account that has administrative privileges.
2.Navigate to Azure Active Directory:
– In the left-hand menu, click on “Azure Active Directory”.
3. Conditional Access:
– In the Azure Active Directory menu, select “Security” and then “Conditional Access”.
4. Create a New Policy:
– Click on “+ New policy” to start creating a new conditional access policy.
5. Assignments:
– In the “Assignments” section, define the users or groups the policy applies to. You can select specific users, groups, or all users.
6. Cloud apps or actions:
– Specify the target apps or actions you want to apply the policy to. For instance, you might choose “Office 365 SharePoint Online” or “Exchange Online”.
7. Conditions:
– Here, you set up the conditions that must be met for the policy to take effect. Conditions might include:
– Device platforms: For example, allow access only from compliant devices.
– Locations: Restrict access based on IP ranges or countries.
– Device state: Allow access only from devices with specific security configurations.
– Sign-in risk: Allow or block based on the calculated risk level of a sign-in attempt.
– Device platforms: Control access based on whether the device is managed or compliant.
8. Access controls:
– Define what should happen if the conditions are met. For example, you might require multi-factor authentication (MFA) or block access entirely.
9. Session:
– Choose the session control options, like allowing limited access or requiring users to sign in again if the risk level is high.
10. Notifications:
– Configure notifications for users and admins, informing them about the policy.
11. Enable Policy:
– Once you’ve configured the policy settings, turn the policy on by clicking “On” or “Enabled”.
12. Review and Create:
– Review your settings and click “Create” or “Save” to apply the policy.
Remember, conditional access can significantly impact user access, so be cautious when implementing policies. Always test policies in a controlled environment before rolling them out to your entire organization.
Also, note that the steps provided here are a general guideline. Depending on your organization’s specific needs and the updates to Microsoft’s services, the interface and options might differ. Always refer to the official Microsoft documentation or seek assistance from Microsoft support for accurate and up-to-date guidance.
