If you join a device to Azure AD, then you get SSO to cloud resources protected by Azure AD. If you are using a Hybrid User (Synchronized from your on-premise Domain), you get an additional hidden gimmick. In general, it allows a lot of use cases where a company would like move to their authentication endpoints to cloud only, but still has a few on-premise resources.
As you can see my device is only joined to Azure AD and not joined to the local domain.
If I also check my Kerberos ticket by executing “klist”, I see that I have no Kerberos ticket as expected.
But if I’m inside my company network and access a network share….
I get access without an authentication prompt and received a Kerberos ticket:
Additionally, this works also for printers and webservers when adding the website to the intranet zone:
And even better for NTLM resources:
What happens here?
As when you are working in a workgroup, Windows can access other machines when there the same user with the same password exists. The clue is, that after you log in, Windows takes your entered password and stores its LM and NT hashes in kernel memory, which is the same hash as Active Directory is using. Additionally, your username is the same like in the local Active Directory. So, when the file server request authentication (Kerberos) the request can be signed by the local hash and the Key Distribution Centre (KDC) will then be able to return a Kerberos ticket.
Things to think about
With the above shown behavior, we should think about if a Hybrid Azure AD Join with Intune is required at all? In my opinion, the only benefit is at the moment only the GPO’s which you get by using a AzureAD Hybrid Join. If you see other benefits, please comment the blog or tweet @ThomasKurth_CH.
Special thanks to @John_Craddock for the hints during the Identity MasterClass. I highly recommend his MasterClass for everybody which is working with Active Directory and Azure AD.
- Microsoft Sentinel ASIM Parser demystified - March 31, 2024
- Enhancing Network Security Insights with IDS/IPS of Ubiquiti Dream Machine Pro and Microsoft Sentinel - March 10, 2024
- Ubiquiti Dream Machine Pro Logs to Microsoft Sentinel - February 6, 2024
9 Comments
bosmans · May 23, 2019 at 11:39
hybrid also works with downlevel clients/servers (not only W10). and i think if you have win32 apps that rely on AD machine authentication this only works with hybrid as well
Thomas Kurth · May 25, 2019 at 07:41
If the Win32app is using NTLM or Kerberos on Windows 10 then it works. But you are correct, downlevel devices require hybrid to work.
Anantha · May 24, 2019 at 09:14
We are using non ADFS solutions for federated servcices currently having bit of a struggle in getting the SSO established for the Azure AD Joined devices (Autoprovisioning process). Because as you mentioned there’s Kerberos token generated though the device comes within the defined Trusted IP range. Looks like we have to create a Web Application for the respective federated component , make it to work. Not sure if you had come across this scenario?
Thomas Kurth · May 25, 2019 at 07:43
Kerberos is always only working when you are on the Corporate Network and have access to a Domain Controller. But what you could try is publishing the application with Azure AD Application Proxy which accepts Modern Authentication, but then can do Kerberos against your internal web application.
I hope this helps
Menno · April 30, 2021 at 14:40
Does the Kerberos authentication process work from an Azure AD joined device through an AD Forest Trust?
Thomas Kurth · May 23, 2021 at 22:08
I have not tested this scenario until now. Also Microsoft does not clearly mention this as supported. I suggest to test this…
Fabian · August 13, 2021 at 08:31
Yes, and when changing the password you always have to change it twice (azure, on-prem) and fast enough before the account is locked by the automatic login attempts. Is this really a recommendation? And if weak authentication methods like NTLM are disabled (that’s really advisable), does it still work?
Thomas Kurth · October 26, 2021 at 08:34
When password write back is enabled the password needs only to be changed once.
If the password is changed on the device itself the password is changed in Azure AD and synced to AD with Password Write back. After a few minutes it can be used on-premises.
If the password is changed on a on-premise system the new password hash is synced to Azure AD and on the next login to the device the new password can be used and in the cloud systems immediately.
I never had issues like you describe unless I have saved the password in applications instead of using SSO.
Ultimate guide to define device names in Windows Autopilot Hybrid Join Scenario - Workplace Management Blog by baseVISION · June 10, 2019 at 19:20
[…] AzureAD Joined Device and Kerberos??? – May 22, 2019 […]