In this post I’ll take a closer look at how AADJ machines authenticated with an AD Synced identity can seamlessly access on-prem resources. This includes things like SMB file shares or other applications that require AD USER authentication. It’s important to remember if you have services utilizing machine authentication, those devices will need to remain AD joined or Hybrid Azure AD Joined. However, machine auth is not widely used, especially in small and mid-sized organizations. If you still have on-prem resources, it’s very likely they can still be accessed without additional user interaction if the user’s device is Azure AD Joined, and they’re authenticating with an Azure AD Connect synchronized identity.
Many organizations who want to move device management to the cloud think they should Hybrid join devices now and the transition to AADJ will be easy. The issue with Hybrid Join is there is no seamless transition from Hybrid Joined to Azure AD Joined. Hybrid devices are still Active Directory Joined and users are still authenticating against AD, not Azure AD (for user sign-ins to the PC). So, if you want to move a PC from Hybrid Joined to AADJ, your users will end up with a new user profile and you’ll likely be manually moving profile data (or using a tool to migrate the profile data for you). OR…. If you have good users (or you’re ballsy) you can convert their devices to Autopilot, wipe them, and have autopilot AADJ and Enroll their devices. Regardless of your situation, HAADJ usually ends up making more work for you if it’s implemented where it’s not necessary. If devices are already Hybrid joined, I suggest transitioning them to AADJ in waves, or have all replacement devices AADJ to phase out the hybrid devices over time.
The argument I hear the most from organizations is they still have on-prem resources and on-prem AD. Because of this, they think devices need to be hybrid joined to take advantage of cloud management & security features while still having seamless access to on-prem resources. Luckily, the device identity doesn’t have anything to do most common on-prem resources, such as SMB shares or Apps that use AD Windows authentication. When Azure AD connect is used to sync on-prem identities to Azure AD, is also synchronizes information to Azure about the on-prem AD environment. This includes attributes from user identities which are necessary to talk a Domain Controller and be issued Kerberos tickets, which grants users the ability to access on prem resources (details can be found here – https://learn.microsoft.com/en-us/azure/active-directory/devices/azuread-join-sso). Your endpoint’s DNS servers need to be able to resolve your on Prem DCs for this to function. If you already have a functioning on-prem environment, your DHCP is likely already pointing to your DCs for their DNS. Most organizations already have the pre-reqs for this in place, but they are below:
- Azure AD Connect synchronizing on-prem user identities
- Line of sight to a domain controller (LAN or VPN)
- Client DNS servers that can resolve your local AD domain
- An Azure AD Joined machine authenticated with an identity synchronized from Azure AD Connect
Let’s do a quick demo:
I have Two devices in my lab:
- A Hybrid-AADJ device (The user account, MFoley, is also synced to AAD via Azure AD Connect.)
- This device will behave like a traditional AD joined machine. Since its hybrid joined, it’s also registered to AAD and Intune enrolled. This device authenticates against the Local DC when users sign in.
- An AADJ device authenticating with the same user as the HAADJ device.
- This device is signing in with the synchronized cloud identity for user MFoley. When this device authenticates, it authenticates against Azure AD. However, upon authentication, it receives information about the domain and signed in user to see if it can find a local DC.
Here is our HAADJ device. We can see its Hybrid joined in the below screenshot:
And here we can see The Kerberos tickets issued for mfoley and that they were issues from my Lab DC just like a typical AD joined machine.
Here is our AADJ device also logged in with MFoley (same user as the HAADJ but with the synchronized cloud identity):
After signing in, if we look at our kerberos tickets, we have a TGT Kerberos ticket from the DC, even though this machine is not joined to the domain.
We can seamlessly browse SMB shares on the network and also connect to a SQL server using Windows Auth with the signed in user. GIF below to demonstrate everything in action, but you can see there is really no difference between these two machines when it comes to accessing on-prem resources. The only difference between them is one one of them is Hybrid AAD Joined, and the other device is Azure AD Joined.
Here is it all together below with the AADJ machine from sign-in:
What happens when a synced user password is expired, can they change it from AADJ device using Ctrl+Alt+Del ?
Without some additional configuration, No, they can’t change their on-prem password from an AADJ machine. With some additional configuration, you can match your password expiration policies and allow for Azure AD password writeback to on-prem. The answer in this link explains it very well – https://learn.microsoft.com/en-us/answers/questions/721416/password-expiration-with-aad-connect-password-hash.html.
A key piece of information is that this only works for user/pass logon, and not for WHfB
It works with FIDO2 keys or WHfB, but there is some additional configuration – https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base