We’re back and it’s been a W H I L E…. let’s jump right back in with some Single Sign-On (SSO) passwordless fun with Windows 10, Azure AD Join, Microsoft Intune and Windows Hello for Business. This article is also uploaded to the Route443 blog here.

In this post we describe one route to incorporating passwordless technology that leverages customer investment in the Microsoft cloud, specifically Enterprise Mobility + Security.  We assume the customer is in possession of a hybrid infrastructure, with on-premise pieces (Active Directory Domain Services, Certificate Services etc.). Most customer configurations we come across are those where a Hybrid Azure AD-join configuration has been opted for, with the on-premise identity being the dominant one.

We’ll use Windows Autopilot to kick start a hypothetical migration from hybrid to cloud-only, in doing so using Microsoft Intune as an alternate for SCCM and on-premise GPO, rolling out Windows Hello for Business as part of the process, together with Wireless 802.1X and AlwaysOn VPN profiles. Finally, a single sign-on (SSO) path back to on-premise resources is a must.

Here we take a Windows 10 version 1803 client  and join it to the tenant Azure Active Directory. As way of demonstrating the platform capability, we:

• Provision the machine using Windows Autopilot and onboard the user using multi-factor authentication (sans password)
• Use Windows Hello for Business for Multi-Factor Authentication (MFA) via biometric gestures and PIN for fallback
• Use TPM-backed certificate authentication to provide secure access to the end-user both in deployment and access to:
  • VPN using Win10 AlwaysOn VPN
  • Secure wireless using 802.1X
• Use Credential Guard to isolate and protect secrets (e.g., NTLM hashes / Kerberos ticket-granting tickets)
• Leverage Single Sign-On (SSO) access to on-premise resources:
  • File servers
  • Print servers
  • Application servers

Machines are built using Windows Autopilot and joined to the Azure Active Directory (AADJ).  Since these are AADJ devices, they will not be part of the on-premise Active Directory. User accounts exist in both the cloud and on-premise AD.

Moving on, let’s peek at the configuration

In this use case, we’re going to deploy a Windows 10 machine using Windows Autopilot. In a conventional Windows deployment, Out of the Box exprience (OoBE) requires the user to identify whether the device is personally or organizationally owned, the selected option then triggering a different set of configuration workflow. For an organizational join, the client needs to have visibility to the Internet to process the registration of the device and the user.

Windows AutoPilot simplifies this decision-making process by directly tying the procured hardware to the organization tenant, importing the hardware ID of the device into the Microsoft Store for Business. The Out of Box Experience (OoBE) lands the user on the tenant branded logon screen.

When prompted for credentials, we enter our tenant details (in this example Route443). In a standard Windows configuration, we’d be required to enter a password after entering the username. Since our goal is passwordless, we look to stronger mechanisms for authentication. During OoBE deployment Windows Hello for Business is not available, so an alternative credential is required. FIDO 2.0 would be ideal but is not yet General Availability (GA) in a Windows 10 release.  Vendors such as Yubikey have incorporated FIDO 2.0 into their product range and are ready to support the up-coming release  of Windows 10 that includes support for FIDO 2.0.

With Multi-Factor Authentication (MFA) enabled in the tenant and phone sign-in configured for the user, the Microsoft Authenticator app can be used to do passwordless sign-in.  Like Windows Hello for Business, it uses key-based authentication for the user credential bound to a device (Biometric or PIN). With phone sign-in enabled for the AAD account, the enrolling user will see a number onscreen.

Within the mobile authenticator app, the user must match the number that appears on-screen with that surfaced via the mobile app.

Note that the App itself can be protected either by Touch ID or PIN. Once successfully authenticated, the machine will continue with configuration. Consistent with the organizational Intune policies in this example, the user will be prompted to register a PIN for Windows Hello for Business. This is also used for fallback in case biometric options (facial recognition/fingerprint) are not available.

Click on PIN requirements to see what your organizational policy has decreed.

 

Once the PIN is set, the user is able to login with their Hello PIN.  Should the device have other Hello capabilities, such as facial recognition or fingerprint reader, then these can also be engaged.

In the above example, the device is configured for facial recognition.  Changing biometric settings can also be modified under Windows Settings|Accounts|Sign-In Options.

Devices are enrolled for Intune MDM and Azure AD joined. This can be checked via Windows Settings|Accounts|Access Work or School.

