See below for an example config file and all available settings.
#What is jamf native macos connector password
For testing purposes, you can disable the sync between the local password and the Azure account by selecting the “Ignore Local Password sync”. The client secret is not used with Azure and the rest of the settings are just nice to have depending your goals. 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. Redirect URL: this has been set in the Azure native app to and is the same for Verify.Your Jamf Connect Application ID (see Jamf Connect Login, as you use the same native app).If you only installed Jamf Connect Verify, without deploying any settings, you can set it up manually for testing purposes. So, let’s first have a look at setting it up manually: The key to make it work is obviously configuring the settings. Unsigned packages, as well as packaged deployed via a Local File Share Distribution point don't work in a prestage! 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. For testing, you can just run the installer on your test machine, nothing special.
#What is jamf native macos connector pro
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. If you are deploying Verify together with Login, just repackage it like I did in my previous post. So for this quick overview, I’ll just deploy Verify separately. I could just add the Jamf Connect Verify to the prestage package, but Jamf Connect Verify can actually be used without Jamf Connect Login. In my discussion about deploying Jamf Connect Login, I repackaged the installer and added a post-install script for the authchanger and Notify, etc… Jamf Connect Verify is a tool used with Azure, while Jamf Connect Sync (Nomad Pro) is used with Okta. Note: Just for clarity, Jamf Connect Login is used with Azure or Okta.
And while there are plenty of different deployment scenarios possible, I’m going to keep this one short and simple.
You do need an on prem AD.Īfter 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.
So please ignore the domain, Jamf Connect Verify will NOT do Kerberos with Azure. The reason I'm using the '.' domain in my AD, was just for quick testing to make it easier to use the same accounts. To clarify this: Azure does NOT do kerberos (only for Win10 Azure bound device). This has caused some confusion with some readers. even in my On Prem AD, and also for my Kerberos Realm. Note: Below in this post you'll see that I use a.
0 kommentar(er)
