Note: Below in this post you'll see that I use a .onmicrosoft.com domain... even in my On Prem AD, and also for my Kerberos Realm. This has caused some confusion with some readers. To clarify this: Azure does NOT do kerberos (only for Win10 Azure bound device). The reason I'm using the '.onmicrosoft.com' domain in my AD, was just for quick testing to make it easier to use the same accounts. Nothing more. So please ignore the domain, Jamf Connect Verify will NOT do Kerberos with Azure. You do need an on prem AD.
After deploying Jamf Connect Login with Azure in one of my previous posts, it was about time to have a look at adding ‘Verify’ to the mix as well. And while there are plenty of different deployment scenarios possible, I’m going to keep this one short and simple.
Note: Just for clarity, Jamf Connect Login is used with Azure or Okta. Jamf Connect Verify is a tool used with Azure, while Jamf Connect Sync (Nomad Pro) is used with Okta.
In my discussion about deploying Jamf Connect Login, I repackaged the installer and added a post-install script for the authchanger and Notify, etc…
I could just add the Jamf Connect Verify to the prestage package, but Jamf Connect Verify can actually be used without Jamf Connect Login. So for this quick overview, I’ll just deploy Verify separately. If you are deploying Verify together with Login, just repackage it like I did in my previous post. If not, just deploy it with a Jamf Pro policy, or even a stand alone pre-stage package if you have nothing else to deploy in the prestage. For testing, you can just run the installer on your test machine, nothing special.
NOTE: If you create a package to deploy in a prestage, you need to sign it AND it has to be deployed via a Cloud Distribution Point. Unsigned packages, as well as packaged deployed via a Local File Share Distribution point don't work in a prestage!
The key to make it work is obviously configuring the settings. So, let’s first have a look at setting it up manually:
If you only installed Jamf Connect Verify, without deploying any settings, you can set it up manually for testing purposes. The mandatory settings you’ll need are:
- Identity Provider: set to ‘Azure’
- Your Jamf Connect Application ID (see Jamf Connect Login, as you use the same native app)
- Redirect URL: this has been set in the Azure native app to https://127.0.0.1/jamfconnect and is the same for Verify
The Kerberos Realm is only needed if you plan to use Jamf Connect Verify to get Kerberos tickets from your on-prem AD, but I’ll come to that below.
The client secret is not used with Azure and the rest of the settings are just nice to have depending your goals. For testing purposes, you can disable the sync between the local password and the Azure account by selecting the “Ignore Local Password sync”.
With the above basic settings, without ignoring the local password sync, ‘Verify’ will check if the local password for the user matches the Azure password when signing in. If the passwords don’t match, ‘Verify’ will prompt the end user for the local password and change it to the one set in Azure. Only in this direction, never the other way around.
Now, what about Kerberos? First of all you’ll notice in the screenshot above that the ‘Verify’ menu icon is dark, not green. This means that it did not receive any Kerberos ticket. Well, important to remember is that this is only used in hybrid on-prem / Azure environments. If you do have an on-prem AD, linked to Azure via Azure Connect or not, you can configure Jamf Connect Verify to request Kerberos tickets for the end user and renew them automatically. For this the only setting you need to add is the Kerberos Realm, as in my first screenshot in this post.
For testing purposes I quickly configured an on-prem AD with the same domain name as my Azure test environment. Added the Kerberos Realm, put the VM in reach of my AD (Network, DNS, etc…) and clicked on “Kerberos Tickets”. Magic! The Jamf Connect Verify menu bar icon turned green and I had my Kerberos ticket!
NOTE: The Jamf Connect Verify menu bar icon will only turn green when a valid Kerberos ticket has been received, and YES you need an on-prem/hybrid AD infrastructure for this! The mac needs to be within reach of the Domain Controller.
So, with this basic and manual deployment behind us, let’s see how to configure it remotely with a plist/config profile. Just like with Jamf Connect Login, I’ll just upload a .plist file as a custom setting in a Jamf Pro configuration profile. However, best practice would be to make a nice mobile config, sign it and upload that to Jamf Pro.
Here is my example of a .plist with some settings:
Which results in the following settings being set:
That’s it! After all, deploying ‘Verify’ is not that complicated! Let me know if I missed something important, or if you have any questions / issues.