uid=account email here,dc=okta name here,dc=okta,dc=com You should be able to match the settings with what’s normally displayed in the Jamf Pro GUI. I’ve run out our Jamf Pro config and censored the relevant parts for security. (Hello the Future! This might be horribly inaccurate by the time you read this!) At least definitive as of September 2021. As a result with much discussion on the mac admins slack and some experimentation, I decided to compile what should be the definitive okta settings guide for Jamf Pro. Sadly Okta rate limits the heck out of it and Jamf is particularly “noisy”. Leaving that aside, there are times when you have to make Jamf work nicely with it. LDAPS is one of those protocols that was handy when it was first invented but has seriously outlived it’s usefulness in today’s cloud first world. Just make sure you set it the same way you have set it on the app in Okta.Okta has a native LDAP interface that can be very useful for products that require it. Jamf documentation says "jamfconnect://127.0.0.1/jamfconnect". Note: the OIDCRedirectURI can be anything you want. For instance for the basic access app:įinally, a more advanced plist with some additional options, but most importantly, the OIDCAccessClientID and OIDCAdminClientID keys: Make sure you set the same in the config profile – see below.Īlso, after saving the app, hit ‘edit’ and change the ‘Allowed grant types’ – select both option under “Implicit (Hybrid)” Jamf documentation advises “jamfconnect://127.0.0.1/jamfconnect”. The redirect URL can be anything you want. 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… When creating the app in Okta, make sure you create it as NATIVE app and choose a Redirect URL. 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).īut 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. 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. The most basic deployment possible is adding a plist like: Either by writing the settings to a plist with ‘defaults write’, for instance: defaults write /Library/Preferences/.plist AuthServer -string "" Next, we need to configure Jamf Connect Login with our settings. Upload it to your Cloud Distribution point and add the package to your Jamf Pro pre-stage. ![]() Just rename the official installation pkg to have 'Okta' in the name and the authchanger will be flipped to Okta for you upon installation. 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. 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. Don’t forget to put your file permissions! # install Jamf Connect Login 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. 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. Only my vFuse created VM's seem to have the issue. I have been able to deploy JCL with Okta without any issues on VM Fusion VM's and physical Macs. Update 26/08/19: It seems that the "User blocked by OIDC lookup" issue was only linked to a specific Vm creation method (vFuse).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |