Conditional access and legacy authentication

This week is still all about conditional access. More specifically, the recently introduced feature to create conditions based on the use of legacy authentication (including older Office versions), which is currently still in preview. By now, I’ve done my fair share of posts regarding blocking legacy authentication (see for example here and here), but now it’s literally getting super easy. And no need for AD FS anymore. This helps with easily closing another backdoor, as previously legacy authentication simply bypassed any conditional access policy. In this post I’ll walk through the required configurations followed by the end-user experience.

Configuration

Before going through the configuration let’s start with a quick reminder about legacy authentication. Very simplistically said, legacy authentication is basic authentication that uses a single authentication factor in the form of a username and password and cannot force a second authentication factor (think about protocols like, POP3, IMAP, SMTP, MAPI and EWS and apps like, Office 2010). As I have no need for legacy authentication in my environment, I will block all legacy authentication to my apps. The following seven steps walk through the simple configuration to create a conditional access policy that blocks the access to all cloud apps for all users when using legacy clients.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups02On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5 AAD_CA_ClientApps02On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Mobile apps and desktop clients > Other clients and click Done and Done;
6

AAD_CA_Grant02On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: Make sure that there are no apps within the environment that still need basic authentication, as this configuration will block all of it.

7 Open the New blade, select On with Enable policy and click Create;

Note: It can take up to 24 hours for the policy to take effect.

End-user experience

One of the best use cases is an old Office version. Office 2010 and the default configuration of Office 2013, both use basic authentication. Office 2016 and later use modern authentication by default. Due to the way basic authentication works the end-user experience is not pretty and will not be pretty. Below is an example of the end-user experience when using Outlook 2010 for connection to Exchange Online. As mentioned, it’s effective and not pretty.

BlockOutlook

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Client apps.

Conditional access and device state

This week back in conditional access again. More specifically, the recently introduced feature to exclude devices based on the device state, which is currently still in preview. This enables organizations to exclude managed devices (Hybrid Azure AD joined and/ or compliant) from a conditional access policy. That means that the conditional access policy will only be applicable to unmanaged devices. This enables new scenarios and makes existing scenarios easier. Think about using session controls to enable a limited experience within cloud apps, for unmanaged devices only. In this post I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

The configurations that make the most sense for using the device state are related to the access controls. At least, in my opinion. All other scenario’s can also be created by using the already available options. It just makes it a bit easier. By looking at the access controls, the session related controls are the most obvious configuration to start with. The Use app enforced restrictions session control enables organizations to enable a limited experience within a cloud app, for, in this case, unmanaged devices and the Use proxy enforced restrictions session control enables organizations to sent the user sign-in information to Microsoft Cloud App Security, also for, in this case, unmanaged devices. That enables additional actions based on the users sign-in activity. The following seven steps walk through the simple configuration to create a conditional access policy that uses the proxy enforced restriction session control.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 AAD_CA_CloudApps01On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5

AAD_CA_DeviceState01On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, click Exclude, select Device Hybrid Azure AD joined and Device marked as compliant and click Done and Done;

Note: Think about the easier scenarios that can be created by using the option to exclude domain joined devices from the conditional access policy.

6

AAD_CA_Session01On the New blade, select the Session access control to open the Session blade. On the Session blade, select Use proxy enforced restrictions (preview) and click Select.

Note: Optionally configure additional a Cloud App Security Access policy or Cloud App Security Session policy to enable additional behavior based on the sign-in information of the user. For example, block the sign-in for a specific cloud app.

7 Open the New blade, select On with Enable policy and click Create;

Note: Basically the Azure AD conditional access policy and the Conditional Access App Control access or session policy will work together to perform real-time monitoring and control.

End-user experience

Let’s end this post with the end-user experience, followed with the administrator experience. As I only have connectors for Office 365 and Microsoft Azure in my Cloud App Security, I can only create access policies for the connected apps. These access policies can be used to simply monitor the activity or to actually block the session and display a custom block message. Besides that, the policy can also create alerts. In the dashboard, via email and via text message.

I created a policy that would block the session of the end-user with a custom message as shown below. Yes, I could have blocked the session already with conditional access itself, but this provides me with some more information about the sign-in.

CloudAppSecurity_Blocked01

