Update 26/08/19: It seems that the "User blocked by OIDC lookup" issue was only linked to a specific Vm creation method (vFuse). I have been able to deploy JCL with Okta without any issues on VM Fusion VM's and physical Macs. Only my vFuse created VM's seem to have the issue. I'm sure I tested with physical machines in the pst, so not sure why the inconsistent behaviour, but it seems fine for me now. Updating the post below now.
Just like in my previous deployments with Azure, I repackaged the official installer, deployed it to a temporary location and add a post-install script to flip the ‘Authchanger’ to Okta.
installer -pkg /tmp/jcl100.pkg -target /
# Enable Jamf Connect
/usr/local/bin/authchanger -reset -Okta
Note: Once again, don't forget to sign you custom package and use a cloud distribution point in case you want to deploy it via a Jamf Pro pre-stage. Both are a requirement for pre-stage packages!
Update! The latest versions of Jamf Connect Login don't need the authchanger to be flipped manually (by tweaking the postinstall script above) anymore. Just rename the official installation pkg to have 'Okta' in the name and the authchanger will be flipped to Okta for you upon installation.
Upload it to your Cloud Distribution point and add the package to your Jamf Pro pre-stage. Next, we need to configure Jamf Connect Login with our settings. Either by writing the settings to a plist with ‘defaults write’, for instance:
defaults write /Library/Preferences/com.jamf.connect.login.plist AuthServer -string "yourdomain.okta.com"Or by using a config profile. The most basic deployment possible is adding a plist like:
<?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>AuthServer</key>
<string>yourdomain.okta.com</string>
</dict>
</plist>This, together with the ‘Autchanger’ flipped to Okta, would actually allow all your Okta users to login and create a user account through Jamf Connect Login. This basic setup worked fine for me, and yes, you could probably close it down by adding the optional ‘OIDCAuthServer’ key and create a custom Authorization Server linked to your Jamf Connect Login app (Okta -> Security -> API).
But I wanted to use OIDC and my 2 Jamf Connect Login apps in Okta to leverage the possibility to create Admin users based on the OIDCAdminClientID key.
So I created my 2 Okta apps, one to allow access for assigned users, the other to decide who gets Admin privileges on the Mac…
The redirect URL can be anything you want. Jamf documentation advises “jamfconnect://127.0.0.1/jamfconnect”. Make sure you set the same in the config profile – see below.
Also, after saving the app, hit ‘edit’ and change the ‘Allowed grant types’ – select both option under “Implicit (Hybrid)”
… and assigned my users to both apps. For instance for the basic access app:
Finally, a more advanced plist with some additional options, but most importantly, the OIDCAccessClientID and OIDCAdminClientID keys:
<plist version="1.0">
<dict>
<key>HelpURL</key>
<string>https://yourdomain.okta.com</string>
<key>LoginLogo</key>
<string>/usr/local/images/TTG.png</string>
<key>Migrate</key>
<false/>
<key>DenyLocal</key>
<true/>
<key>LocalFallback</key>
<true/>
<key>AuthServer</key>
<string>yourdomain.okta.com</string>
<key>OIDCProvider</key>
<string>Okta</string>
<key>OIDCRedirectURI</key>
<string>jamfconnect://127.0.0.1/jamfconnect</string>
<key>OIDCAccessClientID</key>
<string>0oab-**************-356</string>
<key>OIDCAdminClientID</key>
<string>0ode-**************-542</string>
</dict>
</plist>Note: the OIDCRedirectURI can be anything you want. Jamf documentation says "jamfconnect://127.0.0.1/jamfconnect". Just make sure you set it the same way you have set it on the app in Okta.
grtz,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Manager Technical Support | Jamf
Hey TTG, thanks again for your blogs. I now have this working on my test device but am just having a niggling problem with MFA that I thought I’d ask you about.
I have Okta doing MFA (Duo) across the whole organisation (requirement my boss has given me) when accessing the web portal, but I am unable to control MFA at application level for Jamf Connect. So what happens is, on every login using Jamf Connect the user is prompted for MFA and as you can imagine this is pretty annoying for a user, and I haven’t come across an option when using MFA to remember the device.
The only way I can get this to stop is to add an exclusion for the user for MFA at an organisation level, which obviously is not ideal as it lowers the level of security for the overall account. I also tried a sign on policy for the app itself to only ask for MFA once a week but this doesn’t seem to apply to Jamf Connect.
Have you found any way to control MFA prompts for Jamf Connect?
Hey Anil, as far as I’m aware you can manage MFA on an application level in Okta as well no? I’ll check that again.
Hi, I did create a rule for this but Jamf Connect was ignoring it and looking at the organisation-level rule, anyhow what I’ve done now is allowed local auth, so the 1st login (if account doesn’t exist) will be online auth with MFA prompt, then subsequent logins will be authenticated locally.
I can live with this, but my next challenge is to get Jamf Connect Sync to work so it can update the local password to match the Okta password if it is changed.
How does it handle existing mobile accounts? I don’t want my users losing their desktop, dock etc if I deploy this to them. So far I have been able to get it working by creating
Hi Mateo, for existing mobile accounts there is the demobilize key. That should handle it nicely, but as always: test with the latest version of JC before putting anything in production.
Hey TTG, thanks for writing up this blog. I have setup word for word how you posted and noticed that all users are still being setup as Admins.
I have ODICRedirectURI, OIDCAdminClientID, and OIDCAccessClientID all set and the 2 apps in Okta are set as Native Type.
Can’t for the like of me figure out what I am missing.
Hi Rob, I’d contact support for this. I don’t know out of my head if this is still the case, but I remember a product issue with that. Mention JC version and the plist you configured to confirm.