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