When I’m now looking in the Cloud App Security dashboard, I can already see the alerts. When I navigate to either Investigate > Activity log or Alerts, I can look at the information as shown below. That provides me with the source, which, in this case. is Azure AD conditional access, the matched policy and information about the user and the device (as shown below). Pretty nice.

AppDashboard01

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Device state.

Conditional access and guest users

This week back in conditional access. More specifically, the recently introduced feature to assign a conditional access policy to All guest users, which is currently still in preview. At the same time also the ability to assign to Directory roles was introduced. The idea for both is the same. The first is to specifically assign to guest users and the second is to assign to specific roles in the directory. This post will focus on the first scenario. I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

Microsoft Teams is getting really hot for collaboration. This also creates a very low bar for inviting external parties (B2B) to collaborate with. Working together. Of course this should be facilitated to enable the productivity of the end-user. However, that doesn’t mean that there shouldn’t be additional security in-place. Even if it’s just to ensure the identity of the guest user. For example, enable multi-factor authentication for guest users. The following steps walk through the simple configuration to enable multi-factor authentication for guest users on Microsoft Teams.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroupOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select Select users and groups > All guest users (preview) and click Done;
4 AAD_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps > Microsoft Teams and click Done;
5

AAD_CA_GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access > Require multi-factor authentication and click Select.

6 Open the New blade, select On with Enable policy and click Create;

Note: Guest user matches any user account with the userType attribute set to guest.

End-user experience

Now let’s end this post by looking at the end-user experience. Once the (external) user is invited for using Microsoft Teams, it will first have to configure MFA (see screenshot on the left). After that the user will be able to access Microsoft Teams by using its favorite MFA option. In my example I picked the Microsoft Authenticator app, as it will clearly show that an external account was used (see screenshot on the right). It clearly shows #EXT and onmicrosoft.com.

Screenshot_MFA Screenshot_Authenticator

More information

For more information about conditional access and assignments, please refer to this article about Conditions in Azure Active Directory conditional access | Users and groups.

Join me at the Tech Summit in Amsterdam

Next week, March 28-29, the Microsoft Tech Summit will be in Amsterdam and I will be there. On Wednesday (March 28) I will be available at the Ask the Experts Reception and on Thursday (March 29) I will be speaking about Manage Windows AutoPilot via Microsoft Intune. I hope I will see you there!

pvanderwoude

About my session

In this session, I will pull you into the world of Windows AutoPilot. Learn what Windows AutoPilot is and also, learn what Windows AutoPilot is not. In this demo-rich session I will show you how to use Windows AutoPilot, together with Microsoft Intune, to simplify device provisioning.

Super easy Office 365 ProPlus deployment via Windows 10 MDM

This week a blog post about a very nice new app type in Microsoft Intune standalone. The Office 365 Pro Plus Suite (Windows 10) app type. This app type makes it very easy to assign Office 365 ProPlus apps to managed Windows 10 by utilizing the Office CSP. Additionally, it also allows the installation of the Microsoft Project Online desktop client, and Microsoft Visio Pro for Office 365. I know, I’m not the first to write about this app type, nor will I be the last, but this app type needs all the attention it can get. It’s that nice. I’ll start this post with some prerequisites and important information, followed by the configuration. I’ll end this post with the administrator experience.

Good to know

Before starting with the configuration of the new app type, it’s good to know the following current limitations and requirements.

  • Devices must be running Windows 10, version 1703 or later. That version introduced the Office CSP;
  • Microsoft Intune only supports adding Office apps from the Office 365 ProPlus 2016 suite;
  • If any Office apps are open when Microsoft Intune installs the app suite, end-users might lose data from unsaved files. At this moment the end-user experience is not that pretty;
  • When the Office apps are installed on a device that already has Office installed, make sure to be aware of the following:
    • It’s not possible to install the 32-bit and the 64-bit Office apps on the same device;
    • It’s not possible to install the same version of the Click-to-run, and MSI versions of Office on the same device;
    • When an earlier version of Office is installed, using Click-to-Run, remove any apps that must be replaced with the newer version;
    • When a device already has Office 365 installed, assigning the Office 365 ProPlus 2016 suite to the device might mean that the Office subscription level must be changed.

Configuration

