An issue you may see in your software deployment process is that an app is not being allowed for certain settings, even though you have configured and deployed relevant profiles.
This article will cover various points that, if overlooked, can cause issues or a misunderstanding.
Related Resources
- How To: Create and Deploy a PPPC Payload
- Allow System Extensions with Addigy MDM
- How To Get The Team ID, Bundle ID, and Code Requirement
Table of Contents
- Make Sure the MDM Profile is Installed Before the Software
- Check for any Incorrect or Missing Identifiers
- Checking Locally Enforced XML Information
- Creating a Custom MDM Profile
- OS Prompts vs Application Prompts
- Gray Slider in System Settings > Privacy & Security
Make Sure the MDM Profile is Installed Before the Software
Some permissions and settings relating to allowing an app require the MDM Profiles to be present before the app installation takes place. Having these profiles installed before the app also ensures that the end-user is not prompted to grant any permissions that can be automatically granted.
If you installed the MDM Profiles after the software in question, we recommend removing it from the device and reinstalling it.
Note: When deploying MDM Profiles and Smart Software/Public Software via the policy, our priority deployments will automatically perform any MDM Profile installations before any Smart Software/Public Software deployments, unless configured to do otherwise.
Check for any Incorrect or Missing Identifiers
One of the most common issues is that a specific app binary part of the larger application is not allowed and/or that a specific binary has an improper identifier.
Sometimes when an application updates, the binary identifiers may change. If this happens to a binary you are allowing and the application updates with a new binary, the permission will be lost if the new identifiers are not already in place.
Furthermore, applications may have many different binaries with many different identifiers, which will be very cumbersome to find.
To help verify if there are any incorrect or missing identifiers, we always recommend that you refer to any available remote deployment documentation from the software manufacturer, given most include this information. If this is not available in any documentation, it may be worthwhile to contact their support team.
If you are unable to follow the above recommendation, identifiers can be manually retrieved using this article: How To Get The Team ID, Bundle ID, and Code Requirement. However, it is important to note that for apps that use many binaries, these binaries may be hidden away in specific directories that are hard to find.
Checking Locally Enforced XML Information
One way to ensure that Addigy properly applied the MDM Profile details would be to locally view the device's enforced MDM settings. So long as the information entered in the relevant profile shows correctly within the output, then the profile was applied properly.
There are two ways that the enforced MDM Profile information (in XML) can be retrieved:
System Information > Profiles
To see the enforced profile data via System Information:
- Open System Information by performing a spotlight search (CMD+Space)
- Select the Profiles tab under the Software section
- Once in the Profiles window, you can select the specific profile name within the list, or view all enforced settings by selecting Device Configuration Profiles.
Note: You can use CMD+F to search for specific information within the enforced settings.
Profiles Command Option
This command accomplishes roughly the same thing as what the Device Configuration Profiles option above will show, however, this is more remote-friendly given the command can be run via Addigy. The command is as follows:
sudo /usr/bin/profiles list -output stdout-xml
Creating a Custom MDM Profile
Testing the application allow-listing via a custom MDM Profile can be a great way to verify whether there is an issue with how Addigy is creating the profile.
Two widely used custom profile creator tools include Apple Configurator and iMazing.
For steps on how to deploy a custom MDM Profile via Addigy, please reference the following:
How To: Configure and Deploy a Custom MDM Profile
OS Prompts vs Application Prompts
One important thing to note is that there is a difference between an application prompting for permission vs the OS prompting for permission. There have been cases where the application does not properly check for whether the required permissions have been granted, thus, it may not be an entirely accurate method of verifying if an app has proper permissions.
If you are receiving a prompt similar to the one below, this means that it is a prompt from the OS itself and the app does not have proper permissions. Do note that the prompt itself will vary in design and wording depending on what permission is required, but it is quite clear when the prompt is from macOS itself and not an app.
If you are receiving an application prompt, it may be inaccurate. We recommend first trying to use the app to verify functionality. For example, if an antivirus is asking for permission, try performing a device scan and see if any macOS prompts appear. If the application prompts prevent you from utilizing it, an app reinstall may be needed.
Grayed out Slider in System Settings > Privacy & Security
When allow-listing an app with a PPPC MDM Profile, you may see that the slider in System Settings is grayed out. This does not always mean that the app is not enabled for the relevant permission; it is more of a visual misrepresentation within System Settings.
This is an example of what it may look like for apps that appear to lack proper permissions but are allowed properly.
Similarly to the point above, we recommend simply using the app to ensure it can function normally without any issues. For example, an antivirus will not be able to scan all directories on a device if Full Disk Access is not provided.
If you have any questions about the content of this article, please do not hesitate to contact our Support team for further information.