MSEndpointMgr
Home ยป Azure Active Directory ยป SSO to domain resources from Azure AD Joined Devices – The MEGA Series

SSO to domain resources from Azure AD Joined Devices – The MEGA Series

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:

  1. SSO to domain resources from Azure AD Joined Devices
  2. Configure Certificates for an Always On VPN (AOVPN) solution
  3. Set up a Network Policy Server for Routing and Remote Access authentication (NPS)
  4. Configure a Routing and Remote Access Server (RRAS)
  5. Set up a Device Enrollment Service (NDES)
  6. Install Azure AD Application Proxy to publish the Device Enrollment Service (NDES)
  7. Configure Certificate Templates in Intune
  8. Create a Simple Certificate Enrollment Protocol (SCEP) Profile in Intune
  9. Creating the Always On VPN Profile in Intune

SSO to domain resources from Azure AD Joined Devices

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

Why do we need SSO to domain resources from an Azure AD joined device?

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 hero’s during the pandemic – often having to turn around new cloud technology in a coffee break. Giving customers access to cloud services from their homes was a big win. Many companies are now questioning the requirement to bring everyone back into the Office and instead are considering a hybrid approach to their workforce’s location.

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. This leaves one big question…

Do we need Hybrid Azure AD joined devices?

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:

  • You:
    • support down-level devices running Windows 7 and 8.1.
    • want to continue to use Group Policy to manage device configuration.
    • want to use existing imaging solutions to deploy and configure devices.
      • NB: Depending on your skills, you can add Azure AD join to an exisitng imaging solution.
    • have Win32 apps deployed to these devices that rely on Active Directory machine authentication.
    • are provisioning Windows 365 Enterprise Cloud PC’s.
    • rely heavily on DFS using a public root domain.

The above list is a revision of what Microsoft are currently writing in the official DOCS at: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join-hybrid#scenarios

In our experience, the main reason customers are considering Hybrid Azure AD joined devices is if an application requires machine authentication in Active Directory. Actually, it doesn’t even have to be an application. If your users are required to access data on a resource computer in another forest, like a file share, then you will probably need to consider Hybrid Azure AD join for your devices.

More information on how Kerberos-based processing of authentication requests works over forest trusts can be found in the DOCS at: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/concepts-forest-trust#kerberos-based-processing-of-authentication-requests-over-forest-trusts

The cloud is a candy shop

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. If for example, you have sales reps in the field not depending on anything that would require a hybrid joined device, then we suggest that you get your feet wet by migrating those users to Azure AD Joined devices.

Group Policy (GPO)

One of the common arguments for requiring Hybrid Azure AD joined devices is the use of GPO. GPO’s 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):

  • Templates
  • Settings Catalog
  • Proactive Remediations
  • PowerShell Scripts
  • Custom Configuration Service Provider (CSP)

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

After you have exported your on-premises GPO’s using the Group Policy Management app you can import the XML to Group Policy Analytics where Intune will automatically analyze the GPO.

Export GPO by choosing “Save Report” in the GPMC.msc
Group Policy Analytics analysis of the imported XML

Group policy analytics is a great tool in understanding which GPO’s can be configured in Intune. I would always encourage you to review the GPO’s you have in place today. Try and question whether they are needed for Intune managed devices.

Unless you are following a strict baseline for configuration and can vouch for every setting, which cannot be replicated from Intune – great, use your existing strategy for device configuration, which may mean you have to consider a Hybrid Azure AD device join. If not, I would encourage you to look at managing your Azure AD joined devices from a fresh perspective. By all means, start with whatever security baseline applies to your business sector but then pause. Question the processes you have in place and whether they need to be re-considered for modern device management.

How does AD authentication work from an Azure AD joined device?

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

Kerberos authentication from an Azure AD Joined Device

Prerequisites

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. We will go through the configuration of a basic AOVPN setup later in this series.

The mechanics of it

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. The attributes that were synced with the user identity contain the domain information so now we are seeing a normal Kerberos/NTLM exchange with the domain controllers. That is the magic!

