Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Frequent questions about using Conditional Access to secure remote access
Published Apr 03 2020 02:00 PM 62.5K Views
Microsoft

Industry trends and changes in the way we work usually span years, with organizations evolving at their own pace. But we're living in unusual times. 

 

Organizations asking employees to work from home to slow the spread of COVID-19 are making huge organizational and process changes in a matter of weeks, not years. For them, quickly enabling remote work while keeping company data safe presents new challenges and amplifies old ones.

 

To help, we’d like to share best practices and tips, aligned with the principles of Zero Trust, that we’ve assembled from working closely with customers in these trying times.

 

Question: What’s the best way for users working from home to set up MFA?

We recommend using a Conditional Access policy to enable MFA for all users.

  1. If you haven’t already done so, enable combined security information registration, which will give your end users the best experience and register them for Self Service Password Reset (SSPR).
  2. Place limits to help thwart attackers trying to register as users. For example, you can require registration from Microsoft Intune compliant or hybrid Azure AD joined devices.
  3. If you can’t require a corporate device, block MFA registration outside a certain time window so that users who miss the deadline have to contact the helpdesk.
  4. Defaulting to the Microsoft Authenticator app as their primary MFA method will give users the best experience, especially if they’re based outside the US. For example, they’ll get fewer MFA prompts for applications on mobile devices.

    CA1Apr3.png
  5. You can ask users to register at https://aka.ms/mysecurityinfo. Otherwise they’ll be prompted when they first sign-into an application that requires MFA. Be sure to have them register a backup method, such as a phone number for SMS and voice call MFA, or a hardware token. This will help when someone gets a new phone with a new number.
  6. When you’re done making changes, run the new MFA Authentication method analyzer to make sure you didn’t miss any recommended steps.

Question: I’m seeing more devices connect from personal and work devices outside my trusted networks. What can I do to keep control of company data?

You have a couple of options for ensuring that users only keep files on devices you trust, depending on your endpoint management strategy and which features you’re already using. You can restrict file access to managed devices and applications, or you can limit file downloads and file access from unmanaged devices while still allowing app access.

  • For devices already managed by Microsoft Intune, now a part of Microsoft Endpoint Manager, you can limit access through Conditional Access policies. Requiring a compliant device gives you the most control over device management, minimizing risk.
  • Implementing Hybrid Azure AD join will join devices already joined to your on-premises Active Directory to Azure AD. You can then apply Conditional Access policies that only let users access your environment from these trusted devices.

Pro tip. If you use AD FS, be sure to expose your username mixed and certificate mixed endpoints (a frequently missed step), even if your environment already has Hybrid Azure AD devices. You may only experience issues when devices need to check in during their two-week sliding window.

 

Question: Given the current situation, we need to deploy Conditional Access policies quickly. What advice do you have?

To start, we recommend reviewing our best practices guidance. Here are some highlights:

  1. To avoid introducing service dependencies that you will need to resolve, apply each policy to all apps or explicit lists of apps instead of using app exclusions.
  2. Proceed with caution. A policy deployed too quickly may inadvertently block user access and delay your roll-out. We typically recommend running new policies in report-only mode for a couple of weeks, but if you can only do this for a few hours, you’ll still benefit.

    CA2Apr3.png

  3. Use Azure AD sign-in logs and the Conditional Access What If tool for troubleshooting.
  4. With new access policies in place, your users will likely see sign-in prompts for MFA or requests to enroll their device. To reduce prompts for reauthentication and MFA, we recommend the following:

    • Consider extending sign-in frequency periods and configuring persistence of browsing sessions.
    • If you’re not using Conditional Access, enable “Keep me signed-in” under your tenant branding.
    • On mobile devices, install the Microsoft Authenticator mobile application, which enables not just MFA, but also single sign-on across mobile apps.
    • To enable single sign-on when users sign into their device, enroll devices for hybrid domain join or Azure AD join or use Windows Hello for Business.
    • Exclude the MFA requirement for hybrid Azure AD domain joined devices and compliant devices.
    • Configure your user’s Windows 10 devices to use the Web Account Manager (WAM). We’ve seen organizations disable the WAM to work around an app issue and then forget to re-enable it later. Because the WAM helps enable single sign-on to Windows 10 desktop applications, it’s necessary for device-related Conditional Access policies. If a user can’t satisfy a device policy from an Office desktop app and their device is properly enrolled, verify that the following key has NOT been set:
      • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity|DisableADALatopWAMOverride value of 1

 

Question: How do I use Conditional Access to enable access to some apps, like Office 365, and block everything else?

Organizations that don’t have time for in-depth analysis of which resources they should or shouldn’t block can implement Conditional Access in an ‘allow-list’ configuration, which blocks access to any Azure AD applications and resources not on the list. Keep in mind, however, that your organization may have dependencies on hundreds of services and endpoints within Azure AD, and that apps calling blocked services may exhibit unexpected behavior. If you need to take a block-all approach to enable remote work quickly, we recommend following best practices guidance.

 

