Stop someone getting admin with SAP Privileges

Revoking someone's admin rights ends the rights they have now. It doesn't stop them asking SAP Privileges again a minute later. To stop a person or a Mac getting admin, change Privileges' own settings through your MDM, then check the change took.

The short answer

1. For one Mac, give it a copy of your Privileges profile with EnforcePrivileges set to user, and exclude it from the usual one.
2. For who may use Privileges at all, set LimitToUser or LimitToGroup, and make sure people outside the limit aren't admins already: Privileges doesn't time their rights.
3. Scope Privileges and your oversight together, to the same groups, so no Mac has Privileges without something recording what it grants.
4. Check on the Mac that the person is a standard user and Privileges shows it's managed, and in your oversight tool that nothing else made them admin.

Key names are the ones you set in a configuration profile for the corp.sap.privileges preference domain, as SAP's Managing Privileges page documents them. This guide was checked against Privileges 2.6.0.

Why revoking isn't enough

Privileges is self-service: anyone it manages can ask for admin whenever they like, within the limits its profile sets. Removing someone from the admin group, by hand, with a script or from an oversight console, ends that grant only. The next request works as before.

Two other moves look like answers and aren't:

• Removing Privileges from the Mac also removes the timer that would end a grant in progress, so rights held at that moment stay. End them first.
• Unenrolling the Mac from your oversight tool, or revoking its key in Altiward, stops you hearing from it. Privileges carries on granting admin, and nothing is recorded centrally until the Mac reports again.

The three settings

The two limits allow people rather than block them, so they suit "only these people may" better than "everyone except this person". Anyone outside a limit isn't managed by Privileges at all: SAP calls it "expected behavior" that an admin right they hold has no timer (issue #277). Before you add a limit, check nobody outside it is an admin already. Our free Unexpected admins check lists admins outside your permanent list.

Privileges' Dock icon changes when a profile sets any of these three keys, and no other key changes it, so it's a quick sign on the Mac that the profile arrived.

Stop a Mac in Intune

Intune can't exclude a person from a profile that's assigned to devices: Microsoft's assignment guidance says excluding user groups from a device group assignment isn't supported, because Intune doesn't evaluate which devices belong to which users. Work with the person's Mac instead, in a static device group.

1. Make a static device group, such as No self-service admin, in Microsoft Entra ID, and add the Mac. Static, because Microsoft recommends against excluding dynamic device groups where timing matters: a new Mac can get the profile before the group catches up.
2. Copy your Privileges settings into a new macOS policy, the same profile type you use now (a preference file for corp.sap.privileges, or a custom profile), and add the key below. Keep every other key, including Altiward's hook settings if you use Altiward, so the Mac stays configured as before apart from this.
3. Assign the copy to No self-service admin.
4. Exclude No self-service admin from your usual Privileges profile's assignment. Two profiles setting corp.sap.privileges on one Mac conflict, so the Mac must get exactly one.

<key>EnforcePrivileges</key>
<string>user</string>

To let the Mac back, remove it from the group. Intune then removes the copy and applies the usual profile.

Stop a Mac in Jamf Pro

The same pattern works with scope. Put the Mac in a static computer group, add that group to the Exclusions on your usual Privileges profile's scope, and scope a copy of the profile, with EnforcePrivileges set to user, to the group alone.

Scope Privileges with your oversight

Assign the Privileges app, its settings and its system extension profile to exactly the groups that get your oversight tool, and to none wider. A Mac with Privileges but no oversight lets people become admins with nothing recorded off the Mac. In Intune, if you use Altiward's Push-AltiwardProfiles.ps1, it assigns Altiward's profiles to one group: add the Privileges app and its profiles to the same group yourself. The Intune guide covers deploying both.

Keep the stopped Mac in that scope. It still has Privileges installed, and you want to keep hearing from it.

Check it took

On the Mac, check the person is no longer in the admin group. This prints yes or no:

dseditgroup -o checkmember -m <short name> admin

Then ask for admin in Privileges as that person: it shouldn't grant it. Check your break-glass account and your MDM's managed admin account are still admins, on a pilot Mac before you rely on it.

From outside the Mac, an oversight tool shows whether the change holds. Altiward's agent reads the Mac's admin group: Admins now stops listing the person, and if anything else makes them admin later, such as a script or a second admin account, it's reported as an admin nobody granted. The agent's health readings include the EnforcePrivileges value the Mac's profile sets, so your SIEM records when the setting arrived. Altiward records and reports; the stopping is done by Privileges and your MDM.

Sources

• SAP, Managing Privileges, Privileges wiki: EnforcePrivileges, LimitToUser, LimitToGroup and the Dock icon
• SAP, Privileges 2.6.0 release notes, and GitHub issue #277
• Microsoft, Assign device profiles in Microsoft Intune, group exclusion support matrix
• Jamf, Scope, Jamf Pro documentation
• Altiward, install guide, Deploy the agent