How to SSO to domain resources without using hybrid join.

Welcome to this new blog series which will hopefully demystify SSO to domain resources from Azure AD Joined devices -- and get you up and working quickly with a comprehensive guide on AOVPN configuration.

Over the coming weeks, we will explore the concept of authenticating users to domain resources from an Azure AD Joined device. This first post in the series will give an overview of how SSO to domain resources works from an Azure AD Joined device.

Many organizations still question how best to achieve this and often try "Hybrid Azure AD Join" for their devices -- which is absolutely not a requirement. If you already have a VPN connection -- great, most of your work has been done. For those who are still considering how to make a VPN connection, we will walk through how to deploy a Microsoft Always On VPN (AOVPN) solution with the other necessary components and configuration including, Network Policy Server (NPS), Routing and Remote Accesses (RRAS), Extensible Authentication Protocol (EAP), Network Device Enrollment Service (NDES), Simple Certificate Enrollment Protocol (SCEP) and Microsoft Endpoint Manager Intune.

There will be an assumption that you already have a Certificate Authority present in your domain and are running Azure AD Connect to synchronize your user identities to Azure AD.

In summary, the 9 part series will cover:

Part 1 of 9 from the "SSO to domain resources from Azure AD Joined Devices -- The MEGA Series"

This first part of our mega-series will give an overview of how SSO to domain resources works from an Azure AD Joined device. In other words, how to access legacy systems from a pure cloud computer seamlessly (the user won't even know what hit them).

Many organizations are now in "full swing" when it comes to the implementation of the Microsoft Cloud offering. We have seen rapid adoption of Cloud technology to allow the workforce to "work from anywhere". Microsoft Teams alone saw a 775% increase in usage, in Italy, during the start of the COVID-19 pandemic in 2020. IT Admins have been among the many hundreds of unsung heroes during the pandemic -- often having to turn around new cloud technology in a coffee break.

VPN's have played a large part in enabling the workforce to access on-premises resources during the pandemic. More often than not this was to enable them to access file servers and Line of Business applications that were hosted inside the company's datacentres. Some companies have invested more time to remove the requirement of VPN by moving file shares to SharePoint Online and leveraging Azure AD Application Proxy to publish their internal web applications to their users working from home. However, some business applications are just not "Cloud" ready and the VPN is still a requirement to access those on-premises resources.

Interesting question. Hybrid Azure AD joined devices are joined to your on-premises Active Directory and registered with Azure Active Directory. If you answer YES to any of the following scenarios then you "might" consider Hybrid Azure AD joined devices:

And the world is not black and white. So feel free to mix both hybrid join and Azure AD joined devices if you have mixed use-cases throughout your enterprise.

One of the common arguments for requiring Hybrid Azure AD joined devices is the use of GPO. GPOs don't have a place in a modern strategy for Azure AD Joined devices -- there, I said it! Microsoft has given us a whole set of tools to configure our Azure AD joined, Windows 10/11 devices with Microsoft Endpoint Manager (MEM):

For the die-hard GPO fans, we can leverage Group Policy Analytics. This allows us to understand which GPOs are not available to MDM providers and may need more consideration on why/how they are used.

Group policy analytics is a great tool in understanding which GPOs can be configured in Intune. I would always encourage you to review the GPOs you have in place today.

This is where we get into the meat of this first blog post.

There are not as many smoke and mirrors at play here as you might think. A critical component, which is assumed you have in place, is Azure AD Connect. Another critical, and obvious assumption is that your device has line-of-sight to your on-premises resources and domain controllers. This will typically be over a VPN for devices that are not on the corporate network.

Azure AD "is" aware of your domain because it synchronises on-premises user and domain information (attributes) to Azure AD. When a synchronised identity logs into an Azure AD joined device, Azure AD sends a Primary Refresh Token (PRT) along with the details of the user's on-premises domain to the device. The Local Security Authority (LSA) service will then enable both Kerberos and NTLM authentication protocol on the device.

I have an Azure AD Joined device in my lab, connected to the same network as my domain controller. Let's see what happens when I sign in using my Azure AD credentials.

When I sign in on my client device, I see event 4768 on my Domain Controller. This confirms that my user has been issued a Kerberos ticket.

Magic! I don't need to perform ANY configuration to obtain that token. The only pre-requisite was that I had a line of sight with my Domain Controller and the user that I logged into my device with was a "synchronised" identity.

So now when I try and access a Domain resource... let us try the domain controller...

My device has sent the on-premises domain information and user credentials to my Domain Controller.

On my Windows client, I now have the necessary Kerberos ticket(s) to access that share on my domain.

We have seen in the above example that Kerberos authentication works. If the application or resource uses NTLM the device would have received an NTLM token -- SSO would still have worked. It is worth mentioning that any application that is configured for Windows-Integrated authentication would also work for SSO to domain resources from an Azure AD joined device.

Many organisations are enabling Windows Hello for Business (WHfB) on their Azure AD Joined devices -- this makes perfect sense. If you are using WHfB, you are not logging on with a Username/Password combination. You will be using a biometric or PIN.

WHfB requires additional configuration to enable on-premises SSO from an Azure AD joined device. There are two deployment models: the "Key Trust" model and the "Certificate Trust" model.

How Key based authentication works:

Public key mapping is only supported by Windows Server 2016 domain controllers and above.

To summarise, in order to allow authentication using WHfB, domain controller certificates must be updated to include the KDC AUTHENTICATION EKU.

Once you have modified your Domain Controller Authentication templates to include the EKU "KDC Authentication", your new Domain Controller Authentication certificate should have the KDC EKU.

You can login to Windows with WHfB and be issued with Kerberos tickets.

Remember that before you issue the new Domain Controller Authentication Certificate to your DCs, a valid HTTP Certificate Revocation Point should be available for your WHfB devices.

DFS is great for redirecting resources, and it is fully supported for Azure AD Joined devices. But you might run into a few snags when access is done over a split-tunnel VPN.

For Kerberos SSO to work, you must use a Fully Qualified Domain Name (FQDN) to access the file shares on a DFS Namespace (e.g. \\\\dfs.contoso.com\\fileshare1\\), this goes for the servers that the Namespace is redirecting to as well.

This first post in the series was designed to inform you that SSO is possible, to domain resources, from an Azure AD joined device WITHOUT requiring Hybrid Azure AD Join.

Microsoft has done some great work in making this feature just work -- let's spread the word, SSO to domain resources is EASY.

Special thanks to DANIEL STEFANIAK and STEVE SYFUHS at Microsoft for being awesome people willing to give time to help the community.

See you in Part 2 where we will CONFIGURE CERTIFICATES FOR AN ALWAYS ON VPN (AOVPN) SOLUTION.