This brings us to the hybrid solution of splitting OIDC and ROPG, as discussed in the current Jamf Connect Admin Guide and additional KB.
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. And that’s when you get the dreaded ‘incorrect password’ error on that second login prompt.ĭropping 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.
#Jamf pro okta password
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. 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 this allows JCL to fully configure username and password of the local account. 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. 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. Easy and straightforward! But why do we need ROPG then? When you authenticate, Jamf Connect Login is using OIDC (or OpenID Connect) as a protocol to validate your credentials. 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. 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. Fine, easy! Well, yes in most case, but as said ADFS complicates things. 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.
#Jamf pro okta mac
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.įor those not interested in the what and how, you can jump to the config and plist here. 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. The idea is to split the two types of authentication Jamf Connect Login uses into: 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! 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!
0 kommentar(er)
