Configuration Profiles
XML files that configure macOS settings automatically via MDM.
Settings are enforced by macOS itself. Users can't change them.
What Are Configuration Profiles?
Configuration profiles are XML files (.mobileconfig) that declare settings macOS should enforce. Unlike scripts that run commands, profiles tell macOS "this is how this setting should be configured" and macOS takes over from there.
Why Use Profiles Instead of Scripts?
⚙️ Profiles Are Enforced
When you install a profile, macOS continuously enforces those settings. If a user tries to change a managed setting, macOS blocks it or reverts it. The setting is "locked down."
Example: A profile sets screensaver password to required. The checkbox in System Settings is grayed out. Users can't disable it.
📜 Scripts Are One-Time
Scripts change a setting when they run, but don't prevent future changes. A user (or another process) could change it back. You'd need to run the script again.
Example: A script enables the firewall. A user could disable it afterward. The script would need to run again to re-enable it.
Bottom line: Use profiles when a profile payload exists for that setting. Use scripts for settings that don't have profile payloads, or when you need to audit/report compliance status.
How Profiles Work
Your MDM server sends the profile to the Mac via the MDM protocol. This happens over HTTPS to Apple's APNs and then to the device.
The MDM client on the Mac receives the profile and passes it to the system. macOS validates the profile and installs it.
The profile contains one or more "payloads". Each payload configures a specific system feature (screensaver, firewall, passwords, etc.).
macOS applies each setting and marks it as "managed." Users see the setting grayed out in System Settings (Preferences).
As long as the profile is installed, macOS enforces the settings. Even after reboots, the settings remain locked.
Inside a Profile
A .mobileconfig file is XML containing:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "...">
<plist version="1.0">
<dict>
<!-- Profile metadata -->
<key>PayloadDisplayName</key>
<string>Security Baseline</string>
<key>PayloadIdentifier</key>
<string>com.yourorg.security.baseline</string>
<key>PayloadType</key>
<string>Configuration</string>
<!-- Array of payloads -->
<key>PayloadContent</key>
<array>
<!-- Screensaver payload -->
<dict>
<key>PayloadType</key>
<string>com.apple.screensaver</string>
<key>askForPassword</key>
<true/>
<key>askForPasswordDelay</key>
<integer>0</integer>
</dict>
<!-- More payloads... -->
</array>
</dict>
</plist>
Understanding Payloads
Each payload in a profile controls a specific macOS feature:
Controls screensaver settings including password requirement, timeout, and which screensaver to use.
Controls firewall settings including enable/disable, stealth mode, allow signed apps, and block all incoming.
Restrictions payload. Control AirDrop, iCloud, Game Center, camera, and many other features.
Password requirements including minimum length, complexity, expiration, and history.
MACE reads the mobileconfig_info from each rule's YAML and combines them into profiles.
Profile Output Options
Combined vs Individual
📦 Combined Profile
All payloads merged into a single .mobileconfig file.
Pros: Simpler to manage with just one profile to deploy. Easier to track in your MDM.
Cons: Can't scope individual settings to different groups. If you need to change one setting, you redeploy the whole profile.
📂 Individual Profiles
Separate .mobileconfig file for each PayloadType.
Pros: Granular control. Deploy firewall settings to all devices, but stricter password policy only to executives. Easier to update individual settings.
Cons: More profiles to manage in your MDM.
Format Options
MACE can generate profiles in different formats for different MDMs:
The standard Apple format that works with any MDM. Can also be double-clicked to install manually (for testing).
The same profile with its payloads wrapped in Custom Settings, so Jamf Pro keeps every key when you upload it.
Jamf Pro's "Custom Settings" payload expects a plist file. This contains the settings for a specific preference domain (like com.apple.screensaver). You upload this plist and specify the domain in Jamf. MACE also writes plists/manifest.plist, a map of domain to file to rules. Always one file per domain, and never signed.
Raw preference files in the shape Intune's Preference file template expects, one per domain. Payloads that only exist as a profile, such as the password policy, are written as .mobileconfig in the same folder. Never signed.
Profile Signing
What Is Profile Signing?
Profile signing uses a digital certificate to cryptographically sign the profile. This proves:
- The profile came from your organization (authenticity)
- The profile hasn't been modified since signing (integrity)
Why Sign Profiles?
Signed profiles show as "Verified" when users view them in System Settings → General → Device Management. Unsigned profiles show as "Unverified."
If anyone modifies a signed profile, the signature breaks and macOS won't install it. This prevents tampering.
Some security frameworks require profile signing. Your security team or auditors may mandate it.
How to Sign Profiles
You need a certificate with code signing capability in your Keychain. This could be from Apple Developer Program, your organization's CA, or a public CA.
In the Signing card, turn on Sign Exported Profiles and pick a certificate from Select certificate…. Only code-signing identities in your login keychain are listed. Then check which Signed Outputs to sign: Config Profiles, Audit Prefs, and in Advanced mode the Suppression profile.
MACE writes signed copies to the signed/ folder next to the unsigned originals. The offline suppression profile is signed into advanced_scripts/.
⚠️ Important: Signed Profiles Can't Be Modified
Once signed, a profile can't be edited. If you need to change a setting, you must generate a new profile and sign it again. Plan your baseline carefully before signing.
Deploying Profiles via MDM
Jamf Pro
📱 Uploading a .mobileconfig Profile
In Jamf Pro, navigate to Computers → Configuration Profiles.
Click "Upload" and select your .mobileconfig file. Jamf parses it and shows the payloads.
Give the profile a clear name. Review the payloads to confirm they're correct.
In the Scope tab, choose which computers receive this profile. You can target all computers, specific groups, or individual devices.
Click Save. Jamf pushes the profile to scoped devices. They receive it at next check-in (or immediately if you force).
🟢 Using Custom Settings with .plist Files
Go to Computers → Configuration Profiles → New.
In the left sidebar, click "Application & Custom Settings" → "Custom Settings".
Click "Upload" and select the .plist file from your build (e.g., MACE - com.apple.screensaver.plist).
Enter the domain, which is the filename after the prefix (e.g., com.apple.screensaver). plists/manifest.plist lists every domain and file.
Set scope and save. The settings apply to targeted devices.
Microsoft Intune
🔵 Deploying Profiles in Intune
In Intune admin center, go to Devices → macOS → Configuration profiles.
Click "Create profile". Select "macOS" as platform and "Templates" as profile type.
Select "Preference file" from the template list for the raw XML. (The "Custom" template takes a .mobileconfig instead.)
In the configuration settings, enter the preference domain and upload the matching .xml file from your intune/ folder. Any .mobileconfig files in that folder go through the Custom template instead.
In Assignments, select which device or user groups receive this profile.
Review settings and click Create. Intune pushes the profile to assigned devices.
What Happens on the Mac
When a profile is pushed to a Mac:
You can see it in System Settings → General → Device Management. It shows the profile name, payloads, and whether it's verified (signed).
As soon as the profile installs, macOS applies the settings. No reboot required for most settings.
In System Settings, managed settings show a message like "Some settings are managed by your organization" or the control is grayed out.
If deployed via MDM, users can't remove the profile. Only the MDM can remove it (or the device must be unenrolled).
Common Issues and Troubleshooting
- The profile wasn't signed, or the signing certificate isn't trusted
- Sign the profile with a trusted certificate
- Or deploy the signing certificate's root CA to your Macs
- Check that the profile actually installed (System Settings → Profiles)
- Some settings require a logout or reboot to take effect
- Check for conflicting profiles that might override settings
- Verify the payload type is correct for that setting
- Generate a new profile with the updated setting
- Upload to your MDM (it will replace the old version if same identifier)
- MDM pushes updated profile to devices
Best Practices
Before deploying to all devices, test on a small group. Verify settings apply correctly and don't break workflows.
Name profiles clearly (e.g., "Security Baseline - Screensaver Settings") so you can identify them easily in your MDM and on devices.
Not all devices need all settings. Use MDM groups to target profiles to the right devices (e.g., stricter settings for finance Macs).
Keep records of what profiles you deploy and why. The CSV export from MACE helps with this documentation.