Author: JD Strong

Declarative Device Management (DDM) represents a significant leap forward in Apple device management. By enabling devices to enforce configurations autonomously and report their compliance dynamically, DDM eliminates many of the challenges that plague legacy profiles. However, with only ~20% of MDM configurations currently available as DDM profiles, early adoption and feedback are critical to shaping its future. This is a continuation of my exploration of DDM. We will look at the available DDM profiles, how to create, deploy, and verify DDM profiles.

Addressing the Challenges with Legacy Profiles

While legacy profiles remain functional in many scenarios, they often fail to reliably enforce critical configurations, such as passcode policies. For example, a legacy passcode policy delivered via .mobileconfig may prompt users to update their passcode but allows them to dismiss the request, leaving devices non-compliant. And, lack of enforcement for software updates is part of the reason tools like Nudge exist—to provide additional pressure for users to install software updates and comply with policies. This inconsistency stems from how macOS processes legacy profiles, not the fault of MDM vendors.

DDM resolves these issues by enforcing policies at the system level, ensuring compliance without relying on repeated server-side pushes. For a concrete example, see how DDM handles Passcode Policies in the next section.

Why DDM Matters

Despite potential limitations, DDM represents the future of Apple device management. It introduces self-enforcing profiles that allow devices to autonomously enforce configurations without constant oversight from MDM servers. It’s a game-changer, but to fully realize its potential, Mac Admins need to understand what is available in DDM profiles, how to create, deploy, and verify DDM profiles in their environments. Finally, we need to ask our MDM providers to fully implement all available keys for profiles, lower the guardrails or provide a way to ship our own JSON.

Let’s prepare for the future of device management. Let’s dive in.

The Building Blocks of DDM: Configuration Profiles

At the heart of Declarative Device Management (DDM) are configuration profiles—the building blocks that describe the desired state of a device. Unlike legacy .mobileconfig profiles, which are written in XML plist format, DDM profiles use the JSON format. This shift to JSON aligns with modern data standards, making DDM profiles more versatile and easier to integrate into existing workflows.

Key Differences Between Legacy and DDM Profiles

Legacy profiles follow a static model: they define settings and rely on the MDM server to enforce those settings on devices. If something changes, the server needs to push the updated configuration again. DDM profiles, on the other hand, take a declarative approach:

• Self-Enforcing: Devices enforce their own configurations locally, reducing reliance on the server and network availability.
• Dynamic Updates: DDM profiles allow devices to dynamically adjust to changes and report their compliance status back to the server.
• Lightweight JSON Format: While legacy profiles are written in XML, DDM profiles use JSON, making them more compact and modern.

For developers and admins, Apple provides several helpful resources to explore these profiles:

• Apple’s DDM overview
• Reference documentation for DDM declarations
• Apple’s GitHub repo of YAML declarations

Passcode Policies: Legacy vs. DDM

Passcode policies provide a great example of the difference between legacy and Declarative Device Management (DDM) profiles.

Legacy Passcode Profiles

In the legacy model, passcode enforcement relies on the MDM server to push settings to devices via .mobileconfig files. However, enforcement is inconsistent—users can simply dismiss passcode prompts, leaving devices non-compliant. This limitation stems from how macOS processes legacy profiles, not from MDM vendors.

DDM Passcode Profiles

With DDM, passcode settings are enforced at the system level, ensuring compliance. Devices autonomously apply the required configurations and report their status back to the MDM. Key settings in DDM include:

• RequirePasscode: Requires users to set up a passcode on their device.
• RequireComplexPasscode: Enforces complex passcodes that avoid repetitive or sequential characters (e.g., “123” or “ABC”) and require at least one non-alphanumeric character.
• MinimumLength: Specifies the minimum number of characters in the passcode.
• MaximumFailedAttempts: Limits the number of failed login attempts before the device locks.
• MaximumGracePeriodInMinutes: Controls how long users can wait before the device locks after waking.
• MaximumInactivityInMinutes: Locks the device after a period of inactivity.

For example, enabling RequireComplexPasscode eliminates the need for admins to define complex regular expressions for passcode validation. This built-in enforcement saves time and ensures compliance across devices.

Here’s a sample JSON configuration for a DDM passcode policy with common settings:

{
   "Type": "com.apple.configuration.passcode.settings",
   "Identifier": "com.example.config.passcode.settings",
   "Payload": {
      "RequireComplexPasscode": true,
      "MinimumLength": 10,
      "MinimumComplexCharacters": 1,
      "MaximumFailedAttempts": 11,
      "MaximumGracePeriodInMinutes": 1,
      "MaximumInactivityInMinutes": 15
   }
}

Once deployed, this configuration ensures that users must comply with the passcode policy during login or when creating or updating their password. For example, Apple’s Passcode Declarative Configuration specifies that users have 60 minutes to set a passcode before being forced to comply.

Settings like RequireComplexPasscode help enforce stricter security policies directly within macOS, iOS, and iPadOS, reducing the need for third-party solutions. However, full implementation of these keys depends on your MDM provider. If certain keys are missing, reach out to your provider to advocate for full DDM support.