CA3Apr3.png

Targeting the Office 365 suite will ensure that most Office 365 applications run as expected under a block-all policy. The policies listed in the table below enable access to Office 365 services from outside your corporate network while blocking external access to all other Azure AD services.

Policy Name

Users and Groups

Cloud apps or actions

Conditions

Grant

Include

Exclude

Include

Exclude

Include

Exclude

Block all apps excluding O365

All users

Break glass accounts

All applications

Office 365 (preview)

Any location

All trusted locations

Block access

Access Office 365 externally from Hybrid joined or compliant device

All users

Break glass accounts

Office 365

n/a

(Select appropriate controls)

 

Allow access:

- Hybrid joined devices

- Compliant devices

- Require one of the selected controls

 

We don’t recommend targeting all users and applications in a single rule. Policies applied to ‘all users’ will apply to users local to your tenant as well as any guest users invited to your tenant. If you take this approach, be sure to include some break-glass accounts. But if your security requirements allow for it, target individual group(s) of users instead of using the ‘All users’ option when you roll-out policy.

To ensure that your policy doesn’t block traffic from inside your network, you can exclude trusted network locations, as the “block all apps excluding O365” rule above does. Actively managing network locations within Azure AD will help you cover all internal networks. If you want to make other apps available externally, you can add them to the exclusion list in the first policy, and then either add them to the second policy or create another policy to apply different conditions.

Question: What steps should I take for users connecting to my corporate network through a VPN?

It’s good practice to enforce MFA on VPNs in addition to all your apps. So that you can use Conditional Access, we recommend using a VPN that supports federated authentication to Azure AD with SAML or OpenID Connect. You can look for VPNs that support SAML authentication in the Enterprise Applications App Gallery, or you can add a custom SAML app in the Azure AD portal. As with any other Conditional Access policy, you can protect a VPN federated with Azure AD by requiring MFA or trusted devices. You can learn more about Azure AD hybrid access options here.

If your VPN doesn’t support federated authentication you can protect RADIUS authentication with Azure MFA using the Azure MFA NPS extension.

If you use location-based Conditional Access policies for users outside the corporate network, be sure to update your trusted name location IP ranges so that users quickly jumping between VPN and home IP addresses don’t trigger impossible travel or unfamiliar location events.

Pro tip. If you see an increase in VPN traffic and want to decrease the load, here’s how Microsoft IT has addressed this challenge.


To remove dependencies on on-premises infrastructure, such as federation servers, to access 3rd party SaaS applications, consider integrating them into Azure AD.

Question: How can I enable access to on-premises apps and resources without using a VPN?

Azure AD Application Proxy lets you publish an application or Remote Desktop, while integration with partners like Akamai, Citrix, F5 and ZScaler lets you leverage existing network and delivery controllers with Conditional Access.

  • Azure AD Application Proxy lets you provide secure remote access, without a VPN, to on-premises web applications like your internal-only SharePoint site or intranet site. The same Conditional Access policies you’ve designed for SaaS apps will work for your on-premises applications, while users get the same single sign-on experience, including required MFA challenges.

Pro tips.

·       Azure AD App Proxy only uses OUTBOUND connectivity on port 80 and 443.

·       You can provide single sign-on to Integrated Windows Authentication applications by configuring Kerberos Constrained Delegation (KCD).App Proxy can translate URLs in the header or body. URL translation also supports wildcard URLs.

·       Don’t forget to check the full detailed deployment plan for Azure AD App Proxy and other features.

 

  • You can publish Remote Desktop for admins through Azure AD App Proxy to access Remote Desktop Web Role and Remote Desktop Gateway Role.
  • You can also integrate existing networking and delivery controllers like Akamai Enterprise Application Access (EAA), Citrix Application Delivery Controller (ADC), F5 Big-IP APM or Zscaler Private Access (ZPA) into Azure AD to continue to leverage Conditional Access policies for these hybrid resources.

Summary

We hope you find these recommendations helpful as you enable secure remote work for your employees. Please let us know via Twitter (@AzureAD) if you have any other questions or ideas.

 

11 Comments
Brass Contributor
  1. @Alex Weinert If you can’t require a corporate device, block MFA registration outside a certain time window so that users who miss the deadline have to contact the helpdesk.

     

    how can this be done?

Microsoft

Good question. We've seen customers set up one policy to require MFA for all apps and a second to block access. User that are in the first policy and haven't registered will be prompted to register. After time X (usually 72 hrs) have passed, unregistered users are moved to the second policy. 

Deleted
Not applicable
Copper Contributor

Can we block file download from owa for personal devices and allowed only for corporate devices, can it is achievable with EMS

Copper Contributor

Hi, 

 

