PLEASE NOTE THAT THIS POST DATES FROM BEFORE JAMF CONNECT ALLOWED FOR HYBRID SETUPS. THIS WORKFLOW WAS A WORKAROUND TO ALLOW SOME SETUP BUT IS NOT OFFICIALLY SUPPORTED BY JAMF -> please see hybrid setup for an officially supported solution. The officially supported hybrid setup avoids the domain\username issue mentioned at the end of this post. However, the part on how the create the ADFS app in this post is still valid and needed for the hybrid setup.
Hey all! Remember my previous post where I ran against issues with deploying Jamf Connect (Login and Verify) in environments where ADFS was federated with Azure? The suggested fix was to authenticate directly against the ADFS server, instead of via Azure.
Unfortunately this only partially worked for me, as I ran against the same roadblocks as when authenticating via Azure: ROPG did not work, hence no password validation in Jamf Connect Login and no way to get Jamf Connect Verify working.
However, on this Friday morning, I gave it another try, as I’ve been hearing from all directions that “Jamf Connect and ADFS just works”. Nice, but as I don’t believe in Unicorns, I have to see it myself before I actually take anything for granted. And guess what?! Yes, it works! Hooray!
I did not change anything to the way my ADFS farm is deployed, but after writing that previous post I got side tracked on other topics and did not try newer Jamf Connect versions. In the mean time there have been some updates, so it was about time I gave it another try!
Deployed Jamf Connect Versions:
- Jamf Connect Login 1.3.0
- Jamf Connect Verify 1.1.2
ADFS pre-reqs:
- ADFS 4.0 / Win 2016 (older ADFS versions don’t understand ROPG)
- ADFS Native app
So first thing the ADFS app, let’s have a look at how to create that. For this we need to go to the ADFS server and open the ADFS management tool:

Next, add an Application Group:

Give the app a name (Jamf Connect), and select ‘Native Application’:

Enter the redirect URL: https://127.0.0.1/jamfconnect.
Note the Client Identifier as you’ll need it in the plist to configure Jamf Connect later.

That’s basically it from the ADFS side of things! So what’s left? Well, nothing more than deploying Jamf Connect and creating a plist! As simple as it gets!
The only important thing here is to set the OIDCProvider to ‘Custom’ and add the OIDCDiscoveryURL. The discovery URL is https://FQDN-of-your-adfs-server/adfs/.well-known/openid-configuration.
Whether that’s only internally or publicly resolvable, I leave that to you and your security team, but just make sure it’s resolvable from wherever your end users might need to authenticate.
Required keys:
- OIDCClientID (the client identifier we copied earlier)
- OIDCROPGID (the same client identifier we copied earlier)
- OIDCDiscoveryURL (https://FQDN-of-your-adfs-server/adfs/.well-known/openid-configuration)
- OIDCProvider (Custom)
- OIDCNewPassword (set it to False if you want to validated the password over ROPG – actually the main purpose of the post 🙂 )
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>OIDCClientID</key>
<string>6ab82b08-94c7-482b-bd63-b06e10XYXYXY</string>
<key>OIDCROPGID</key>
<string>6ab82b08-94c7-482b-bd63-b06e10XYXYXY</string>
<key>OIDCDiscoveryURL</key>
<string>https://adfs.travellingtechguy.dev/adfs/.well-known/openid-configuration</string>
<key>OIDCProvider</key>
<string>Custom</string>
<key>OIDCNewPassword</key>
<false/>
</dict>
</plist>
That’s it! No more ‘Incorrect password’ on the ‘please re-enter your password screen!’

This should now nicely validate the password and complete the user provisioning / login!
So, what’s next? Yes! Jamf Connect Verify!
This is actually straight forward as well, just add the following keys to the plist:
- OIDCROPGID
- OIDCDiscoveryURL
- OIDCProvider
Below I’m adding additional keys as per my previous post on deploying fileshares, but the above 3 keys should be enough to make JC Verify work with ADFS.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>OIDCROPGID</key>
<string>6ab82b08-94c7-482b-bd63-b06e10XYXYXY</string>
<key>OIDCDiscoveryURL</key>
<string>https://adfs.travellingtechguy.dev/adfs/.well-known/openid-configuration</string>
<key>OIDCProvider</key>
<string>Custom</string>
<key>KerberosGetTicketsAutomatically</key>
<true/>
<key>KerberosRealm</key>
<string>TRAVELLINGTECHGUY.DEV</string>
<key>MenuShares</key>
<string>TTG Shares</string>
<key>MenuHomeDirectory</key>
<string>TTG Home</string>
<key>HideShares</key>
<false/>
<key>HideHomeDirectory</key>
<true/>
</dict>
</plist>
And yes! Success! ROPG login, Kerberos tickets, Shares… beautiful!

So where does that bring us? Well, if you do have ADFS in your environment, and authenticating with Jamf Connect via Azure does not work, there is this alternative setup!
For authenticating via Azure we’ll have to wait. As said before, there are so many variables and different setup in play which makes this extremely complicated to achieve I think. Don’t know, I’m not an ADFS expert 🙂
Oh yeah, one thing… the accounts actually get created as domain\username as reported here. I don’t have any fix or further info on this right now, so this might be something to keep in mind.

As always, if you like this blog, hit the like button, tell your friends about it and leave a comment down below!
Good weekend,
TTG
Hi TTG,
Currently we are facing challenges on configuring Jamf connect with Azure AD Hybrid setup, where AD FS is 3.0 and Password Hash Synchronisation method being used and getting an error while authenticating on client mac “ROPG check failed. Bad password”.
Please suggest and share us the step by step guide if possible, to address the issue.
Not much experience with ADFS 3.0 to be honest, but in order to understand the situation, if you go to Azure AD -> Azure AD connect settings in the Azure portal… do you still have Federation enabled AND password hash sync enabled? As I have seen recurrent reports of ADFS 3.0 issues, I’m wondering if that would cause issues… normally you step away from federation and replace it by PHS… what’s your situation?
See this: At this point, federation is still enabled and operational for your domains. To continue with the deployment, each domain needs to be converted from federated to managed to force user authentication via password hash synchronization.
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/active-directory/hybrid/plan-migrate-adfs-password-hash-sync.md
To verify that password hash synchronization works correctly, complete the Troubleshooting task in the Azure AD Connect wizard:
Open a new Windows PowerShell session on your Azure AD Connect server by using the Run as Administrator option.
Run Set-ExecutionPolicy RemoteSigned or Set-ExecutionPolicy Unrestricted.
Start the Azure AD Connect wizard.
Go to the Additional tasks page, select Troubleshoot, and then select Next.
On the Troubleshooting page, select Launch to start the troubleshooting menu in PowerShell.
On the main menu, select Troubleshoot password hash synchronization.
On the submenu, select Password hash synchronization does not work at all.
For troubleshooting issues, see Troubleshoot password hash synchronization with Azure AD Connect sync.
Thanks for the information. Both options were enabled and there is any way without changing existing set up to make work ?