Hybrid Autopilot & ODJ Connector Permissions

Disclaimer: I recommend utilizing pure-AAD join in 99% of use Autopilot use cases. Hybrid join is excellent for getting existing domain-joined devices into Intune, with future replacement with an AADJ-only device. That being said, there are still use cases where hybrid Autopilot is desired. This post delves into me learning how it works so I better understand it and can speak knowledgeably about it with others.

Hello all, and Happy Holidays! I’m back with one more post for the year, to talk a bit about my recent experience with getting Autopilot & hybrid join to function, specifically regarding the Offline Domain Join (ODJ) connector. When I started down this path in my lab, I will admit that I found the docs to be a little lacking (Deploy hybrid Azure AD-joined devices by using Intune and Windows Autopilot). Specifically, the steps regarding installing and configuring the ODJ connector. Two specific questions came to my mind:

  1. Can this be installed and configured on Server Core?
  2. What permissions does the service account require?

Server Core?

Short answer to question one: no, it cannot.

Long answer to question one: since it isn’t documented, I decided to try it. After spinning up a Server 2022 Core server, I downloaded the latest ODJConnectorBootstrapper.exe via the MEM Admin Center and attempted to install it. Issue number one:

Attempting to install the ODJ connector on Server 2022 Core

Interesting, Server 2022 is definitely later than 2016. In looking at the installation log, I found these two lines:

OK, so it’s most likely looking at the value of InstallationType in the registry. For my own personal amusement, as this is now entering unsupported territory, I modified this registry value and tried again.

And we have success!

Except, when you launch the configuration tool, and click “Sign In”, the application crashed. Womp womp.

ODJConnectorUI.exe crashes after clicking Sign In

Alright, so this was mostly expected. As I mentioned earlier, diving this deep entered unsupported territory, but I “needed” to know.


Next, I wanted to know what permissions I could get away with when running multiple connectors. The documentation only states that all connectors must run via a service account that has the necessary permissions within Active Directory, but it makes no mention of the permissions required on the server itself. By default, the ODJConnectorSvc service will be configured to run as SYSTEM after installation. In my mind, this is not ideal. I’d prefer the service to run with as few permissions as possible.

The first step I took was to prepare a group Managed Service Account for the service to run as:

This gMSA will also need to be granted permissions within Active Directory to create computer objects; in my lab, I added it to an existing group that granted the necessary permissions to a specific OU for hybrid Autopilot devices to be created.

Next up is to configure a GPO to grant the above gMSA the “Log on as a service” right and link it to the OU containing the servers:

Granting “Log on as a service” rights

Finally, install the connector, configure it, then change it to run as the previously configured gMSA (be sure to disable IE ESC for Administrators so you are able to sign in):

Now, let’s take a look at the connector status in MEM Admin Center:

ODJ Connector Status

While this initially looks good, eventually, they will all go into an Error state. If we poke at the event logs, we’ll find the following:

If we switch the connector server back to running as SYSTEM, these errors will go away, and the status will return green. The problem is that when enrolling the connector, it enrolls a certificate that the service uses to authenticate to Intune, and the gMSA does not have permissions to this certificate’s private key. In order to fix this, we need to modify these permissions via certlm.msc by managing the private key:

Manage Private Key Permissions

Once the gMSA is granted read permissions to this certificate’s private key, and the connector service restarted, the connector status should return to green.

In order to update this on multiple connectors, I put together a short PowerShell script to configure the private key permissions and the service runas account, which can be found in my GitHub (https://github.com/ajf8729/Toolbox/blob/main/Active%20Directory/Set-ODJConnectorPermissions.ps1)

The above script accepts a parameter to specify the service account (in the form “DOMAIN\gMSA_name$”), configure the private key permissions, configure the connector service to run as the gMSA, and finally restart the service.

Hooray, we now have our ODJ connectors successfully running as a gMSA and without administrator rights!

Finally, in testing Hybrid Autopilot now…

Computer Account Created Successfully!

Happy Holidays Everyone!

Related Posts

2 thoughts on “Hybrid Autopilot & ODJ Connector Permissions

  1. This is wonderful. Thanks so much for your detailed write up. I, too, didn’t like the idea of using SYSTEM for permissions on this function and gMSAs are definitely the way to go.

Leave a Reply