With device configuration profiles defined in Microsoft Intune and assigned to devices, the AADJ client will receive the appropriate configuration.

Specific to this configuration, the following profiles are relevant:

• Certificate configuration profiles
  • Root CA
  • Issuing CA
• SCEP profile for Windows Hello
• SCEP profile for WLAN/VPN
• 1X WLAN profile
• AlwaysOn VPN profile

Certificate Authority Configuration Profiles

If certificates are pushed out via SCEP, then an Enterprise PKI and NDES server, acting as a Registration Authority, is required, together with an Intune connector installed on the server. As announced at Ignite, Intune will support 3rd party CAs in the near future.

A configuration profile is required for each tier of the PKI. In this example, a two-tier PKI exists, with a profile for each CA pushed to the client.

SCEP profile for Secure Wireless / VPN

A SCEP profile is rolled out with a Client Authentication EKU to satisfy the 802.1X and AlwaysOn certificate requirements.  This certificate is then used by these services to authenticate the client to the back-end Network Policy Server (NPS) running behind the respective wireless and VPN services.

SCEP Profile for Windows Hello

While Windows Hello for Business prefers hardware-backed credentials, not all computers are in possession of a Trusted Platform Module (TPM). Intune provides options for falling back to a software-based credential, should the need arise.

In Certificate Trust scenarios using Windows Hello for Business, a SCEP profile is required with a Smart Card EKU. This is to satisfy access conditions for Single Sign-On (SSO) for Windows Hello for Business against the on-premise domain.

Secure Wireless LAN profile

The Secure Wireless LAN profile contains the configuration for the on-premise wireless network, EAP type settings, authentication methods etc. Use of certificates ensures that access to the on-premise wireless is seamless when in-range. For a more immersive experience, machine certificates are preferred for use, subject to their availability in Intune.

AlwaysOn VPN profile

The AlwaysOn VPN profile contains the configuration for the on-premise AlwaysOn VPN server (Microsoft replacement for DirectAccess). The more detailed settings are minted from a EAP.XML file generated on a test machine manually and then imported into the Intune blade in Azure Resource Manager (ARM) console.

Dependent on whether the user is on-site at the business location or working from home, connectivity to the network, either via secure wireless (802.1X) or IPsec VPN (IKEv2) gives access to the corporate resources, courtesy of the provisioned certificates. This is carried out transparently. Since these are user certificates, connectivity is established after interactive logon.

This is down to  a limitation in the Microsoft Intune SCEP configuration profile that assumes all assigned certificates are to be user-oriented, rather than machine. Thankfully, based on details from Microsoft at Ignite, an upcoming Microsoft Intune release will provide additional support for machine certificates. Once these are available, we’ll follow up with an additional post.

On-Premise Access and Single Sign-On (SSO)

So how are on-premise Active Directory resources accessed in a native Azure AD Join (AADJ) scenario? It may come as a surprise, but AADJ clients can also communicate with on-premise Active Directory resources. This is down to functionality built into recent versions of the Windows 10 client and Azure AD Connect, providing additional details during AAD Sync that can be subsequently used by the Windows client.  It’s worth pointing out that this functionality is not specific Windows Hello for Business, but for AADJ clients as a whole that wish to communicate with on-premise resources.

It is assumed there is line-of-sight to a on-premise domain controller from the Windows 10 client. Line-of-sight can mean on-premise wired, wireless (802.1X) or Always On VPN.. For our passwordless scenario, the authenticated user has the aforementioned “Hello” certificate deployed via SCEP.

If on-premise domain controllers are Windows Server 2016 or above, then the certificate trust model for Windows Hello for Business, described here, can be dropped in favour of the key trust model. This simplifies deployment by not requiring SCEP/NDES for the Smart Card.

Using DSREGCMD from the command-line we can derive some useful information concerning the client.

This is an Azure AD joined device, with TPM-backed private keys for certificates created during the enrollment being stored in TPM. The user also has been enrolled for Windows Hello for Business (NgcSet: YES).

In this article, we illustrated how it is possible to optimise investment in Microsoft cloud services for deploying workspaces across any network, using modern secure authentication, whilst maintaing the ability to seamlessly access on-premise applications. This managed workspace achieves feature parity comparable to that of a classically deployed workspace. By utilising modern secure authentication, together with Azure AD Domain Join, this provides opportunities for customers to take advantage of other identity-as-a-service pieces already available in the Microsoft cloud.

For more information on these interesting topics, please contact us at Route443.