My teammates at Jamf who support Jamf’s own IT (known as Jamf @ Jamf) have developed an innovative method for allowing computer and mobile device smart groups to figure out device membership based on users and groups from an identity provider (like Okta or Entra ID) or an LDAP service (like Active Directory).

Normally, figuring out user and group membership is not a capability of computer and mobile device smart groups but the method the Jamf @ Jamf folks developed leverages MDM configuration profiles to bridge that functionality gap in the following way:

1. User is assigned an application with compliance policy in the organization’s identity provider.
2. A Jamf @ Jamf automation system adds User Extension Attribute criteria to a username in scope of a group provided by the identity provider.
3. A smart user group in Jamf Pro uses that criteria to populate group membership.
4. The new smart user group is used to scope a configuration profile.

The configuration profile referenced in step 4 above is then deployed to devices that match the smart user group’s membership. Once the profile is deployed, the profile being installed on a device is criteria which can be used by computer and mobile device smart groups. This allows the profile to be the bridge functionality to connect users and user groups from an identity provider or an LDAP service.

In the post I linked to earlier, the configuration profiles created for this purpose are referred to as “dummy profiles”, which are in turn a reference to “dummy receipts”. Dummy receipts are a method for creating a receipt for an installer package installed by Jamf Pro, which likewise can be used as criteria which can be used by computer smart groups.

But what goes in that dummy profile? Ideally, it should be something that deploys no settings at all. The dummy profile’s existence on a device is enough to accomplish the goal of bridging the gap between user and device scoping and for the sake of causing no complications, the profile should exist on the device and otherwise do nothing. Meanwhile, this should be an approach which can be used on all Apple platforms so we need something which can be deployed to all Apple platforms.

After thinking about this for a bit and discussing it with colleagues, it looks like the best way to accomplish this is to build a configuration profile with the following characteristics:

1. Profile with certificate payload
2. Certificate payload should have the following:

• Self-signed certificate’s public key
• Certificate lifespan should be set to an extended period of time, to allow the use of the profile over a long period of time without worrying about the certificate expiring.

The reason to use a self-signed certificate’s public key is that a certificate can only be used for something if you have both the public and private key available. Without the private key being available at some point in the communication process to authenticate the public key as being valid, the public key is effectively useless.

In this case, that’s exactly what we want – we want something useless in the profile’s certificate payload because something useless can’t be used! Using this approach will mean that our configuration profile will deploy no settings to a Mac or mobile device, and a malicious third party won’t be able to use the certificate either because only the public key for it will be available. For more details, please see below the jump.

To assist with creating the self-signed certificate’s public key for our dummy profile’s certificate payload, I’ve written a script which does the following:

1. Generates a self-signed SSL certificate’s public key and associated private key, where the script’s default settings are to create a self-signed certificate with the following characteristics:

• Certificate subject name is set to a UUID value.
• Certificate key is set to use a 4096-bit RSA key
• Certificate lifespan is set to 3652 days.

2. If the self-signed SSL certificate’s public key and private key are successfully created, script displays a message listing public key certificate name with a .cer file extension and the certificate public key’s location on the filesystem.

3. If the self-signed SSL certificate’s public key and private key are not successfully created, script displays an error message.

Note: Both the RSA key bit strength and lifespan are set using variables in the script, so these default settings can be adjusted as needed.

The private keys created by this script are completely disposable. For this purpose, we only want the public keys created by this script because we want a certificate payload which is functionally useless for use with Jamf Pro dummy configuration profiles.

A successful run of the script should produce output similar to that shown below:

Once the public key is created, a new Jamf Pro configuration profile can be created. For this example, I’m setting up a new dummy configuration profile named Advertising Department Software Test Group which will be deployed to Macs.

As part of creating the profile, I’m selecting the Certificate payload option and uploading a certificate public key file created by my script. In this case, the public key file is named 2E69ABC8-3B5C-4F8F-ACE9-BAAAE592BF1C.cer.

Once the public key is uploaded, you will need to set a display name.

In this case, I’m choosing 2E69ABC8-3B5C-4F8F-ACE9-BAAAE592BF1C, which matches the subject name of the certificate.

In the certificate options, uncheck the following options:

• Allow all apps access
• Allow export from keychain

Both settings refer to the certificate’s private key (which is not being provided with the public key), but not allowing these options for certificates when you don’t have to is a good security-focused habit to cultivate.

Once the public key is uploaded and all the other choices you want are made for the profile, the profile should look like this:

Once deployed to a Mac, the profile should look like this in this example:

For this example, in Keychain Access.app you should see that a certificate named 2E69ABC8-3B5C-4F8F-ACE9-BAAAE592BF1C has been added to the System keychain as a self-signed root certificate without a private key associated with it.

Once the configuration profile is deployed, you can use the profile as part of a device smart group’s criteria.

Now you can apply whatever user-focused criteria you want to the Advertising Department Software Test Group configuration profile’s scoping and the device smart group’s membership will update to only include those devices with the Advertising Department Software Test Group configuration profile installed on them.

The script referenced above is available below, and also on GitHub via the following link:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/create_certificate_public_keys_for_dummy_profile_certificate_payload