This week is all about conditional access in combination with Windows 7 domain joined devices. I know, simple solution, migrate as fast as possible to Windows 10. Having said that, it’s not always possible to simply migrate those devices to Windows 10 and in the mean time those devices do need access to Office 365. That’s why I thought it would be good to write something about those Windows 7 domain joined devices in combination with conditional access. As Windows 7 should not be a reason to not implement conditional access. In this post I’ll provide the details about the additional configurations that need to be in place, to allow Windows 7 domain joined devices access to Office 365. So, not directly about conditional access, but about the configurations that must be in place.
Before looking at the configuration, let’s start with a list of prerequisites that need to be in place. These are the general configurations that also need to be in place for Windows 10. Also, the configurations are nowadays triggered and/or mentioned during the installation of Azure AD Connect.
- Configure service connection point – The service connection point (SCP) object is used by devices, during the registration, to discover Azure AD tenant information;
- Setup issuance of claims – In a federated Azure AD configuration, devices rely on AD FS to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).
Now let’s continue with the configurations specific to Windows 7, and other down-level operating systems. Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2, are considered down-level operating systems. Down-level operating systems require the following additional configurations:
- Configure Azure AD to enable users to register devices;
- Configure on-premises AD FS to issue claims to support Integrated Windows Authentication;
- Add Azure AD device authentication end-point to the local Intranet zones;
- Install the Microsoft Workplace Join for non-Windows 10 computers package.
Configuration 1: Configure Azure AD
The first configuration, that must be in place, is that users must be enabled to register devices in Azure AD. The following 2 steps walk through that configuration. When using enrollment with Microsoft Intune, or MDM for Office 365, this configuration will be in place automatically.
|Open the Azure portal and navigate to Azure Active Directory > Devices > Device settings to open the Device Device settings blade;
|On the Device – Device settings blade, select All with Users may register their devices with Azure AD and click Save;
Configuration 2: Configure on-premises AD FS
Before starting with the second configuration, it’s good to mention that it’s no longer required to have an on-premises AD FS to register domain joined computers with Azure AD. Having mentioned that, the second configuration, that must be in place, when using AD FS, is that the on-premises AD FS must support issuing the authenticationmehod and wiaormultiauthn claims when receiving an authentication request to the Office 365 relying party trust. This can be achieved by adding an issuance transform rule that passes-through the authentication method. The following 5 steps walk through that configuration by using AD FS 4.0 (Windows Server 2016).
|Open the AD FS Management console and navigate to AD FS > Relying Party Trusts;
|Right-click the Microsoft Office 365 Identity Platform relying party trust and select Edit Claim Issuance Policy;
|On the Issuance Transform Rules tab, select Add Rule to open the Add Transform Claim Rule Wizard;
|On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next;
To finish the AD FS configuration, run the following PowerShell command to allow IWA, or MFA, for the Office 365 relying party trust.
Set-AdfsRelyingPartyTrust -TargetName “Microsoft Office 365 Identity Platform” -AllowedAuthenticationClassReferences wiaormultiauthn
Configuration 3: Add end-points to local intranet zones
The third configuration, that must be in place, is that the Azure AD device authentication end-point must be added to the local intranet zones. That should avoid certificate prompts. In my case the device registration would even fail, with a clear error in the Event Viewer (Event ID: 406). That event literally provides the solution of adding the URL to the local intranet zone. The following 6 steps walk through the configuration by assuming that an existing policy is available.
|Open the Group Policy Management console and navigate to Group Policy Management > Forest > Domains;
|Right-click an existing GPO and select Edit;
|In the Group Policy Management Editor, navigate to Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page;
|Right-click Site to Zone Assignment List and select Edit;
|In the Site to Zone Assignment List dialog box, select Enabled and click Show;
Note: In my case I also still had to add my identity provider to the local intranet zone (which is value 1).
Configuration 4: Install Microsoft Workplace Join for non-Windows 10 computers
The fourth configuration, that must be in place, is the installation of the Microsoft Workplace Join for non-Windows 10 computers package. The installation of that package creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows and silently registers the device with Azure AD.
The following 7 steps walk through the simple creation of an application, for the Microsoft Workplace Join for non-Windows 10 computers package, in Configuration Manager. That application can then be deployed to the required devices. Before starting with the steps below, make sure to download the Microsoft Workplace join for non-Windows 10 computers package.
|Open the Configuration Manager administration console and navigate to Software Library > Overview > Application Management > Applications;
|Click Create Application to open the Create Application Wizard;
|On the General page, provide the name and location of the MSI and click Next;
|On the Import Information page, click Next;
|On the Summary page, click Next;
|On the Completion page, click Close;
Let’s end this post by looking at the configuration results. The result should be that the Windows 7 domain joined devices are registered to Azure AD. The first place to look for a success is the Event Viewer. Open the Event Viewer and navigate to Applications and Services Logs > Microsoft-Workplace Join. As shown below, for a successful device registration this log should show Event ID 201 (Workplace join operation succeeded).
The second place to look for a success is PowerShell. Simply use the Get-MsolDevice cmdlet. Below is an example of 1 of my devices, which clearly shows the version of the operating system and Domain Joined trust type.
The third place to look for a success, and last place that I’ll show, is the Azure portal. Now simply navigate to Azure Active Directory > Devices > All devices. Below is and example, in which I selected 1 of my devices, which clearly shows the version of the operating system and the Hybrid Azure AD joined join type.
Once the Windows 7 domain joined device is successfully registered with Azure AD, the device can be granted access to Office 365 by using the access control of Require domain joined (Hybrid Azure AD) in conditional access.
For more information about Windows 7 and conditional access, refer to the following articles:
- How to configure hybrid Azure Active Directory joined devices: https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup
- Azure AD device-based conditional access and Windows 7/8.1: https://jairocadena.com/2017/10/04/azuread-device-based-conditional-access-and-windows-78-1/