Azure AD Hybrid Join Over VPN Issues

Hello once again! Long time no talk...read?

In this post I wanted to talk about the way Hybrid AAD Join works over VPN and an interesting communication I had with a Microsoft contact of mine recently.

I have covered Hybrid AADJ in the past, link here. Adding in the VPN adds a new wrinkle into the equation that is supposed to be solved by one of the HAADJ scheduled tasks. 

HAADJ creates a scheduled task that runs the dsregcmd.exe command. This command is built into the Win10 OS and this task is also built into the OS and have been running since day 1. These are located at Microsoft>Windows>WorkplaceJoin. This task has 2 defined triggers

The first trigger runs the dsregcmd at the initial logon. This does not help our VPN users at all unless you are deploying a prelogin VPN like Always-On VPN or Direct Access. The second scheduled trigger is supposed to kick off every hour after a reboot and generates a log in event viewer with ID 4096

This would allow a VPN user to reboot, login, and trigger the once an hour request, and if still connected to the VPN in an hour kick off the Hybrid Join process. This was not seeming to happen though. The timings of this event were very sporadic. I brought it up to a contact I have at Microsoft and it appears there was a bug that needed fixed! I have not validated with them what version/when/how this was going to be in place but if you are having issues with VPN+Hybrid Join hopefully it should be fixed in a future build.

Until next time fellow IT explorers

Securing Traditional Domain Joins

Hello Everyone!

My bread and butter are EMS deployments and some general O365 security talks. 

A lot of my customers really like the option to limit logins to certain cloud services to only Hybrid Joined machines using Conditional Access. 

For those unaware, at a high level, the Hybrid Join process will automatically join a domain joined Windows 10 machine into Azure AD. 

When I help people with setting this up I always check to see if they have modified who is allowed to join a computer to the domain. At the time of this writing (Server 2016) the default is that any authenticaed user can join up to 10 devices to the domain.

Thats right folks, by default you do not have to be a domain admin to join a machine to your domain. Above the obvious issues like clutter in AD, duplicate objects, SID issues, etc there is also the issue that the person who joins the object to the domain becomes the owner of that object in AD and can see some sensetive attributes.

Anyways, in our case this almost invalidates the reason most companies want to do Hybrid Join, which is to prevent personal machines from accessing corporate cloud resources. If the user brings thier laptop in though and decides to join it to the local domain then were back at square one. 

The easiest way to fix this is with a GPO on your domain controllers.

The GPO is located at Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignments > Add Workstation to Domain

Once you find the GPO you can add whatever group you would like to keep it locked down.

Just a little tidbit that some people dont realize! I think were all so used to only having an admin join a machine this can slip through the cracks.

Until next time, have a good one.

Azure AD Hybrid Join and the UserCertificate Attribute

Hello Everyone, 

Today I want to talk about an issue I ran into recently with trying to setup Hybrid Azure AD Join. 

First lets do a little background on the process. Microsoft has a decent guide on how to do it which can be found here.

https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup

The exact situation I ran into, or at least that I thought I ran into, was the fact that the device object was not syncing into Azure AD. 

In order for a Hybrid Join to occur you have to sync the device object with AAD Connect. Inside of AAD Connect there are certain sync rules and settings. One of those rules states if the userCertificate attribute on a machine is $null then do not sync it.

Now you technically can brute force a fix by either manually putting in literally anything for that attribute (I tried, it accepts a junk value) or changing the rule in AAD Connect to sync the object anyways. Either way I would not recommend as something else is most likely the actual root issue and wont fix the problem.

For awhile I chased down the idea that this attribute was generated upon domain join (due to a tip from an MS rep), spoiler alert, this is not when the attribute is generated on the Active Directory Object. This attribute is generated AFTER the Win10 device probes the SCP you setup in your AD and actually finds something. 

So, at a basic level, this meant that my issue was one of communication. For whatever reason my device was not communicating with Azure AD. This issue was solved two different ways for me when I ran into it across a few customers. 

1.) ADFS. If you have ADFS in place you need to place the claims rules in ADFS correctly. In my specific case the users UPN and the domain that they had federated with O365 was user@domainA.com but the real domain name on prem and the name that all the devices used was computer.domainB.com. The fix in this scenario was to federate domainB.com with ADFS as well and include domainB in our claims rules. 

2.) Scheduled Task. At two of my clients we ran into this without ADFS being in the mix. We were using AAD Connect with SSSO. The fix in this situation came in the form of enabling the scheduled task built into Win10 devices that attempts to do the Hybrid Join. This task can be found at Microsoft>Windows>WorkPlace Join. For some reason this was disabled, it should be enabled by default. I suspect something to do with SCCM but can not verify.

Once this was actually enabled the device was able to probe the Azure AD Join service, generate its specific userCertificate attribute and then complete its join after a login or two. If this does not happen for you this task can also be controlled by a GPO that can block the device enrollment. As a test I would move a device into an OU with no policies on it and work off it from there.

So, to recap, usually not having a value in the userCertificate attribute is not the actual issue. Something is stopping the communication between your machine and Azure AD. 

Event Viewer is also pretty helpful in tracking down some of these issues as well. You can view the logs at Microsoft>Windows>User Device Registration. If the above does not help you I would check here for further info. 

Hope this can help some of you, see ya around.