Windows 10 Passwordless – Azure AD Join, Microsoft Intune and Windows Hello for Business

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 Access Onion 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.

Hello

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 (passwordless) 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.

Transformation of the Desktop

For more than twenty years the Desktop PC has been the staple of enterprise computing, as the main productivity tool for knowledge workers. This dominance is being increasingly challenged as the modern workforce shifts to a more mobile experience, with modern operating systems reflecting this commoditized (read: BYOD) trend. Within this new generation of computing the traditional way of managing (thereby controlling) those devices will no longer apply or suffice. The reality is that as we see the desktop shifting toward a more mobile form, our traditional view of how we perceive infrastructure and security is fundamentally challenged. Not convinced? Stay tuned and we’ll delve into how we see this next generation computing mapping out.

Within the mobile world there’s a powerful and agile model of security and management called Enterprise Mobility Management (EMM). It contains three major management components Mobile Device Management (MDM), Mobile Application Management (MAM) and Mobile Content Management (MCM).

…With Windows 10, Microsoft has re-architected the Windows operating system to adopt EMM…

Here’s why: With the rise of mobile computing, employees don’t use (or not only) a locked-down PC on the corporate network to do their jobs. Instead they use many different devices, some company-owned and some personally owned. These devices run a vast array of (mobile) apps and connect across networks that are outside of IT’s control. Legacy Windows client management tools (like Microsoft’s System Center Configuration Manager (SCCM) are too inflexible for modern computing environments. They imply management of a client through installation of a complex system image on the PC, constrained by the boundaries of the organization. Solutions such as DirectAccess are last gasp entreaties to modernize the managed client in the conventional sense.

…The era of the domain-joined PC is coming to a close…

EMM moves the legacy PC paradigm from complex and hard-coded system image to context-based policy. With Windows 10, Microsoft is addressing the need for greater security and management flexibility in the enterprise. Yet, the Apple MacOS platform has been in this position for many years. From the start of the “mobile century”, the MacOS platform has been considered a mobile device next to the smartphones and tablets using the Android and iOS platform. So why is this development now taking momentum ? Could it have something to do with the impressive number of 400 million Windows 10 devices already in the field ? Clearly an operating system that is imposing itself on the market in such volume, while supporting much of the desired functionality organizations and their users are looking for,  is going to have impact on the conversation.

Gartner retired the Magic Quadrant for Client Management Tools in March 2016…

The traditional Windows architecture offered a broad attack surface because both the file system and the operating system itself presented vectors. To counter the risk, IT had to install, as part of the image, additional security agents to monitor threats and remediate accordingly.  Maintaining the integrity and security of data on the PC was a constant struggle. Likewise, this model required devices to join a Windows domain governed by policy (GPOs) , or third-party management software, controlling what employees could or could not do on this PC. It assumed devices were corporate-owned, Windows-based, and connected to a persistent local area network (LAN).

For the most part, the modern enterprise, moreover the IT department, no longer has the latitude to work this way. The demands of today’s employees; working on any device, in a variety of environments — home, airports, coffee shops, hotels, etc., means the traditional approach can no longer support this work style. Mobile devices are not LAN-bound and are frequently owned by the employee, rather than the company. The clouding of business v personal and the way in which the focus shifts freely from device to application to data, means overlapping is inevitable. Flexible use of devices becomes deeply embedded in many aspects of an employee’s personal and work life.

To address this new vista (no pun intended), Microsoft has re-architected Windows 10 to move beyond the legacy management systems and fully supporting EMM.

3
EMM solutions like Microsoft Intune are providing an efficient and flexible way to provision services to employees and secure business data on modern operating systems. The move to EMM represents a major change in how the desktop will be secured and managed moving forward.

…Our vision on this…

We believe that organizations need to start planning now for the moment where PCs are managed and secured like mobile devices, and desktop apps are developed and deployed like mobile apps. That’s a major upcoming shift within the technology landscape, enabling the transformation of the desktop.

In a upcoming blog post we’ll explain the technology behind EMM solutions, in specific the Microsoft Intune EMM solution and will also provide you a sneak preview in the near future to help you make the right decisions.

Please stay tuned, follow our website (www.route443.eu) our blog (blog.route443.eu) to receive the latest information from us.

 

 

The evolution of access control

Do you remember what it was like when everyone had desktop computers and data security focused on the best way to physically lock computers to heavy desks?

Many customers are asking us the question how they would be able to take control again of their “environment” where the environment now has become scattered amongst on-premise or outsourced resources, Cloud resources and Mobile devices.

In this blog post, we’ll review the ways security and access control have changed over the years, highlighting how Enterprise Mobility Management solutions (we’ll be showing you the  Microsoft Enterprise Mobility suite here) are poised to provide integrated solutions for the current world with mobile devices and online (Cloud) services.

We’re using the Microsoft Enterprise Mobility (EMS) solution as the explicit example here, because Microsoft has a different vision on how to solve these issues compared to other solution providers like MobileIron or Airwatch. The main and most important difference in vision between those providers, is the way they are handling the delivery of (mobile) applications and data. Where MobileIron and Airwatch (as an example, there are many other providers out there) are desperately trying to create “controlled bubbles”, the Microsoft vision is to use the native device and application experience, while protecting the access towards the application and the data. That’s a fundamental other way of taking care of the challenge here. It’s not that the “bubble” approach is wrong to begin with (even more, there are specific use cases to use the approach) but the end-user will lose the “native device experience” but even more the end-user will end up using the EMM solution provided mobile apps to replace the native apps…

bubble approach

Picture: showing the MobileIron “apps” with the “bubble” approach 

We’ve seen cases at customers where the “bubble” approach failed or at least was not that successful as end-users did not fully accepted the fact that they where losing the native device apps like Outlook mail of ActiveSync. Let’s not get going about the quality of those non-native EMM apps here but you’re able to imagine the challenges there for the EMM providers 😉

So what’s the vision of Microsoft here ? Well, Microsoft has of course the best interest in using their  applications but on the other hand they have a great bundle of solutions to their availability. But first, let us have a look in the way things have been changed the past years for now:

Mobile Access version 1: Mobile Laptops

In the past, corporate data was hosted on-premises. It was accessed by desktops that were physically connected to the corporate network. Then, laptops emerged as the dominant corporate device, and the Virtual Private Network (VPN) was born.
VPNs provided 3 primary functions:

1. They made it possible for laptops to reach corporate services on the Intranet
2. They restricted corporate access to Internet-connected laptops
3. They helped prevent data loss by encrypting communications and running agents on the laptops that helped contain data

Over time, VPN technology evolved. The criteria that could be used for access control (e.g. require the laptop to be domain-joined) expanded and the technology to prevent data loss matured.
Eventually, new types of VPNs such as SSL VPNs emerged. SSL VPNs enabled app-specific, as opposed to device-wide, access to corporate services from the Internet. This reduced the attack surface and also enabled new scenarios such as accessing corporate services from web browsers running on unmanaged devices.

Mobile Access version 2: Smart Mobile Devices

Later, when smart mobile devices arrived in the corporate computing landscape, they needed access to corporate resources, and VPN technology was the tool available to provide that. Mobile devices, primarily connected to the Internet, needed network reachability to corporate services. However, theses always-on devices brought many security concerns from their early general lack of IT controls. This drove demand for complementary technology to the VPNs which would help protect data.
All of this created an opportunity for integrated solutions based on Mobile VPN, Mobile Device Management (MDM), and Mobile Application Management (MAM). The management system would provision a VPN profile to a mobile device and thereby give it controlled access to corporate services on the Intranet. MDM and MAM features would help provide data protection on mobile devices analogously to the agents deployed by VPN clients on laptops.
Over time, Mobile VPNs emerged into per-app Mobile VPNs. The per-app variety provided similar benefits to mobile devices that SSL VPNs had provided to mobile laptops in the past. They reduced the attack surface and enabled new scenarios.

Mobile Access version 3: Identity-based Access Control and Data Protection

Now, we are in an era of mobile access where increasing amounts of corporate data lives outside of the network perimeter. Data still lives on corporate networks, but it’s also in cloud services, on mobile devices, and in mobile apps. Perhaps one day you won’t have any corporate data left on-premises, but the moment you start adopting cloud services you need to rethink the way access is controlled and data is protected.

ConditionalAccess1

Picture: showing that within the current world the apps, devices and resources are scattered

In the mobile-first, cloud-first world, a fundamentally different approach was needed, so we built access control and data protection directly into mobile devices, mobile apps, and the cloud infrastructure itself.  In this world your network perimeter is replaced by an “identity perimeter.”

ConditionalAccess2

Picture: showing that within the perimeter protection layers do not apply anymore

That’s what Microsoft has built with Office 365 and the Enterprise Mobility Suite, as a supplement to the classic VPN provisioning mechanisms that other  EMM providers like MobileIron or Airwatch have for on-premises apps. Microsoft EMS delivers integrated identity, access control, management, and data protection – built to protect your corporate data wherever it lives, using technologies like Device and Application Management, Information Right Management, Risk based contextual based authentication, Analytic Security Services and more.

With Microsoft EMS, whenever a mobile device or app attempts to authenticate to an online service (Microsoft or 3rd party) or on-premises web app, subjects the request to criteria you define, consulting with the management system as needed. Is the mobile device managed and compliant with your IT policies? Is the mobile app managed? Has the user presented multiple forms of authentication? Is the PC domain-joined and managed or controlled ? Is the request coming from the corporate network or the internet? All of these criteria and more are provided without the need for VPN. It’s just built-in the solution.
The diagram below shows how Microsoft EMS ensures that you have the access controls in the cloud needed to replace the access controls in your VPNs.

ConditionalAccess3

Picture: illustration of conditional access using Microsoft EMS

In addition to providing cloud access control, Microsoft EMS also provides native data protection. Again, this is based on identity and integrated with management.
Was a corporate identity used to access the data? If yes, then the mobile apps will prevent the data from being shared with consumer apps or services via Save-As, Open-In, clipboard, etc (Intune MAM with or without device enrollment into MDM). Is the document itself explicitly protected by an access policy (using IRM like Azure RMS)? If so, enforce access control on that file, even when it roams outside of apps and devices under management.

This integrated approach to data loss prevention enables the same application to isolate the corporate and personal data that it handles. This means your employees will not have to use separate apps for work. They can just use native or Office mobile apps for work and personal use and the right protections will apply at the right times. The diagram below shows this concept.

ConditionalAccess4

Picture: showing the Microsoft EMS approach to handle Data Loss Prevention

As mobile access evolves from VPN-based to identity-based, we foresee several benefits:

  • Cost savings compared to VPNs. VPN technology is typically expensive and complex. Deploying VPN agents, profiles, and certificates is also complex and expensive. As more and more of your data moves to the cloud, you’ll enable larger and larger populations of cloud-only users that don’t require a VPN and everything it carries.
  • Simpler access infrastructure to operate. Instead of operating a global scale network perimeter with various proxies, gateways, and VPNs, you just need to connect your existing on premise AD with the Azure Active Directory. From there, Office 365 and other SaaS apps will route their authentication through Azure AD and your modern access controls will be enforced.
  • Better end-user experiences. With EMS’s identity-based access control, your end users will not have to install and launch separate VPN apps. The access control experience is natively a part of the sign-in experience in the mobile apps. Since your traffic isn’t bounced from the Internet to the Intranet and back, your employees get better latency and performance in their mobile apps.
  • Positioned for the future. Once your basic cloud access infrastructure is in place, you have a solid foundation for future innovation. Because the capabilities are provided from the cloud, improvements come often and automatically. You don’t need to plan upgrades or migrations to start to take advantage of the latest and greatest. Compare this to your VPN infrastructure today and the tremendous amount of effort it takes to upgrade to the latest and greatest.

As Route443, we’re often working by the identity-based model for mobile access control and data protection, as it has our special interest we’re following any developments very closely. We see this development as one of the best things offered in the industry to help you provide great mobile experiences to your employees and in the most future-proofed way.

In the meantime, if you’d like to know more on how you are able to use this functionality within your corporate environment, please contact us and let us know how we can assist you.