After being familiar with the current limitations and requirements, let’s continue with the configuration. The 10 steps below walk through the configuration of the Office 365 Pro Plus Suite (Windows 10) app type. After creating the app type, assign the app like any other app. Keep in mind that at this moment the app can only be assigned as Required, Not applicable or Uninstall. Available is currently not an option.

1 Open the Azure portal and navigate to Intune > Mobile apps > Apps;
2 Select Add to open the Add app blade;
3 AA_AppTypeOn the Add app blade, select Office 365 Pro Plus Suite (Windows 10) as App type to add the Configure App Suite, the App Suite Information and the App Suite Settings sections;
4 On the Add app blade, select Configure App Suite to open the Configure App Suite blade;
5 AA_ConfigureAppSuiteOn the Configure App Suite blade, select the Office 365 apps that must be installed and click OK to return to the Add app blade;
6 Back on the Add app blade, select App Suite Information to open the App Suite Information blade;
7

AA_AppSuiteInformationOn the App Suite Information blade, provide the following information and click OK to return to the Add app blade;

  • Suite Name: Provide a unique name for the app suite;
  • Suite Description: Provide a description for the app suite;
  • Publisher: Provide the publisher of the app;
  • Category: (Optional) Select a category for the app suite;
  • Display this as a featured app in the Company Portal: Select Yes or No. At this moment the app suite can only be deployed as  required, which means that there are not many reasons to select yes;
  • Information URL: (Optional) Provide the URL that contains more information about the app;
  • Privacy URL: (Optional) Provide the URL that contains privacy information about the app;
  • Developer: (Optional) Provide the developer of the app;
  • Owner: (Optional) Provide the owner of the app;
  • Notes: (Optional) Provide additional notes about this app;
  • Logo: (Optional) Select an image.
8 Back on the Add app blade, select App Suite Settings to open the App Suite Settings blade;
9

AA_AppSuiteSettingsOn the Add Suite Settings blade, provide the following information and click OK to return to the Add app blade;

  • Office version: Select the version of Office that should be installed, 32-bit or 64-bit;
  • Update channel: Select how Office is updated on the devices, current, deferred, first release current or first release deferred;
  • Automatically accept the app end user license agreement: Select Yes or No;
  • Use shared computer activation: Select Yes or No;
  • Languages: Select additional languages that should be install with the app suite. By default Office automatically installs any supported languages that are installed with Windows on the end-user device.
10 Back on the Add app blade, click Add;

Note: After adding the app suite it cannot be edited anymore. To make adjustments, delete the app suite and create a new. That makes it important to think about the configuration before creating one.

Administrator experience

Usually I’ll end this type of posts with the end-user experience, but in this scenario there is not much to see. I can show something like the running installation process or the installed products, but that’s not that exciting as it’s simply there. Having said that, from an administrator perspective there are some interesting things to look at. Let’s start with the most interesting one, which is actually available on the end-user device, the Office CSP key in the registry. This key can be found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeCSP and is shown below.

Reg_OfficeCSP

Within this registry entry, it actually shows the content of the configuration XML in the default of the key. This enables me to have a look at the default values used during the installation of the Office apps. Besides the values configured in the app type. Below is the configuration XML that belongs to my installation. It basically shows 3 options that are not configurable, ForceUpgrade, Product ID and Display Level. Knowing these values should help with explaining the installation behavior.

<Configuration>
     <Add Channel=”FirstReleaseCurrent” ForceUpgrade=”TRUE” OfficeClientEdition=”32″>
         <Product ID=”O365ProPlusRetail”>
             <ExcludeApp ID=”Access” />
             <ExcludeApp ID=”Groove” />
             <ExcludeApp ID=”InfoPath” />
             <ExcludeApp ID=”Publisher” />
             <ExcludeApp ID=”SharePointDesigner” />
             <Language ID=”nl-nl” />
             <Language ID=”en-us” />
         </Product>
     </Add>
     <Display Level=”None” AcceptEULA=”TRUE” />
     <Property Name=”SharedComputerLicensing” Value=”0″ />
</Configuration>

Also interesting to look at, from an administrator perspective, is the installation status in the Azure portal. Simply navigating to Intune > Mobile apps > Apps install status and selecting the assigned app, will provide an overview as shown below.

InstallStatus

More information

For more information about the Office CSP and using Microsoft Intune to deploy Office 365 ProPlus, please refer to the following articles: