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.
There two simple ways to confirm this:
1. Type sudo profiles -H
2. Open up System Preferences and see if the Profiles pref pane shows up
Unfortunately, I was never able to reproduce the issue or find the cause. Therefore I could never get any further in troubleshooting with Jamf. Fast forward a year later, through some other issues I was reporting and troubleshooting, I was able to finally reproduce the issue. The steps are real simple:
- Type
sudo rm -rf /var/db/ConfigurationProfilesin Terminal. This command will remove the profiles from the computer. - Confirm profiles are not installed by checking System Preferences (if you had it opened, quit and reopen it) and running
sudo profiles -Hvia CLI - Type
sudo Jamf recon -saveFormTo ~/Desktop/noProfilesInstalledin Terminal. - Check inventory record for computer and see Profiles. How many profiles do you see?
- Type
sudo Jamf mdmin Terminal - Type
sudo Jamf recon -saveFormTo ~/Desktop/ProfilesInstalledin Terminal. - 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 since configuration profiles were supported in the JSS. 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. Extension attributes allow you to collect data in the JSS that is not otherwise gathered by the jamf binary. This data is collected at inventory or when you run the jamf recon command on a client. There are two that I like to use, but there are even more out there that list out ALL configuration profiles if you want to get even more granular.
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>"
fiProfile 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 attribute as the criteria and then scope a policy to those groups. The policy should make use of the Files and Process payload option “Execute command”. Run the command:
jamf mdmto re-enable mdm on the client.
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, 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 more of an organizational policy (HR) issue than a technical (IT) issue. The problem here is with 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.
Feature Request
I was told to submit a feature request on JAMF Nation and so I did. I encourage you to up vote it if you are a Casper/Jamf Pro customer who uses MDM / Configuration Profiles through the JSS. 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 isn’t 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 as well:
https://www.jamf.com/jamf-nation/feature-requests/1979/list-locally-installed-mdm-profiles
https://www.jamf.com/jamf-nation/feature-requests/2624/search-for-installed-profiles-on-a-computer/
Babo D's Corner 
A typo, should be `profiles -H` not `profile -h`
LikeLike
Thanks for catching that. Forgot the ‘s’.
LikeLike