Disclaimer: This blog is not intended to be advice on how to manage your environment. As the name suggests, these accounts are based on experiences I’ve had in my own lab. Always approach information you find outside (or inside for that matter) official documentation with skepticism and follow the golden rule: Never test in production.
Since starting this blog last year, my most popular post by far has been Using Intune to Create and Demote Local Admins on MacOS. To my dismay, despite copious warnings to not put such an experiment into production; I regularly recieve emails thanking me for such a solution because Microsoft simply refuses to offer one and – to be clear – for good reason.
Historically, unmanaged identities – especially with a shared password – were often a necessary evil without tools like LAPS and an omnipresent IdP to allow admins to elevate and resolve issues like local account permissions and domain trust relationships. The hard to swallow truth is with cloud IdP solutions like Azure and Okta having a nearly ubiquitous presence in our post-lockdown global economy; these archaic workarounds simply have no justification in modern management.
In Azure, Azure AD joined Windows devices (excluding hybrid AD join) will accept any identity as a local administrator simply by adding them to the Local Administrator role. But what about MacOS? At the time of this post, Microsoft simply expects Mac Users to be admins on their own devices and sidesteps the issue entirely. It’s not a requirement and Intune will happily manage the device regardless of the logged in user’s privileges, but how can we find the middle ground between a restrictive account posture and administrative accessibility like we can on Windows? With Jamf of course!
Wait! Before you roll your eyes and unfollow me on Twitter, just hear me out. I know more than anyone how cliche it is to answer every MacOS MDM questions with “just use Jamf Pro” so I won’t even mention it beyond this point (though the process is nearly identical for both platforms). As the title suggests, this time I’m talking about Jamf Connect. If you’re unfamiliar, Jamf Connect is the branded proprietary successor to the open-source project known as NoMaD which offers to synchronize your local password with your cloud IdP credentials. Additionally, Jamf Connect Login will also overlay Apple’s lock screen with one that authenticates to the cloud and enables local account creation from those same credentials. Here’s the best part… Jamf Connect can be deployed with any MDM solution including Intune and costs less than a cup of drive-thru coffee per device per month. (See Pricing | Jamf)
Now you’re probably asking “That sounds great, but how does this solve the problem of provisioning an admin user while the user only has Standard permissions?”. Well, with Azure we can create roles for the Jamf Enterprise Application to set local account permissions during account creation in Jamf Connect and obtain feature parity with Azure AD joined Windows devices. Without further ado, let’s walk through the configuration and deployment together.
1) Integrating Jamf Connect with Azure AD
To avoid re-inventing the wheel, I’m going to reference documentation and summarize where possible. For this step, head over to Integrating with Microsoft Azure AD – Jamf Connect Documentation | Jamf to create the App Registration needed in Azure:
2) Configure App Roles
If you intend to use App Roles to destinguish between Admin and Standard users, DO NOT allow public client flows under the Authentication section until you have completed your user/group role assignments. If you are unable to add users or groups to the registered apps, check this and set it to NO, make your change, then set it back to YES. It will take 5-15 minutes for these changes to replicate so be patient.
Instead, go to App Roles and create an Administrator and Standard member types. Make note of the value you use here as you will need them later.
3) Configure with the Jamf Connect Configuration App
On a MacOS device, navigate to https://account.jamf.com/ and find your product Jamf Connect information page. There should be a blue button to download the tools and documentation and another to download the license file. Please download both. If you are testing with a Beta Program tenant and license, this will be located under Product Feedback
Mount the JamfConnect.dmg and drag the Jamf Connect Configuration app to the Applications folder. This tool will help you create the .mobileconfig files needed to configure Jamf Connect on the client workstation.
Launch the Jamf Connect Configuration app from Applications and start filling in the information. In this case all we need is to set the Identity Provider to Azure, fill in the Application (Client) ID from the registered app we created earlier into the OIDC and ROPG Client ID, and enter your Azure Tenant ID under Tenant. Finally, before leaving the Identity Provider tab, make sure you choose the downloaded Jamf Connect licesense file at the bottom. Unless you have other special configurations to make, this is the minimum required to function.
(Reference Jamf Connect Configuration – Jamf Connect Documentation | Jamf and Authentication Settings – Jamf Connect Documentation | Jamf)
Note: If you leverage ADFS in your environment, you will need to create a new application in ADFS that resembles the Azure Registered App and fill in the ID under ROPG Client ID and filling in the Hybird Identity portion of the Login tab. Failing to do this will result in Jamf Connect failing to Authenticate even if everything lines up in Azure. (Reference Federated Integrations – Jamf Connect Administrator’s Guide | Jamf)
3.1) Configure Jamf Connect Login
Jamf Connect consists of two parts each requiring their own configuration. Jamf Connect Login which drives the lock screen experience, and Jamf Connect (Connect) which handles the recurring password sync and password change/reset functions. Starting with Jamf Connect Login you will wish to review all the available options as these will drive the account creation behavior.
Note: I recommend you toggle any desired options (even if they are on by default) at least once before leaving it to the expected state. The current version of this tool does not include the configurations unless they’ve been changed. You can verify this by clicking the </> button and viewing the actual elements present in the config.
This is also where we plug in those App Role values we created earlier. For Azure, plug in the value of any roles intended to be local administrators under Admin Roles and set the Admin Attribute to “roles”. Technically speaking, we don’t have to identify Standard user roles. As long as they are not used to identify Admins, they will default to Standard access.
Update: For existing devices you may wish to enable “Connect existing local users to a network account“, “Always require network authentication“, and “Allow local authentication if a network is unavailable” to ensure your users are pairing the correct local account with their azure identity and are able to sign in locally without network access thus streamlining the migration and login process.
Be sure to fill in the Appearance section with any customizations for branding if you can for a finished look. You will need to deploy these seperately either via script or custom package payload to a static directory somewhere on the device.
3.2) Configure Jamf Connect (Connect)
Lastly hit the Connect tab and configure the behaviors required as needed including customizations, Sync frequency, expiration thresholds, password change/reset URLs, and requirements (though Azure or ADFS should determine this during the Self Service Password Reset process). Don’t forget to verify that the ROPG ID and Tenant ID fields are populated correctly from your Azure Registered App on this tab also!
(See this blog post from The Traveling Tech Guy on how to create the application for Jamf Connect in ADFS if needed: Jamf Connect against ADFS (without Azure) – Travelling Tech Guy. We only need the ADFS application ID to fill in the ROPG feilds.)
Once everything is configured as desired, take a moment and hit the Test button on the top-right. For Azure, test OIDC. For ADFS, test ROPG. Take a moment to review the token details and confirm the role attributes are being passed as expected.
4) Save Configurations and Deploy with Intune
If your test logins are successful, and you’ve validated the </> section for all the values you selected for each tab, go ahead and click the Save icon to export your .mobileconfig files. You will need to do this for each Jamf Connect and Jamf Connect Login, but you do not need to go back to the config tabs. The radio buttons here will export each config from those tabs based on your selection.
Fill in the Organization, Payload Name, and Description as appropriate. Do not check the Jamf Pro Upload box or fill in the server details unless you are trying to export directly to a Jamf Pro Server.
When complete, you should have two appropriately named .mobileconfig files.
Navigate to https://endpoint.microsoft.com > Devices > MacOS > Configuration Profiles > Create Profile. Set the Profile Type to Template and Custom. Fill in all the necessary details and upload each .mobileconfig file to it’s own profile and assign to your device groups as intended.
5) Deploy Jamf Connect Installer Packages
Deploying Jamf Connect requires two PKG installers from the JamfConnect.dmg we downloaded earlier. From it, grab the JamfConnect.pkg from the root of the dmg and the JamfConnectLaunchAgent.pkg from the Resources directory and put them somewhere handy like with your config files. Technically, you can get away with just the JamfConnect.pkg, but the JamfConnectLaunchAgent.pkg will ensure Jamf Connect is running even if the user closes it somehow. Best to deploy both of them.
Navigate to https://endpoint.microsoft.com > Apps > MacOS > Add and select Line-of-Business app for each Package. Fill in the appropriate details like Publisher, but leave most of the options as default.
Once assigned to our target device group, we will eventually see our configurations apply and Jamf Connect will be installed.
6) Test and Verify
Logging out will reveal the new Jamf Connect Login screen for Azure authentication.
After a new user authenticates with Azure, if passthrough authentication was not selected or if the initial password is set to be different users will be prompted to verify their Azure password to be applied locally more than once. The sync later will validate that it is correct, but this validation will also occur every time a password change is made and synced.
After completing setup assistant for our new users – one with the Administrator role and one without – we can see each was correctly configured on our Intune enrolled Mac.
That’s it! By now you should have a basic, but functional deployment of Jamf Connect using Intune. Take the opportunity to experiment and expand beyond the minimum options and make it yours. Such a combo deserves a little flair and sparkle!
