UPDATE about the statement below: The 'OneLoginEurope' key is fixed and you should not need to configure Jamf Connect Login with 'Custom' provider anymore.

<key>OIDCProvider</key>
<string>OneLoginEurope</string>
--------------------------------------------------------------------
NOTE: I was told that configuring Jamf Connect with a OneLogin instance hosted in the EU does not work. See comments from Martin below. I presume this is an issue with the End Point Jamf Connect uses. Setting the OIDCProvider to "OneLoginEurope" does not work either.

Solution: set OIDCProvider to "Custom" and add the "OIDCDiscoveryURL" which you'll find here: https://developers.onelogin.com/openid-connect/api/provider-config

<key>OIDCProvider</key>
<string>Custom</string>

<key>OIDCDiscoveryURL</key>
<string>discovery URL</string>

Hi all, it has been a while since I posted another topic. Things got a bit busy, and I’ve been struggling fixing things with both ADFS and Okta in Jamf Connect. I still have some remaining roadblocks to tackle on those and will try to update those issues I mentioned in my 2 previous posts ASAP. But in the meantime, let’s have a look at another iDP integration in Jamf Connect: OneLogin.

Trying this one out was actually a relatively smooth ride, although I’m facing one minor issue which I’ll discuss at the end of this post.

So Jamf Connect and OneLogin, let’s have a look.

And oh yes… I’m adding something about Secure Tokens as well..

First of all I created a free dev account here.

Let’s start with configuring the OneLogin side of our integration with Jamf Connect Login according to the Jamf KB found here.

The first thing to do is create a WEB app in OneLogin (compared to other Jamf Connect integrations like Azure where you need a Native app).

Go to Apps – Company Apps – add new app, and search for the OIDC app template.
Name the app (e.g. Jamf Connect Login) and save it.

Go back in the app and set the Redirect URL to https://127.0.0.1/jamfconnect

On the SSO tab, set the Application type to WEB,…

and the Authentication method to “None (PKCE)”:

Next you need to assign users to the app. There are multiple ways of doing this in One Login.

The easiest way for testing your config is to manually assign the app to your test user:

Another way is to work via the Roles feature. By default all users in OneLogin are added to the “Default” role, so you could just assign the app to this “Default” role or create a new one:

You can either assign the app in the Role….
… or assign the Role in the app.

That’s it for a basic configuration of OneLogin for Jamf Connect! Next is the plist for our config profile. The mandatory keys are:

– OIDCProvider
– OIDCRedirectURI
– OIDCClientID
– OIDCROPGID (in case you want to validate the OneLogin password and set it as the local account password)

com.jamf.connect.login.plistDownload

In the plist I also have the OIDCAdmin key set (amongst other optional keys). I’ll come back to this below.

Tweak the plist to what’s needed for your deployment, add the app ID in OIDCClientID and OIDCROPGID and upload it as a custom preference in a config profile of Jamf Pro:

The rest is magic again.

If you’ve set OIDCNewPassword to false, you’ll get a second authentication to validate the password and set it as the local account password.

Yes…. I did not set any LoginLogo in this Jamf Connect test run. Apologies, but this would require to tweak the default Jamf Connect pkg again to deploy the image and sign it. Not the most important thing when testing, so I’ll just skip it for now.

If you set it to True, the user will be asked to create/choose a password for the local account:

After completing the user creation, you end up automatically logging in with the newly created user. And this is were I’d like to highlight 2 things!

First of all, Secure Tokens… yes they never go away… or better, depending the situation they are NOT automatically created. Unless you add the CreateAdminUser key to your config and set it to True (which makes ALL your Jamf Connect users admin accounts), you end up with STANDARD accounts. Hence, unless you logged in with an other LOCAL ADMIN first, there we be NO secure token holder on the machine. As discussed in one of my previous posts (still valid with 10.14.3, and although I did not test 10.14.4 with Secure Tokens yet I presume noting changed), this is not really a problem, just a consideration to keep in mind.

Having no Secure Token holder on the machine, does not block you from enabling FileVault with either profile or policy since 10.14.2. In earlier versions there was a bug in macOS causing profiles and policies to fail enabling FileVault if the user enabling it did not have a token.

The only consideration to make is that enabling FileVault via your end user who is a standard account (while no other token holder exist on the Mac) will give you a situation where your Management Account, or any other Local Admin account you use for IT admin purposes will not have a token, and won’t be able to unlock FileVault after a reboot. Have a look at my script to fix it if you really need to, but I still believe there is NO real need for having a local admin account with a secure token.

This personal opinion is based on the fact that I don’t see a real situation where you would need to have physical access to the Mac, reboot it and unlock FileVault without the user knowing you have his/her Mac in your possession. Or even without having the end user with you.

I only see a need for this when of-boarding end users… but that should not be a problem either as you should have the recovery key to bypass FileVault anyway!

Anyway, opinions might be different, just highlighting the fact that if the Jamf Connect user is a standard user, and this user is the first account ever logging in during a DEP workflow… there will be no secure token. And if you would log in with a local admin before, this admin account would get a secure token… but then the Jamf Connect user logging in afterwards would not get one!!! And this would even be a bigger problem, because this user would not be able to enable FileVault and your policy/profile will FAIL. You will need to grant the end user a secure token via your admin token holder… and this is where my script comes in to play again! A situation I’d try to avoid however!

So, you could avoid this by making everyone an Admin through jamf Connect, by setting the following key:

<key>CreateAdminUser</key>
<true/>

While this would then make everyone an Admin, they would get a Secure Token if they are the very first account to log in.

That’s it for my opinions and considerations on Secure Tokens and Jamf Connect.

Now, there is one more thing I wanted to test, being the automated creation of either Standard or Admin accounts, based on Roles in OneLogin. This is in my opinion a very nice feature of Jamf Connect, as it allows you to lock down admin privileges for those who don’t need it, while still allowing some users, developers for instance, to be admin on their mac.

Hence I added the OIDCAdmin key in my configuration, as mentioned above, and set it to the Admin role I created in OneLogin. I created a “JCAdmin” role and assigned my admin test user to it.

I tried with and without assigning the Jamf Connect Login app to it, with and without adding this admin user to a JCAdmin group and some other tweaks and changes to my OneLogin… but unfortunately my admin user never becomes and Admin. Not on a Vm, not on a physical machine. Whatever I try… I get a Standard account… 🙁

I’ll add this to my list of “Jamf Connect troubleshooting to do’s”, but if someone would have succeeded in doing so, please share in the comments below!

That’s it! Jamf Connect Login, OneLogin, something about Secure Tokens again and a small issue to investigate further!

As always, if you have comments, remarks, suggestions, leave a comment down below, and if you like this blog, tell your friend about it, share it or leave some feedback here!

grtz,
TTG