By leveraging DDM for passcode policies, admins can eliminate the gaps in enforcement common with legacy profiles, ensuring greater consistency and security across their managed devices.

Available Profiles in DDM

Apple’s declaration reference documentation and GitHub repo outline the available configuration profiles for DDM. These profiles are organized into logical categories, making it easier for admins to identify and implement the ones they need.

Account Configurations

Manage user accounts for email, calendar, contacts, and more: AccountCalDAV, AccountCardDAV, AccountExchange, AccountGoogle, AccountLDAP, AccountMail, AccountSubscribedCalendar.
Example: Automatically set up corporate Exchange accounts or Google accounts for secure and seamless employee access to email and calendars.

Settings Configurations

Define system behaviors and settings: AppManaged, DiskManagementSettings, MathSettings, PasscodeSettings, SafariExtensionSettings, ScreenSharingConnection, SoftwareUpdateSettings.
Example: Enforce passcode complexity requirements or configure software updates to ensure device compliance with organizational policies.

Credential Configurations

Manage identities, certificates, and authentication: AssetCredentialACME, AssetCredentialCertificate, AssetCredentialIdentity, AssetCredentialSCEP, AssetCredentialUserNameAndPassword.
Example: Dynamically issue SCEP certificates for secure Wi-Fi or VPN access without manual intervention.

Security Configurations

Enhance device security and protect user data: SecurityCertificate, SecurityIdentity, SecurityPasskeyAttestation, ManagementStatusSubscriptions.
Example: Deploy certificates for encrypted email or enable WebAuthn enterprise attestation for secure authentication.

Service Configurations

Manage background services and configuration files: ServicesBackgroundTasks, ServicesConfigurationFiles.
Example: Optimize app updates or manage custom enterprise application configurations.

Activation and Deployment Configurations

Streamline activation and deployment workflows: ActivationSimple.
Example: Bundle multiple configurations like passcodes, software updates, and account setups for efficient deployment to new devices.

Test and Legacy Configurations

Test DDM functionality or use legacy configurations temporarily: ManagementTest, LegacyProfile.
Example: Validate DDM profiles before rolling out or rely on legacy profiles during the transition to DDM.

Assets and User Credentials

Manage reusable assets and credentials: AssetData, AssetUserIdentity, UserNameAndPasswordCredential.
Example: Distribute username/password credentials for VPNs securely while reducing the need for manual user input.

Why DDM Profiles Matter

DDM profiles offer Mac Admins a new level of flexibility and reliability, improving compliance, security, and automation. Each profile serves as a building block for tailoring devices to meet organizational needs. As Apple continues expanding the number of supported configurations, the potential for declarative management will only grow.

Creating DDM Configuration Profiles

Creating Declarative Device Management (DDM) configuration profiles involves working directly with JSON files generated from YAML declarations. Unlike legacy profiles, where tools like Configurator2 or iMazing Profile Editor allowed Mac Admins to create profiles via user-friendly interfaces, there currently isn’t an equivalent for DDM. However, with the right tools and resources, building DDM profiles is still manageable.

Generating DDM Profiles: Tools and Workflow

To generate DDM configuration profiles, we rely on YAML declarations, which Apple provides in their GitHub repository. These YAML files specify the settings available for different types of configurations, such as passcodes, software updates, and VPN requirements. The YAML can then be converted into JSON, the format required by DDM.

Here’s an example workflow for creating DDM profiles:

1. Start with YAML Declarations

   • Visit the Apple GitHub repository to find the YAML for the configuration you want to create.
   • For example, the YAML declaration for passcode settings can be found here.

2. Convert YAML to JSON

   • Use a tool like Jesse Peterson’s ideclr.py to get you started with a JSON payload.
   • For now, we have to manually translate the YAML into JSON if you are familiar with the structure.

For example, the passcode YAML generates the following JSON with all of the available keys:

{
   "Type": "com.apple.configuration.passcode.settings",
   "Identifier": "com.example.config.passcode.settings",
   "Payload": {
      "RequirePasscode": false,
      "RequireAlphanumericPasscode": false,
      "RequireComplexPasscode": false,
      "MinimumLength": 0,
      "MinimumComplexCharacters": 0,
      "MaximumFailedAttempts": 11,
      "FailedAttemptsResetInMinutes": null,
      "MaximumGracePeriodInMinutes": null,
      "MaximumInactivityInMinutes": null,
      "MaximumPasscodeAgeInDays": null,
      "PasscodeReuseLimit": null,
      "ChangeAtNextAuth": false,
      "CustomRegex": {
         "Regex": null,
         "Description": {
            "default": null
         }
      }
   }
}

3. Edit and Customize the JSON

   • Once the JSON is generated, modify it to suit your specific needs. For example:

     • Set "RequirePasscode" to true to enforce passcodes.
     • Adjust "MinimumLength" and "MaximumFailedAttempts" to comply with organizational policies.

   • Save the file with a meaningful name, such as passcode.settings.json, for easy identification.

4. Test with an Open-Source Example

   • Refer to pre-built DDM profiles available in the Mac Admins DDM examples repository. These examples can be used as starting points to create your own configurations.

