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:
Finally, the link to the overview of all settings you can configure remotely in ‘Verify’: Jamf Connect Verify Preferences.
As well as the Jamf Connect Verify Admin Guide and Deployment Article.
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.
Grtz,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Enterprise Support Engineer II | Jamf
Great guide!
The only part that i cannot get to work is the kerberos / online password check with Azure AD.
It doesn’t check if the local and online password are the same until i click on signin manually.
Kerberos as in Kerberos Tickets is only for when in reach of the on prem DC, not against Azure. When KerberosGetTicketsAutomatically is set as well as the KerberosRealm
For the password check: https://www.jamf.com/jamf-nation/articles/628/jamf-connect-verify-preference-keys
Have you set anything for the following keys?
NetworkCheckAutomatically
TimerNetworkCheck
TimerLocalCheck
Well, at this moment we do have a on-prem AD but might not be there for long.
So setting it up for Azure AD.
If we only have Azure AD (and Azure AD Domain Services) is there any way that we can help the users to have their local and online password in sync?
I’ve just set the values you mentioned and pushed it to my test client; don’t know if it will have any effect if we use Azure AD.
Yes, Verify is only for Azure (apart from the Kerberos ticket functionality it has). So yes signing into JC Verify should already be enough to detect a mismatch, but the additional check should help.
Hi,
First off, thanks for this blog – it’s very thorough and extremely helpful.
I’m experiencing the same issue as Denis
“It doesn’t check if the local and online password are the same until i click on signin manually.”
If I go to the Jamf Verify App manually and click Sign In , I receive the prompt “Your network password is not the same…” but I can’t get it to prompt this without manually doing this.
Even signing out does not work as I have the work-flow setup where by it Verifies the password so it asks them to re-enter the password and it is looking for the AAD password again at this point which has not sync’d.
Do you have any suggestions?
Ok, thanks for the info. I need to test it again on my deployment. Will do that over the weekend, see how it behaves and reconfirm with what it is supposed to do.
I am trying this out too but it doesn’t seem like it does anything. I pull down the menu and click sign in. It doesn’t matter what I put in there, real info, bogus info- If I click Sign In, it doesn’t really appear to do anything. I have Jamf COnnect Login working with the same azure app ID. Any ideas?
@Scott Do you have ADFS in your Azure environment? Federated with ADFS?
It is hybrid, yes. Is that what you mean?
Yes, it’s a hybrid, if that’s what you mean.
Yes, that might be the issue. To validate the password Verify will use ROPG. The problem is that if your Azure is federated with ADFS, the ROPG flow does not reach your ADFS endpoint where the users passwords live (actually in you on prem AD). Hence Verify does not work. Same when setting “OIDCNewPassword” to “false” in Jamf Connect Login. It only works if you are not federated with ADFS and to password passthrough or password hash sync instead.
But I’ve been informed that there might be another setup in Verify which would allow the ROPG flow to work in the future. I need to dive into it and see what’s that all about but unless I’m overlooking something, currently not possible and ADFS is a roadblock.
I’m having a similar problem Scott did. Clicking on sign in doesn’t do anything. We use Azure AD sync. Initially I did also get an error indicating that the AppID was missing/required even though I had it entered correctly and I checked to make sure it matched what I had in the Azure portal.
Hi TTC..
Have you ever seen a issues where you deploy Jamf Verify.. The user authenticates but when verify checks that local password and azure are in sync it fails and keeps prompting the user to update the local password although its correct…
Yes, wild guess: there is a passcode policy profile on the device and the new Azure password is not compliant with the local password requirements. It says the local password is incorrect but it means it can’t change the local password due to the passcode policy enforced by the profile
I’m seeing this exactly problem as well. No password policy/configuration assigned to the device.
Check if Verify is not running by root…
It’s not. Should it be? It’s currently running as the logged in user.
No that is good! Then I run JC Verify in verbose mode via Terminal and check the logs https://docs.jamf.com/jamf-connect/1.19.1/administrator-guide/Collecting_Logs.html