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:
- SSO to domain resources from Azure AD Joined Devices Overview
- Configure Active Directory and Certificates
- Configure the VPN Server (RRAS)
- Configure the Network Policy Server (NPS)
- Configure the Network Device Enrollment Service (NDES)
- Install Azure AD Application Proxy to publish the Device Enrollment Service (NDES)
- Configure Certificate Templates in Intune
- Create a Simple Certificate Enrollment Protocol (SCEP) Profile in Intune
- 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:
- 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):
- 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.
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.
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!
- 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.
- 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.
- Normal Kerberos ticket issuance takes place.
- 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
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.
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…
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
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.
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.
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.
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: –
- 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.
- Using the hint, the provider uses the DClocator service to locate a 2016 Domain Controller.
- The SSP uses the private key to sign the Kerberos pre-auth data.
- The Kerberos SSP sends the signed pre-auth key and its public key (as a certificate) to the KDC.
- The KDC determines the certificate is self signed. It retrieves the public key and searches for it in Active Directory.
- 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
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.
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.
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.
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 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.
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
I am currently using the default Azure DNS as the DNS server within an Azure Virtual Network. The network is connected to AVD Multi-Session Hosts that are Azure AD Joined. The virtual network is peered with another network, in which a classic Active Directory Domain Services VM domain-demo.de is located. To authenticate against the Azure AD Joined AVD Session Hosts, a hybrid user is used, which is synchronized from the Active Directory domain domain-demo.de via Cloud Sync.
I am looking for guidance on how to properly configure DNS, so that Azure AD Joined VMs can resolve the domain-demo.de domain correctly, and obtain a correct Kerberos ticket via LSA to authenticate against classic file shares, etc.
I have attempted to create an Azure Private DNS Zone (domain-demo.de) and linked it to the virtual network of the session hosts. Within the DNS zone, I created the following SRV records (_kerberos._tcp, _ldap._tcp) and an A-record for the DC’s name along with its IP address. Unfortunately, this configuration did not result in the desired outcome.
Could you please provide some advice or steps on how to achieve this DNS configuration? Thank you in advance for your help!
That seems like an overly complicated path you have taken.
Is it possible for you just to try and point the DNS configuration on the VNET over to the VM ADDS DNS servers in the VNET you are peering with?
It should resolve nicely after that.
It works now with Azure Private DNS Resolver.
Thank you so much for your reply 🙂
That sounds great!
This is a great blog, with a detailed overview of WHfB & Azure AD join.
I’ve just configured SSO to domain resources from Azure Joined devices using WHfB this week. Working great.
However, we have an internal RDS farm and it doesn’t play nicely with the key trust for WHfB.
Prompting for credentials and unable to use WHfB for authentication and having to choose from the list of available login methods.
Is the only option to reconfigure to use the certificate trust model?
RDS would need to use certificate login – this is supported without having to use the Cert Trust model.
Key trust and Cloud trust can do this:
You’ve stated under DFS Shares – DFS is great for redirecting resources, and it is fully supported for Azure AD Joined devices
I am getting an official advice from Microsoft saying that DFS won’t work with AAD Joined devices with SSO.
Any reference link for “DFS fully supported for Azure AD Joined devices”
We have used it on several customer sites, and they key is to use FQDN with DFs. so that is a must otherwise Kerberos won’t work.
I donøt have a link to a Microsoft article stating this specifically.
Very great post ! many thanks
This is a great article with fantastic resources. I am at the point where I think I understand the concepts and what needs to be done, but our network doesn’t have a dedicated Certificate Authority. From what I have looked at, this is a broad service that could be set up in many different ways for many different reasons.
I know this guide doesn’t cover setting that up, but do you have any resources for someone who hasn’t worked with an internal Certificate Authority before and really only wants it for this purpose?
Hey, thanks for the feedback! 🙂
You only need an internal CA for WHfB, SSO from AADJ Devices will work with just ADDS. Part 2 has been published which guides you through CA configuration for a simple AOVPN solution but the series wont cover CA concepts in and configuration general I am afraid.
Thanks for the reply! Unfortunately for me, I’m trying to deploy WHfB as we roll out more Azure AD joined devices, so I guess I have some learning to do! At least this will be here once I get that done.
Seeing as you don’t have any certificate infrastructure, you could try the recently released preview for Azure AD Kerberos.
Theoretically that should make all the certificate related parts of WHfB SSO to on-prem, magically disappear.
But you will have to try it out (it is as simple as enabling a CSP if you have a reasonably new W10 release).
You should probably call out somewhere early in this blog that you are assuming the user accounts are sync’d from an on-premises AD. Some customers have moved to cloud only users and computers but still need to access “legacy” on-premises stuff that requires an on-premises AD account.
Thanks John, we call that out early in paragraph 4 and then in more detail in the section headed “How does AD authentication work from an Azure AD joined device?”.
Sorry, I don’t undestand this- from the article above, I read that all legacy on-premise stuff should work. Provided your account contoso.local\mike is synced to AAD, you sign in to windows with contoso.com\mike and the legacy app signs you in with contoso.local\mike account. Or do I get it wrong?
We have a problem with SSO for applications that have a different domain name than our primary domain controllers. Lets say our AD domain is called some-domain.com and we access as website corpweb.some-domain.com and file shares and we have a PRT ticket for the DC and the user can access the website without additional prompt.
However if the user tried to access another website that uses another domain suffix like suffix-domain.com it fails to authenticate when accessing newweb.suffix-domain.com, and only work if we type the credentials. Any suggestions on getting SSO working for suffix domain would be appreciated.
I can’t speak for Ben, but my understanding of your problem is that you are trying to access a domain that has resources that require that you use an account in the so-called suffix domain?
For any SSO authentication with your primary identity, you need a trust of sorts, classic domain trusts, federation, oAuth or something that binds the SSO credential to the expected credential on the target resource.
These things are rather complicated in nature, so I would suggest you get a hold of a SME and draw everything out, so it becomes more clear how the authentication flow works now, and what needs to be altered in order for SSO to succeed.
If you are dead stuck, then I can suggest using an Enterpise App registration in Azure AD, and push through a forced static credential (assigned password) to your web app.
You as a n admin would need to maintain the actual credentials, but for the user access will be seamless through a managed browser like Edge.
I see on the screenshots you use Windows 11 for this blog series? You have a sollution for Always On VPN on Windows 11?
On our test devices Always On VPN on Windows 11 is not working. There is also a post on the feedback hub. Connection established after policy sync and disappear after a while or on next reboot.
The screenshots are only a part of the authentication with SSO section of the series.
They have no relation to the next parts of the series.
I have hear of the issues with Windows 11 and Always On VPN but as it is still not released at time of writing we can’t offer any guidance.
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.
Have you configured Hybrid Modern auth or Kerberos auth in your Exchange environment?
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.
Thank you for the article! I will keep this in mind.
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 🙂