With your configuration profiles created, the next step is to deploy them effectively to your fleet of devices. In the next section, we’ll cover deployment strategies, common challenges, and how to verify that your profiles are working as intended.

Deploying and Implementing DDM Profiles

Once you’ve created your Declarative Device Management (DDM) profiles, the next step is deploying them to your devices. While the process shares similarities with legacy profiles, DDM introduces new tools and techniques that require admins to adapt. This section covers deployment strategies, verification methods, and tools to ensure your configurations are applied and working as intended.

Deploying DDM Profiles Using Your MDM Provider

Most Mac Admins rely on an MDM provider to manage their fleet of devices, and many providers now support custom JSON profiles. Here’s how you can deploy DDM profiles through your MDM:

1. Upload the Profile
   Log into your MDM provider’s portal, navigate to the section for custom configuration profiles, and upload your JSON file (e.g., passcode.settings.json).
2. Assign Devices
   Assign the profile to a test group of devices to verify its behavior before rolling it out fleet-wide.
3. Monitor Deployment
   Use your MDM’s dashboard to track profile delivery and ensure that the configurations have been pushed to the assigned devices.

Check your MDM provider’s documentation to confirm the extent of their DDM support. Some providers may not fully support all DDM keys or features, so it’s important to verify what’s available.

Alternative Deployment Tools

If your MDM provider doesn’t yet fully support DDM or you want greater control over deployment, there are several open-source tools you can use to manage DDM profiles.

KMFDDM

KMFDDM is an open-source framework for deploying and managing DDM profiles. It’s a lightweight and flexible alternative for admins looking to test or implement DDM without relying on an MDM provider. Use the KMFDDM Quickstar.to get started.

Fleet Device Management

Fleet is a scalable fleet management system that integrates with tools like osquery for compliance monitoring. For admins considering Fleet, there’s a docker setup available to simplify the deployment process.

Zentral

Zentral is another open-source solution that combines device management tools like osquery and Santa for comprehensive security and compliance monitoring. Zentral’s quickstart guide makes setup straightforward.

Verifying Deployment

Verification is a critical step to ensure that DDM profiles have been successfully deployed and are working as expected. Unlike legacy profiles, which could be manually installed and easily viewed in System Settings, DDM profiles often require programmatic verification. Here’s how you can confirm deployment and compliance:

Where to Check Configurations on Devices

1. System Settings:

   • Like legacy profiles, DDM profiles may appear in System Settings under General > Device Management.
   • Passcode policies are enforced when users create or update their password.
   • Software update settings appear in General > Software Update, including the DetailsURL for additional instructions.

2. Programmatic Verification:
   Use tools like mdmclient or osquery to inspect installed profiles and verify compliance programmatically.

Using Tools to Verify Deployment

mdmclient Commands

The mdmclient utility is part of Apple’s Managed Client (MCX) framework and allows you to query device status and configurations. Here are some useful commands:

Query Device Information:
/usr/libexec/mdmclient QueryDeviceInformation

• Retrieves general device information, including enrollment details.

Check Available OS Updates:
/usr/libexec/mdmclient AvailableOSUpdates

• Lists available OS updates based on your DDM configuration.

Inspect Installed Profiles:
/usr/libexec/mdmclient QueryInstalledProfiles

• Lists all installed profiles, including DDM profiles.

Dump Management Status:
/usr/libexec/mdmclient dumpManagementStatus

• Provides a detailed overview of the device’s management state.

Using osquery

osquery is an open-source tool that lets you query device configurations with -like syntax. It’s particularly useful for auditing compliance across your fleet.

Check Passcode Policies:

SELECT * FROM managed_policies WHERE name = "Passcode";

Inspect Software Update Settings:

SELECT * FROM software_update;

Combine osquery with tools like Zentral or Fleet for ongoing compliance monitoring and reporting.

Best Practices for Deployment and Verification

To ensure successful deployment and compliance, follow these best practices:

1. Start with Test Devices:
   Always test DDM profiles on a small group of devices to validate their behavior before rolling them out fleet-wide.
2. Monitor Compliance:
   Use your MDM provider’s dashboard, mdmclient, or osquery to monitor compliance and troubleshoot issues.
3. Communicate with Users:
   Inform users about new policies and configurations, especially if they introduce restrictions (e.g., stricter passcode requirements or forced updates).
4. Advocate for Full DDM Support:
   Work with your MDM provider to ensure they support all DDM keys and configurations. Provide feedback about missing features or guardrails that limit your ability to customize profiles.

With your DDM profiles successfully deployed and verified, you’re well on your way to leveraging declarative management to its fullest potential. In the next section, we’ll explore advanced use cases, including integrating DDM profiles with security frameworks and automating compliance reporting.

DDM is the future of Apple device management, offering Mac Admins more robust and reliable tools for ensuring compliance and security. As Apple expands DDM’s capabilities and MDM providers adopt full support, the flexibility and reliability of declarative management will only improve. By embracing DDM now, Mac Admins can help shape its development and prepare their organizations for the next generation of device management.. Start by exploring available profiles, testing them on your devices, and working with your MDM provider to implement missing features. Let’s work together to build a better future for device management.