Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Fix bug to properly reflect installed profiles in computer inventory

Sorry if this gets long, but this is important and needs to be properly addressed with some understanding. But just in case, TL;DR: JSS does not accurately report installed profiles. Feature Request for JSS to rely on Jamf binary to report all profiles installed on the client and not on the mdm command "ProfilesList".

Problem:
A year ago or so ago I discovered a bunch of computers at my previous job would drop all profiles. We could never find the cause, but what was alarming is that the JSS would report the computer as having profiles installed when in fact none are.

Two simple ways to confirm this:
1. Type sudo profile -H
2. Open up System Preferences and see if the Profiles pref pane shows up

Unfortunately I was never able to reproduce the issue. Therefore I could never get any further in troubleshooting with Jamf. Fast forward a year later, new job, new environment. Through some other issues I was reporting and troubleshooting, I was able to I finally was able to reproduce the issue. The steps are real simple:

  1. Type sudo rm -rf /var/db/ConfigurationProfiles in Terminal This command will remove the profiles from the computer.
  2. Confirm profiles are not installed by checking System Preferences (if you had it opened, quit and reopen it) and running sudo profiles -H via CLI
  3. Type sudo Jamf recon -saveFormTo ~/Desktop/noProfilesInstalled in Terminal
  4. Check inventory record for computer and see Profiles. How many profiles do you see?
  5. Type sudo Jamf mdm in Terminal
  6. Type sudo Jamf recon -saveFormTo ~/Desktop/ProfilesInstalled in Terminal.
  7. Check inventory record for computer and see Profiles. How many profiles do you see?

This is reproducible in the latest version of the JSS and probably goes back quite sometime. For some extra data, the recon command in steps 3 and 6 should reproduce XML of all the inventory information getting collected by the Jamf binary. The Jamf binary is ACCURATELY reporting whether profiles are installed. If profiles are installed the info will be enclosed in the <ns2:configProfiles> DATA HERE </ns2:configProfiles> tags and if profiles are not installed then it will simply list <ns2:configProfiles/>. In short, the issue is not on the Jamf binary.

The implications of this are huge. Your end users could delete that directory and completely bypass configuration profile enforcement. Let's take IBM as an example. All their users have admin access. Say they enforce filevault 2 key re-direction, some password complexity requirements, and some restrictions via profiles. Their end users could bypass all of that.

What does Jamf have to say:

Currently, the list of profiles that we see in a Computer Record is generated not through 'Jamf recon' or through utilizing the 'profiles' binary; but through the MDM command 'ProfileList'. The MDM command would need to come from the JSS, and unfortunately, would inevitably fail considering the machine removed its MDM profile. Considering this, and what you mentioned with the need to know what profiles are currently on the client computer, what would be needed is essentially a feature within the Jamf binary framework that detects whether or not the MDM framework has been broken. And, if it is broken, repair it. In the end, an end user with admin privileges would be able to do just about anything. We have lots of customers that utilize a home brewed type of 'self repair' using LaunchDaemons. That too though, can be broken by an admin user.

Remediation:
What can you do in the meantime? Create an extension attribute. There are two that I like to use, but there are even more out there that list out ALL configuration profiles.

Profile Count

#!/bin/bash

profiles="$(profiles -C | wc -l)"
profile_count="$(echo $profiles - 1 | bc)"

if [ "$profile_count" -gt 0 ]; then
    echo "<result>$profile_count</result>"
fi

if [ "$profile_count" -le 0 ]; then
    echo "<result>0</result>"
fi

Profile Status:

#!/bin/bash

#If profiles are on the computer it spits out:
#profiles are installed on this system
#otherwise:
#profiles are not installed on this system

profile_status="$(/usr/bin/profiles -H)"

echo "<result>$profile_status</result>"

Create a smart group with the extension attributes as the criteria and then scope a policy to those groups. The policy just needs to run the command: Jamf mdm to re-enable mdm on the client.

So if I can create an extension attribute, what's the problem? The JSS is supposed to report accurate inventory information for each computer client. It should be accurate up to the last recon/inventory update it did on that client. If we cannot trust the inventory records in the JSS then what good is it? Apple is the one pushing MDM and our reliance on it. Jamf is supposed to be the biggest cheerleader behind that given their quick implementation on almost all mdm/dep/vpp features that Apple introduces. However, how can we trust MDM if the JSS isn't reporting things accurately?

You might argue: just don't give your users admin access. Unfortunately, that's not possible in all environments, and usually there are some exceptions that need to be made. But even so you then start getting into how far down do you lock your computers. You might argue, if the user is removing profiles, they can just remove the Jamf binary altogether. Yes, this is true, but that then becomes an HR issue. The issue here is more on reporting and gaining insight. If someone removes the Jamf binary, at least the JSS can at least run reports on the last check in for clients based on the data the JSS has and you can trust the record is accurate. But you cannot do this by looking at the JSS profile record for clients.

The feature request
The data that the Jamf binary collects on installed profiles should be what is reported by the JSS. Do not rely only and primarily on the mdm command "ProfileList". Currently, the JSS does NOT even properly report anything useful or accurate on locally installed profiles either. By allowing the JSS to display what the Jamf binary reports based on actual profiles installed, companies can get accurate and insightful data.

The second part of this is that, the Jamf binary SHOULD re-enable MDM of course IF AND ONLY MDM is supposed to be disabled from the client.

