Yes, I told you in my previous post that I’d get back into the blogging action, and although I won’t be able to keep up with this frequency for sure, there is one topic which has been wandering through my head for weeks now: Jamf Connect and ADFS!
I already discussed the complexity of federated Azure environments long ago, and the semi-satisfying alternative of pure ADFS Jamf Connect configurations here, but there now is a new solution in the mix: hybrid Azure / ADFS configuration of Jamf Connect Login!
The idea is to split the two types of authentication Jamf Connect Login uses into:
- OIDC against Azure
- ROPG against ADFS
If you have been following the topic you know that ROPG, or Resource Owner Password Grant, is the culprit for the complexity of things here. Wait, what? Why?
Well let’s pause here for a moment and quickly have a closer look at what Jamf Connect Login is actually doing when provisioning the Mac with a user account.
For those not interested in the what and how, you can jump to the config and plist here.
The idea is to authenticate against a cloud based identify provider, with known credentials of the end user, and set those as the local account credentials on the Mac. Fine, easy! Well, yes in most case, but as said ADFS complicates things. With the exception of Okta, where the Jamf Connect Login screen can actually use the native Okta API (and although not recommended also OIDC if you want), all other iDP’s use OIDC for this kind of authentication.
When you look at the Jamf Connect Login screen, you’ll notice that it’s actually nothing more than a web based window presenting the login web app of the iDP. When you authenticate, Jamf Connect Login is using OIDC (or OpenID Connect) as a protocol to validate your credentials. Easy and straightforward! But why do we need ROPG then?
Well, the problem is that authenticating through this isolated OIDC mechanism, does not expose the password entered in the progress… so Jamf Connect has no idea what password to configure for the local account! This is where ROPG comes into play, and yes, this is actually the magic behind the whole Jamf Connect Login idea! If you’re familiar with Jamf Connect Login, you know that AFTER authenticating at the first login window (the embedded web app), you are presented with a second prompt to re-enter your password. Why? Yes ROPG! At this point Jamf Connect Login asks you to re-enter the password, captures it, and validates it a second time against the iDP. Doing this allows JCL to fully configure username and password of the local account.
That said, why is ADFS an issue? Well, although ADFS 4.0 (Windows Server 2016) has compatibility with ROPG, the complexity of possible variables in the actual setup of the environment (way beyond the scope of this post), quickly makes things go south. Doing ROPG directly again the ADFS farm is fine, but when an on-prem AD is federated with Azure AD, without PHS (Password Hash Sync) or PTA (Passthrough authentication), the flow of ROPG authentication against Azure does not always reach the ADFS server in such a way that the whole process of validating and capturing the password plays nice. And that’s when you get the dreaded ‘incorrect password’ error on that second login prompt.
Dropping the idea to authenticating Jamf Connect against Azure, and authenticate directly against ADFS is one option (with some consideration and limitations to take into account, as discussed here), but not ideal. Dropping ADFS and configure PHS/PTA instead would be ideal (ADFS is old tech anyway so slowly we should all start thinking of getting rid of it!), but not something you can just switch off without further consequences for other tools in your environment.
How to configure?
What do we need?
- Configure ‘a Jamf Connect app’ in Azure AD
- Configure ‘a Jamf Connect app’ in ADFS
- Create a plist for a hybrid setup
The good news is that both the Azure part as the ADFS part remains the same as in my previous posts, we just need to configure both as if we would make 2 different standalone deployments. One for Azure, and one for ADFS.
So allow me my laziness, but I’m just gonna refer you to both post I already published on the matter. Just go to the parts where either ADFS or Azure is configured, no need to go through the plist part. We’ll cover that below.
Note: Yes, for the Azure configuration you'll see that I mention things related to ROPG. This might not be necessary, but to keep things straight forward, just configure it like that, even if we'll tell Jamf Connect Login to do ROPG against ADFS. This also give you the benefit of having the Azure config ready for when you're ready to drop ADFS and go for a standalone Azure AD or PHS/PTA setup.
Jump to the part where I start configuring the ‘Application Group’ and stop before the part where I discuss the plist. However, it might be handy to write the OIDCROPGID and OIDCDiscoveryURL down. We’ll need them.
Note: I guess I should not be mentioning that, but it makes sense that, because we are moving the ROPG part from Azure to ADFS, the Mac of the end user needs to be able to reach the ADFS (or WAP) server of your ADFS farm. Both inside as outside the corporate network (if needed). I'll leave that part to you and your network team.
Just go through the full setup (including the ROPG related settings) and stop again at the part where I discuss the plist.
With both ADFS and Azure in place, the only thing we need is one little fancy plist! Yes, no additional magic!
For a full description of all keys we need in the plist go and read the Jamf KB. However, hereby my working plist with all the minimum required keys and values you’ll need for this hybrid setup.
Note: I did not set the ROPGTenant key as I don't know what that even does amongst the list of ADFS related plist keys. I will clarify that later and update here but to me that is only used for cloud iDP's and not ADFS (could be wrong but I did not need it). Furthermore, I did not configure a 'client secret'. As far as I know, ADFS does not even support client secrets.
<?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>OIDCProvider</key> <string>Azure</string> <key>OIDCClientID</key> <string>1d884884-12fd-4fba-9bec-71548a000000</string> <key>OIDCRedirectURI</key> <string>https://127.0.0.1/jamfconnect</string> <key>OIDCNewPassword</key> <false/> <key>OIDCAdminAttribute</key> <string>roles</string> <key>OIDCAdmin</key> <string>Admin</string> <key>ROPGProvider</key> <string>Custom</string> <key>OIDCROPGID</key> <string>25e77fe6-4793-4a51-bc5d-298aff000000</string> <key>ROPGRedirectURI</key> <string>https://127.0.0.1/jamfconnect</string> <key>ROPGDiscoveryURL</key> <string>https://adfs.domain.com/adfs/.well-known/openid-configuration</string> </dict> </plist>
As you can see we have the first part covering OIDC related keys, and the bottom taking care of pointing ROPG to ADFS.
Don’t forget to change the OIDCClientID to your Azure app ID, the OIDCROPGID to your ADFS app ID and check the ROPGDiscoveryURL.
In the plist above I also added the Admin Attribute and roles as discussed in my Azure post to differentiate who become an admin on the Mac.
That’s it! Deploy Jamf Connect Login, shoot that plist to all Macs, and there you go Jamf Connect Login and ADFS sorted!
Oh and what about Jamf Connect Verify? Well, easy! Verify only uses ROPG, so just have a look at my pure ADFS config for Jamf Connect Verify here. No hybrid stuff to configure, just deploy Verify with an ADFS config. You will find the Verify part at the bottom of the post.
As always, if you liked this post hit the like button, tell your friends about it, and leave a comment down below! Don’t hesitate to point me wrong or add anything I might have missed!
Oh yes, here is a bonus:
Troubleshooting our hybrid setup
In view of the complexity of ADFS I might not be able to go through a full set of troubleshooting steps, but here are some things which should point you in the right direction. If the first login, through the embedded web app at the Jamf Connect Login window is failing, there is something wrong with the Azure setup. With the settings I discussed for the Azure part of things, there is actually not much which should/could go wrong, so go back and check your Azure configuration.
Note: don't forget to assign users to the Jamf Connect Enterprise app! Take my update of the 6th of November into account.
However, if the second prompt to re-enter the password is causing you trouble, we need to focus our attention again on the ADFS part of things:
- First of all, is your ADFS farm in a known good state?
- Can you reach the login page? Should be something like: https://adfs.domain.com/adfs/ls/IdpInitiatedSignon.aspx
- Does your ADFS service have a valid SSL cert? Have a look at the ADFS Management tool:
- Is your ADFS / WAP server reachable from the Mac?
- Have the ‘Application Group’ and app been configured correctly?
- Check all keys and values in the plist again for typo’s. Make sure you have the correct app id and discovery URL!
- If all seems ok and it’s still not working… contact Jamf Support 🙂