SSO to domain resources
  1. Azure AD Connect synchronizes user identities from Active Directory to Azure Active Directory. Domain identifying attributes are included on the synced user object including, but not limited to, SAM Account Name (used to create the profile path on AAD joined devices), Domain name and UPN.
  2. The User on the AAD joined device authenticates to Azure AD and obtains a Primary refresh token. At the same time The “Domain Name” attribute is used by the AAD joined device to locate the Domain Controller and the LSA service enables the Kerberos authentication protocol on the device.
  3. Normal Kerberos ticket issuance takes place.
  4. Access to a Domain Resource is requested. Kerberos tickets are requested and used to authenticate the request to the resource.

Go and read @SteveSyfuhs excellent blog on “How Azure AD Windows Sign-In Works” if you want to go deeper How Azure AD Windows Sign-in Works (syfuhs.net)

See it in action

Lab: Sign-in

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 – remember, this device is not domain-joined but it is aware of my domain via the Azure AD Connect information passed to the device when I obtained my PRT.

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. Let’s see what that looks like on my client.

Klist displays the cached Kerberos tickets

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. That’s it!

Lab: Accessing files shares

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

accessing a domain share

My device has sent the on-premises domain information and user credentials to my Domain Controller. I can see that Kerberos tickets have been issued to allow me to access that domain resource

Kerberos tickets issued

On my Windows client, I now have the necessary Kerberos ticket(s) to access that share on my domain. If I had tried to access a resource or application that supports NTLM I would have received an NTLM token.

I now have 3 cached Kerberos tickets

What applications and resources will this magic work for?

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.

Caveats

Any good blog post must contain a caveat or two.

Windows Hello for Business

Many organisations are enabling Windows Hello for Business (WHfB) on their Azure AD Joined devices – this makes perfect sense. I now have to backtrack and add a caveat to my previous statement where I said “I don’t need to perform ANY configuration to obtain that token”.

If you are using WHfB, you are not logging on with a Username/Password combination. You will be using a biometric or PIN.

Logging on with WHfB

WHfB requires additional configuration to enable on-premises SSO from an Azure AD joined device. There are two deployment models, to enable this. The “Key Trust” model and the “Certificate Trust” model. The “Key Trust” model requires a TPM on your device. The “Certificate Trust” model requires your domain to be federated to Azure AD – which is a complex piece of work. As many organisations are trying to move away from ADFS, we will focus on the requirements for the Key Trust model.

Key Trust Model

Why does Windows need to validate the domain controller certificate?

Windows Hello for Business enforces the strict KDC validation security feature when authenticating from an Azure AD joined device to a domain. This enforcement imposes more restrictive criteria that must be met by the Key Distribution Center (KDC)

How Key based authentication works: –

  1. Authentication begins when when the user first makes an attempt to access a resource that requires Kerberos authentication. The Security Support Provider (SSP) uses metadata from the Hello key to get a hint of the user domain.
  2. Using the hint, the provider uses the DClocator service to locate a 2016 Domain Controller.
  3. The SSP uses the private key to sign the Kerberos pre-auth data.
  4. The Kerberos SSP sends the signed pre-auth key and its public key (as a certificate) to the KDC.
  5. The KDC determines the certificate is self signed. It retrieves the public key and searches for it in Active Directory.
  6. The Domain Controller validates the UPN for authentication and returns a (Ticket Granting Ticket) TGT to the client with its certificate.

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

Further reading on how AAD joined devices authenticate to Active Directory using a Key can be found below

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication#azure-ad-join-authentication-to-active-directory-using-a-key

To summarise the above information, in order to allow authentication using WHfB, domain controller certificates must be updated to include the KDC Authentication EKU. More reading and implementation for this can be found in the links below.

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki

Note: Windows Hello for Business with a key does not support supplied credentials for RDP. RDP does not support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential.

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-overview#comparing-key-based-and-certificate-based-authentication

Put your money where your mouth is

Once you have modified your Domain Controller Authentication templates to include the EKU “KDC Authentication” and distributed as per the MS DOC above, your new Domain Controller Authentication certificate should have the KDC EKU.

Domain Controller Authentication Template EKU includes KDC

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

Kerberos Ticket pre-auth issuance using Key Trust
Kerberos Ticket issuance using Key Trust

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 Shares

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 might be aware that it uses DNS, so you will have to 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, everything should be configured with FQDN. Microsoft has some good info on converting your namespace to using FQDN at: https://docs.microsoft.com/en-US/troubleshoot/windows-server/networking/configure-dfs-use-domain-names

Here is a small PowerShell tool to make the conversion a little less tedious: https://github.com/mardahl/PSBucket/blob/master/Convert-DFSn2FQDN

