One approach to using IdP group membership for computer and device groupings in Jamf Pro

Now that I've been an engineering manager for over two years I find myself where I think "ah, this would be a good and helpful workflow, surely it can't be that complicated to implement" and then find myself in the situation where it is, in fact, complicated to implement.

One scenario where this happened, recently: surely it can't be that complicated to use an Okta group membership of a username and build smart computer and device groups for reporting based on the user group membership?

The flow I envisioned for this with my manager!brain:

User is assigned an application with compliance policy in org IdP
⬇️
User is added to user group in IdP for compliance policy
⬇️
Automation adds username to smart user group in Jamf Pro
⬇️
Username then populates/replicates across smart computer/device groups

Surly the magic that is Automation Systems can make this all happen with magic?

As it turns out is in, in fact, there is no magic and it is more complicated than that.

There are a few considerations at play here, as some Jamf Pro admins out there can likely cook up on their own. Some of the primary roadblocks we hit brainstorming this workflow were: the lack of a simple way to iterate through a whole list of criteria in a computer/device group and then add/remove usernames as needed; the differences in group management between the Classic API and Pro API; and, the lack of cross-object criteria availability for scoping (e.g., user extension attributes cannot be used for smart group criteria).

Fortunately for me, I am surrounded by kind people with big brains in the Jamf Information Technology department. We knew it would be easy to over-engineer a solution for this, so we tried to determine the simplest way to trickle down the information we needed from our IdP to Pro, then let the power of Jamf Pro's scoping and grouping handle the rest.

Our IAM and Automation experts proposed the following flow to get data into Pro for us to then digest in the way we (the Jamf Pro experts) thought would be easiest to maintain:

User is assigned an application with compliance policy in org IdP
⬇️
Automation system adds extension attribute criteria to username in scope of IdP group
⬇️
Smart user group in Jamf Pro uses that criteria to populate group membership
⬇️
The new smart user group is used to scope a profile that can be used for computer/device groups, as well as policy and application deployment scopes as needed

Once the automation systems (in this case, a combination of Okta Workflows and Tines) were configured to add that user extension attribute data to the user objects in Jamf Pro, it was up to the Jamf @ Jamf team to figure out how to get the other pieces in place for reporting and scoping. 

📦 The groups and profiles

One of the main end goals of this entire thing was to build reporting around comptuers + devices used by users in a specific Okta access group. Okta is an IdP, and Jamf Pro is a device management solution. The goal was to get the two things to meet in the middle, in spite of user extension attribute criteria not being available as smart computer or device groups. The simplest way to do this was to use the smart user group—built with criteria of the user extension attribute being managed by the Okta Workflows/Tines automation—as a scope for something that can have a scope. 

Example smart user group, build on criteria set on user objects by automation workflow

The simplest way to do this, with the least amount of friction or impact on the computers and devices used by these users, was to use what we would call "dummy" profiles.

Deploying and detecting the presence of a simple profile, with an innocuous payload, would act as the criteria we could use for downstream reporting or remediation down the road where needed.

For computers, it was pretty straightforward. We simply created a custom Application & Custom Settings payload with a custom domain and key/value pair.

Example configuration profile to scope to defined user group

Once the profile was in place, we made the deployment scope for the profile that user group we had created.

Scoping the custom profile to the smart user group

From there, we could make smart computer groups and build custom advanced searches based on the existence of the profile on the computer, helpful for additional policy and compliance baseline setting, as well as downstream event data reporting in our SEIM.

And then I found myself needing to figure out iOS. macOS is a bit more extensible when it comes to custom preferences and domains. iOS, by design, is not.

I was hoping I could find some way to deploy a profile to iOS devices that was as close to totally benign as the macOS one above. iOS will not install an empty profile, so that was not an option (neither will macOS) and I needed some other ideas. 

After asking around internally a few options appeared: 

• some kind of light-weight payload, like Notifications for a pretend domain, camera setting, etc. …
• I nixed this, as I don’t want any profile we deploy to look like it may be enforcing a setting of some kind and cause any confusion
• Notifications was mentioned by a few colleagues, but iOS only supports one Notification payload at a time, and the payload is not supported on BYO (I am trying to future-proof the workflow as much as possible)
• deploy a font
• just… no
• fonts are bad and you should feel bad
• deploy a “garbage” profile for a pretend domain and arbitrary value (akin to macOS shown above), that would need to be built out manually and uploaded to Pro to deploy
• testing was mixed on this, only about a 50% success rate of it being applied, and it seemed to arbitrarily require supervision to install
• deploy a certificate
• this seemed the most promising, as it would not be used anywhere for anything, is relatively hidden, can be customized and human-readable, and won’t make any settings adjustments

Ultimately I ended up making a very basic 10 year cert using openssl, uploading it to a certificate payload for a mobile device profile, and deploying to the same Compliance: IdP User Group scope.

Example of cert-as-deployment-payload for an iOS custom configuration profile

The scope for the iOS profile is identical to the macOS profile, which in these examples is the Compliance: IdP User Group scope.

Scoping the custom profile to the smart user group

Once we got all of this in place, we ended up with the following flow:

User is assigned an application with compliance policy in org IdP
⬇️
Automation system adds extension attribute criteria to username in scope of IdP group
⬇️
Smart user group in Jamf Pro uses that criteria to populate group membership
⬇️
The new smart user group is used to scope a profile that can be used for computer/device groups, as well as policy and application deployment scopes as needed

📊 The reporting

Once the profiles rolled out to devices associated with the users in the smart user group, all that was left to do was build advanced searches we could use for our own reporting and to send off to our SEIM for dashboards + audit reports.

(For the record, naming is consistent across the board in our production tenant for this workflow. I started this post a month ago and picked it back up to get it out the door, and didn't feel like updating screenshots. It's my party and however the rest of the song goes.)

In a future post I'll see if I can find a way to show a high level of how Tines and Okta Workflows are configured to integrate with Jamf Pro for the user extension criteria updating. This thing is already an unwieldy beast. But I hope you get the idea!

👢 JNUC 2024 in Nashville

Just a little addendum at the end here; if you happen to be heading to Nashville for JNUC please make sure to stop by the Jamf setup in the Expo Hall and stop by the Jamf @ Jamf station. My team of engineers, and a member of our brilliant IAM team, will be present giving demos and networking. Please say hi to them!

☮️❤️👩🏻‍💻