##################################################
UPDATE 18th of March:

Well, beat me. After successfully posting the workaround below, I did not touch any setting of my Okta Instance, my prestage or config profile in Jamf Pro. Today I wanted to spin up a new VM - same macOS 10.14.3 template I used before - and guess what... the Jamf Connect Login screen started looping again. In the logs I find the "User blocked for signing in by OIDC lookup" again.

Hence I have no clue what's going on now, but it seems that adding the 'OktaEurope' key/string in the config is not fixing it anymore. Sames for 'OktaEU' which actually worked as well when I wrote the below.

This on Jamf Connect 1.0.0 as 1.0.1, as I tried with the updated version as well. At this moment I have no idea, but will update as soon as I have more info!
##################################################

There are moments where you test things over and over again, looping in a situation where you end up hitting your head against a wall and almost fall apart in a nervous breakdown.

Well, that almost happened to me while trying to deploy Jamf Connect Login with Okta. Whatever I tried, I could not get it to play nice over OIDC and I could not figure out why. I was starting to question myself and could not accept the fact that deploying Nomad Login+ Okta was a walk in the park, while following the same workflow with Jamf Connect Login did not seem to work.

Using a simple plist, with only the following key set, worked fine:

    <key>AuthServer</key>
    <string>yourdomain.okta.com</string>

But as from the moment I added any OIDC keys like OIDCAccessClientID (set to my Okta app ID), it broke Jamf Connect Login. Hours of troubleshooting went by, trying every possible mix of keys and settings… nothing worked. Hence the delay on adding a blog post on Jamf Connect Login and Okta.

Anyway, last Friday one of my colleagues mentioned that he saw similar, yet different issues with one of his customers, and that changing the OIDCProvider key to “OktaEurope” (instead of “Okta”) fixed it. Stubborn as I am, I initially ignored it because my Okta instance was actually showing successful authentications! So it could not be that right?!

Okta showing successful authentication…

But the Jamf connect logs: “User blocked for signing in by OIDC lookup”

Well, while ignoring the issue over the weekend, the new and fresh start of the week, as well as the fact that I ran out of any other possible thing I could try, forced me to give it a shot. You never know… and guess what… it worked! Oh boy! So happy it works now, but mixed feelings about all those hours gone… waisted. Lesson learned: don’t be stubborn and yeah, maybe I could have asked help from Okta… but the logs were telling me something different…

Anyway, it’s fixed and I now reached out to Okta to ask for some clarification. I will update ASAP. For now, with some delay, let’s have a look at how to deploy Jamf Connect Login with Okta ๐Ÿ™‚

Note: for those amongst you who have a European Okta instance, looking for a quick fix of this issue, here it is. Even if your Okta instance is a .okta.com or a .oktapreview.com, it seems that if it's hosted on a European instance you need to change your Jamf Connect config to:

<key>OIDCProvider</key>
<string>OktaEurope</string>

Now, let’s have a look at the full setup!

With that roadblock out of the way, the setup is actually quite straight forward ๐Ÿ™‚

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.

Don’t forget to put your file permissions!
# install Jamf Connect Login
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!

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. As said, that’s where the trouble started with the OIDCProvider key. Ok ok, I’ll leave it behind me from now ๐Ÿ™‚

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.

The redirect URL can be anything you want. Jamf documentation advises “https://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>OktaEurope</string>
        <key>OIDCRedirectURI</key>
        <string>jamfoauth://oauth-callback/okta</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 "https://127.0.0.1/jamfconnect". Just make sure you set it the same way you have set it on the app in Okta.

That’s it! Finally the magic works as intended, I can nicely authenticate with a standard user, become an admin if the user is assigned to the admin app or get the door slammed in my face if my useraccount does not have the Access App assigned.

All fixed!

Note: As said, I reached out to Okta to ask some confirmation on which value the OIDCProvider key should be set depending on the different Okta instances and geographic locations. I'll update ASAP once I have some additional info! For know it seems that "Okta", or "OktaPreview" should work, depending if you have a .okta.com or .oktapreview.com instance, but for my .okta.com instance I had to set it to "OktaEurope".

Let me know if you saw similar behaviour, or if you needed yet another value in the OIDCProvider key!

grtz,

TTG

Print Friendly, PDF & Email