If you are the lucky admin of a DFS Namespace using FQDN with a root domain that is also your firm’s public website (e.g. contoso.com), then you must take care to get all the routing via split-tunnel in place. Otherwise, you can obviously end up hitting the public website IP.

Summary

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.

Modern management of devices makes sense to me. Yes, there are still use cases for devices to access domain resources via VPN but as more vendors start moving the authentication model for their applications to support modern authentication methods I see this becoming less of a requirement over the next 5-10 years.

Special thanks to Daniel Stefaniak and Steve Syfuhs at Microsoft for being awesome people willing to give time to help the community with olive branches and blog posts and also to Michael Mardahl for jumping in with some great co-authoring and additions.

See you in Part 2 where we will Configure Certificates for an Always On VPN (AOVPN) solution

(15070)

Ben Whitmore

Community driven and passionate Senior Cloud Consultant at CloudWay with 20 years experience in driving adoption and technology change within the Enterprise.

Michael Mardahl

Michael works as a Microsoft Certified Cloud Architect with APENTO in Denmark. He specializes in customer journeys from classic Infrastructure to Cloud consumption with a strong focus on security. And has been working in the IT industry for more than 20 years, where he started as a Network Administrator in the logistics industry. He has gained experience through a broad range of IT projects throughout the years and was very early to embrace and share his cloud technology passion. When not at work, Michael enjoys the value of spending time with family and friends and BLOG's passionately about Microsoft cloud technology whenever he has time to spare - this has earned him the title of Microsoft Most Valuable Professional (MVP) in the Enterprise Mobility category.

14 comments

  • How can I make the process of accessing an on prem exchange mailbox seamless from an AADjoined device. With GPO, I could configure Outlook zero touch config and have it use the user primary SMTP address on first launch. Now I’m always prompted for the UPN, and have to select what account type I’m using (Exchange). After which I’m prompted to enter the AD password.

    This is one of my last steps to figure out with AADjoined devices. Any advice would be most welcome.

      • Kerberos auth is configured for exchange and I have a valid ticket. I do get an autodiscover prompt which I need to accept just prior to the password prompt however.

      • It should work for exchange connections. there might be another issue. Autodiscover is a story on it’s own, soo many misconfigurations are possible.
        Check you SPN settings in AD

  • I have a slightly interesting question around this, would it work in the following situation?

    A VPN between an office and Azure
    Active Directory Domain Services setup and accessible from the office via the VPN
    A domain member locally in the office joined to the domain controller setup provided by domain services

    Assuming a user at home also had a VPN to the office (including routes to the domain controller provided by domain services) via their Azure joined device… Should this still work the same?

    Ie. Should the PRT contain information about the domain provided by the domain services domain controllers and would the client retrieve a kerberos ticket from those domain controllers?

    Essentially getting rid of the domain controller from the office altogether.

    • All you need it line of sight to a Domain Controller in a Domain that the synced User is a member. Remember the user logged on to the AADJ device must be a synced identity. ADConnect syncs specific domain attributes with the user account and this information is used to locate a Domain Controller from an AADJ device for kerberos authentication.

  • Nice one Ben. This will give more confidence to organisations to jump straight to AAD joined and skip hybrid join. Adding a hybrid today is just adding another decommissioning task for tomorrow.

  • Will the device also process group policy, folder redirection etc as part of the “magic”?

    • GPO processing is not supported at all. You will need to migrate policies to MDM for Azure AD Joined Devices. And you can definitely move your folder redirection to MDM, but I might suggest you take a look at using OneDrive instead.

  • Amazing post. When can we expect the next part as the AOVPN is what we are struggling with? ๐Ÿ™‚

    • Lots of commitments in August but it should be coming soon. Drop me a DM on Twitter if you have specific challenges ๐Ÿ™‚

  • Hi Ben, awesome serie to look out for and thanks for sharing. One question i have is, why scep/ndes and not PKCS ? Much lighter footprint and no ndes/scep/AADproxy required.

    • Thanks for the comment RKast. When we get to that part of the series we will make a distinction between SCEP/PKCS. I personally don’t see SCEP as a challenge for admins who are maintaining an on-premises infrastructure ๐Ÿ™‚

Sponsors

Subscribe

Do you want to be notified of new posts on our site?

Please enter your email address below:

Categories

MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.