The reference for Apple system administrators

CREATE YOUR OWN COMPLIANCE RULES: CUSTOM COMPLIANCE POLICIES

Author

Published

Tags

Category

,

You may be using various tools to check whether the devices you manage are compliant with your corporate policies. Microsoft offers the Compliance Policy feature built into Intune. With a Compliance Policy definition, you can check whether the SIP of the Macs you manage is off, whether the operating system is up to date, that the Gatekeeper settings have been made, and even FileVault encryption. As a result of this, you can mark devices as Compliant or Non-Compliant.

If you haven’t read it before, you can take a look at our article Using Compliance Policy for macOS in Microsoft Intune, where we addressed the use of Compliance Policy in Intune.

Among the Compliance Policy options in Intune, it’s also possible for you to apply some enforcements for devices marked as Non-Compliant. Like informing the user and the IT team, retiring the device, etc.

But instead of applying these kinds of enforcements, organizations just check that a device is Compliant. And they can use this information for the control of other rules. For example, to give network access with NAC solutions, they can include a device being managed with Intune + the device being Compliant in their rule sets. When this is the case, they can ensure that Non-Compliant devices don’t have corporate network access.

A device being Compliant or not may actually be enough for you. But you may still want to check more than what Intune offers you as a Compliance Policy and to take some actions for this.

In its current form, Intune‘s built-in Compliance Policies check the following:

Require system integrity protection: whether System Integrity Protection is on or off

Minimum OS version: the lowest macOS version that can be used

Maximum OS version: the highest macOS version that can be used

Minimum OS build version: the lowest macOS build version that can be used

Maximum OS build version: the highest macOS build version that can be used

Require a password to unlock devices: whether there is a password or not

Simple passwords: whether simple passwords are accepted or not

Minimum password length: minimum password length

Password type: password type (alphanumeric or only numbers)

Number of non-alphanumeric characters in password: the number of special characters in the password

Maximum minutes of inactivity before password is required: the information on after how many minutes of inactivity the device will start asking for a password

Password expiration (days): password validity period

Number of previous passwords to prevent reuse: the number of most recent passwords that will be accepted

Require encryption of data storage on device: whether FileVault is on or off

Firewall: whether the Firewall on the device is on or off

Incoming connections: whether incoming connection requests with the Firewall on the device are on or off

Stealth Mode: whether stealth mode in the Firewall on the device is on or off

Allow apps downloaded from these locations: the Gatekeeper setting — that is, what the preference is regarding which sources applications can be installed from

Those listed above may of course be enough for many uses. But you may want to use a rule outside this list too for marking the device as Compliant. In this case, the use of Custom Compliance Policy will help you. The use of Custom Compliance Policy that was previously available in Intune for the Windows and Linux side has, as of this past July 2026, been opened for macOS too.

Every detail that’s in the rule set of CIS or NIST but isn’t among Intune‘s built-in Compliance Policies can be a part of a Custom Compliance Policy. SSH access being on, the control of whether a specific certificate is on the device, the control of whether any software — for example AnyDesk — is installed on the device, free disk capacity… You name it.

How Is Custom Compliance Policy Used?

To be able to use Custom Compliance Policies, you need two components. A Script and a JSON document.

1. Discovery Script: You should use the Discovery Script to be able to learn the status on the devices you manage for the rules you determine.

2. Compliance Rules: After learning the status on the devices, to be able to compare it with the values it should be, you should upload this rule set as a JSON document into the Custom Compliance Policy.

You can examine an example Discovery Script below. This .sh document pulls the information on whether SSH access on the device is on, whether the Screen Sharing service is on, whether the Guest Account is enabled, whether the Automatic Login option is active, whether the Firewall Stealth mode is on, and how many days the device has been up. You can also do a test by copying the script below.

To be able to use your Discovery Script, you should first upload it to Intune. But you need to do this upload job again from the Scripts tab in the Compliance Policy area. Don’t accidentally go to the Devices / macOS / Scripts section.

After uploading your Discovery Script, you need to upload your JSON document containing your rule set. You can do this directly from the Custom Compliance Policy editing screen. You can examine an example JSON document that will match the Discovery Script above below.

After uploading your Discovery Script and Rules JSON documents, you’ll see a screen like the one below. As you’ll understand from here too, our JSON document dictates that SSH, Screen Sharing, Guest user access, and the Auto login feature be off; that the Firewall Stealth mode be on; and that the device’s up time be less than 14 days.

So What Happens After Sending?

After you Assign the general Compliance Policy that also includes the Custom side to your users, if there’s a non-compliant point on your devices, the devices will be marked as Non-Compliant.

If you look under the Device Compliance heading on any device’s own detail page, you can see the information on which headings the Compliance Policy you sent passed and which headings it failed. In the screenshot below, the checked device appears as marked non-compliant on the Auto Login, Firewall Stealth Mode, and Full disk encryption headings. Of course, until all the criteria are met, this device will appear as Non-Compliant. After these criteria are met, it will be marked as Compliant again.

Finally, an application example

Microsoft recently published an article that can serve as an example of Custom Compliance Policy use. It addresses using the outputs created within the scope of NIST’s macOS Security Compliance Project as a Custom Compliance Policy. You can read the article, which uses the CIS Level 1 baseline as an example, at this address.






Settings Blog’a Abone Olun

Yayınlanan her yazı annıda e-posta adresinize gelsin.

Comments

Leave a Reply

Settings Blog'a Abone Olun

Yayınlanan her yazı anında e-posta adresinize gelsin.

Okumaya devam edin