Here are the feature requests regarding locally installed profiles and scoping to config profiles which I strongly encourage you to upvote:
https://www.Jamf.com/Jamf-nation/feature-requests/1979/list-locally-installed-mdm-profiles
https://www.Jamf.com/Jamf-nation/feature-requests/4515/report-data-on-all-configuration-profiles-on-a-device
https://www.Jamf.com/Jamf-nation/feature-requests/2624/search-for-installed-profiles-on-a-computer

Comment

Posted: 10/30/16 at 6:42 AM by PeterClarke

The two code lines:
profiles="$(profiles -C | wc -l)"
profile_count="$(echo $profiles - 1 | bc)"

could be implemented as: profile_count=$(( $(profiles -C | wc -l) -1 ))

No need for the intermediate variable 'profiles' nor the call to bc.
NB to be clear the double brackets (( and )) are required..

Like

Posted: 10/31/16 at 9:46 AM by bpavlov

Thanks for the one-liner. Simple and more efficient.

Like

Posted: 11/1/16 at 12:38 PM by bpavlov

It was pointed out to me that I made a typo: The actual command should be: sudo profiles -H not sudo profile -H (missing the 's'). You might have already figured this out by the extension attributes or just by using the profiles command previously. But figured I'd mention it just in case.

Like

Posted: 2/2/17 at 3:06 PM by bpavlov

Giving this a small bump. If you rely on MDM and config profiles then this is pretty important to address.

Like

Posted: 3/8/17 at 11:56 AM by CasperSally

If apple is pushing everyone to profiles, shouldn't this be of the highest priority as config profiles are used to secure systems?

Jamf saying "In the end, an end user with admin privileges would be able to do just about anything" is pretty irrelevant. Almost none of our users are admins, but we have quite a few machines reporting no profiles installed even though the jamf inventory record reports they are installed.

Like

Posted: 3/22/17 at 10:00 AM by bpavlov

9.98 got released today and these two new features get us part of the way to addressing the issues stated here:

-All configuration profiles now appear in a device's inventory report, regardless of the device's installation method.
-You can now create smart groups and advanced searches using configuration profile names and identifiers.

A big thanks to whoever worked on implementing the 2 new features.

With that said, there is still one component of the feature request that hasn't been implemented: the JSS should still be remediating if mdm profile/config profiles have been removed. If MDM/configuration profiles have been 1) removed and 2) the computers are scoped to have these installed AND 3) a command to remove the MDM profile hasn't been pushed to the device, then the jamf binary should automatically remediate similar to how you'd run sudo jamf mdm. I wish I could edit my feature request because reading it over I see I made a typo. Anyways, this is the last part I would like to see implemented here.

Like

Posted: 3/22/17 at 10:01 AM by bpavlov

9.98 got released today and these two new features get us part of the way to addressing the issues stated here:

-All configuration profiles now appear in a device's inventory report, regardless of the device's installation method.
-You can now create smart groups and advanced searches using configuration profile names and identifiers.

A big thanks to whoever worked on implementing the 2 new features.

With that said, there is still one component of the feature request that hasn't been implemented: the JSS should still be remediating if mdm profile/config profiles have been removed. If MDM/configuration profiles have been 1) removed and 2) the computers are scoped to have these installed AND 3) a command to remove the MDM profile hasn't been pushed to the device, then the jamf binary should automatically remediate similar to how you'd run sudo jamf mdm. I wish I could edit my feature request because reading it over I see I made a typo. Anyways, this is the last part I would like to see implemented here.

Like

Posted: 4/3/17 at 12:19 PM by beth.lindner

Thanks so much for taking a look at the new enhancement @bpavlov! We were quite pumped to release it. The piece that is left of this feature request is about redeploying Configuration Profiles correct? So for example a device is in scope for Profile A, the end user removes Profile A, the JSS reflects in inventory that Profile A is no longer installed, so the JSS initiates a new install of Profile A based on the scope? Is that an accurate recap?

Like

Posted: 4/3/17 at 1:16 PM by bpavlov

@beth.lindner Yes I think that captures part of the scenario I'm describing. I'll elaborate a bit more below:

The scenario I'm thinking of is where the client for whatever reason may have MDM disabled, but the disablement did not come from the JSS or an approved Jamf method of disabling MDM. In this scenario, I would envision the JSS to pick up the mismatch and remediate. That is, the JSS or some other approved disablement method did not send the Disable MDM command to the device and therefore the JSS would re-enable MDM. On the client side, MDM could have possibly been disabled by many reasons: someone deletes /var/db/ConfigurationProfiles, someone runs jamf removeMDMprofile or some other scenario. I do not believe that if a client runs the jamf binary command that it removes back to the JSS that MDM has been disabled, but I could be wrong. Perhaps something to be tested.

In that scenario, the JSS would remediate by 1) turning on MDM on the client, and 2) going through the exact workflow you just described to make sure Profiles A, B, C which are scoped to the computers are pushed back on.

What this does is makes sure that the only way to disable MDM on a device would be through the JSS or some other approved method. To build off that, the command jamf removeMDMprofile is a jamf command to remove MDM from the device. Perhaps you might want to consider updating the jamf binary (assuming it doesn't already work this way) so that it can communicate with the JSS and allow disablement of the MDM on a client as another approved method. In other words, the client would tell the JSS: "Hey, i'm an enrolled client. i'm disabling mdm through the jamf binary (an approved method) that's not coming from the JSS. I'll let you know in a second once I've disabled MDM so that you can update this on your inventory records and don't try to re-enable MDM on me."

Does that make sense?

Like