What will the limitations be for a customer that is using and 3rd party IdP that is integrated to AzureAD? I'm guessing they won't be able to determine device context and conditional access policies will limited and forced to use the the 3rd party IdP capabilities? 

Copper Contributor

They won't be aggre on third party Idp. i just wanted to know, how this limited acces work with Managed device, as we have to enable Conditonal acces switch with read only for OWA mailbox policy and apply to a user whom we want to restrcit then how it will apply on managed device bcz the user carrying the same owa policy which is not allowing downlaod.

@Deleted - Good question.  To me, the two docs are different discussions about the same thing - 'best practices for Conditional Access.'  The "best practices" doc has alot of background information about CA, what the different elements of a Policy are, how policies are processed, etc. - how to conceptualize Conditional Access.  However, in terms of enterprise guidance and real-world implementation details (i.e. what specifically should I click/choose in the UI to end up with a complete CA design), the "common policies" doc is where I go.  

 

@Sonam Singh Chouhan - this is another common ask these days and yes, you can control attachments.  Either limit - (open in browser/save to SharePoint Online or OneDrive for Business) - or block from OWA with interop between AAD Conditional Access and OWA mailbox policy.  There is a two-step here where AAD Conditional Access Policy and Exchange Online work together.  With the Conditional Access Policy, you can exclude Hybrid AAD Joined (i.e. Domain Joined devices represented in your AAD) and/or 'compliant' devices (i.e. devices marked as 'compliant' in AAD by Intune) from getting the limits so they work 'fully' but sessions from un-managed devices are limited  https://techcommunity.microsoft.com/t5/outlook-blog/conditional-access-in-outlook-on-the-web-for-exchange-online/ba-p/267069

Microsoft

@Alan Schmarr  - The limited access policies with EXO and SPO will still work even if a 3rd party IDP is being used, as long as the device identity is in AAD. After the user authenticated with the 3rd party IDP, Azure AD will run Conditional Access policy and authenticate the device. The device info will then be used in the policy decision. 

Brass Contributor

Regarding "Question: What steps should I take for users connecting to my corporate network through a VPN?":

We have VPN through RRAS. We've enabled Conditional Access in the VPN profile. Our devices are all Hybrid Azure AD Joined.

Can we enforce MFA (through Conditional Access) every time on our Hybrid joined devices when the user connects to the VPN? Even if the device is enrolled in Windows Hello for Business?

 

We tried last year and came up dry - with the answer that it's working as intended. The answer from support was that when we Hybrid join, the device gets an MFA token in the PRT.

Can you tell me if this is correct, or if the behavior has changed since then?

Copper Contributor

Hi, I'm trying to set up a CA policy that allows members of a group access to the Azure Portal but only if they have a VPN running, otherwise no access. The group access works as expected, but as soon as I add the VPN (as a Trusted Location, excluding everyone else) it allows users in my 'blocked' group through who have a VPN running and allows users in my 'allowed' group if they haven't. I can't seem to get it working, but is it actually possible? I'm pretty new to Intune so I'm stumbling around a bit, so any advice would be really appreciated.

Copper Contributor

I may as well post this as the response to my plea was overwhelming (Irony alert). I figured it out, by luck more than judgement I might add, but there we go. You need 3 policies. I used 2 groups to test. A test group containing my test user that I wanted to block, and a 'live' group containing me who I (naturally) wanted to allow. All the policies are 'Block' policies, so it feels a little counter intuitive to 'Include' who you want to block and 'Exclude' those you don't, but now I've written it, it seems quite clear. So to be clear, if it's 'Included' it's blocked, and 'Excluded' it isn't.

Policy 1 Groups Excl & Incl-No Location

Include who you want blocked, exclude who you don't. Select the App/s you want blocked. I configure the Device Platforms for Word and the Client Apps for everything, but haven't tested whether they are relevant. Nothing else changed.

Policy 2 All Groups Incl-Locations Excl & Incl

Include everyone. No exclusions unless you want a safety valve (just in case). Include the apps as above. Include 'Any Location' and Exclude any 'Trusted Locations'. Device Platforms and Client Apps as above.

Policy 3 Groups Incl & Excl-Locations Excl & Incl

Include who you want blocked, exclude who you don't. Include the apps as above. Include 'Any Location' and Exclude any 'Trusted Locations'. Device Platforms and Client Apps as above.

 

All I can say is with this set up, we can only get in with a VPN working. In the real world where you have to include 'All Users' you may need to put in an excluded (Admin) by name. We were managing the Azure Management Portal, which has implications if you botch it up, so fair play to MS if someone has programmed it to make sure you have to work hard to really screw it up. It doesn't work if that name is in a group, so it has to be explicit, and you can't remove it later! So well done to that nerd in the dark room who really thought about it, it is rare these days.


MS support couldn't do this in two weeks, and then they have the cheek to rate their support!!! 

Version history
Last update:
‎Jul 27 2020 07:09 PM
Updated by: