system_settings_screensaver_password_enforce reports non-compliant on some machines in Tahoe

[jonbrown21]

Summary

Control 11.34 – Enforce Screen Saver Password (system_settings_screensaver_password_enforce) reports non-compliant on macOS Tahoe even when askForPassword is correctly enforced via a classic MDM configuration profile. Below is information from a failing computer with enforcement set correctly and correctly enforced and functional.

The control validates using:

NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')

to read askForPassword.

On affected systems, this returns an empty suite dictionary and evaluates askForPassword as false, even though the managed preferences layer shows askForPassword = 1.

This results in a false-negative compliance failure.

Steps to reproduce

1. Deploy a classic configuration profile targeting preference domain:

com.apple.screensaver

With the following keys:

• askForPassword = true
• askForPasswordDelay = 5
• idleTime = 1200
• moduleName = Tahoe

2. Confirm the profile is installed and applied.

3. Run the following commands and compare results.

---

Managed Preferences Layer (MDM materialization)

ls -l "/Library/Managed Preferences/com.apple.screensaver.plist"
defaults read "/Library/Managed Preferences/com.apple.screensaver.plist" askForPassword

Observed output:

-rw-r--r--  1 root  wheel  331 Feb 17 20:04 /Library/Managed Preferences/com.apple.screensaver.plist
1

---

User Defaults Layer

Non-host domain

defaults read com.apple.screensaver askForPassword 2>/dev/null || echo "Non-host unset"

Observed output:

Non-host unset

ByHost domain

defaults -currentHost read com.apple.screensaver askForPassword 2>/dev/null || echo "ByHost unset"

Observed output:

1

---

Compliance Validation Method (Current Rule Logic)

/usr/bin/osascript -l JavaScript << 'EOS'
ObjC.import('Foundation');
var d=$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver');
var v=d.objectForKey('askForPassword');
console.log("askForPassword_js:", v ? v.js : null);
console.log("suite_dictionary:", JSON.stringify(d.dictionaryRepresentation ? d.dictionaryRepresentation.js : null));
EOS

Observed output:

askForPassword_js: false
suite_dictionary: {}

Operating System version

ProductName: macOS
ProductVersion: 26.3
BuildVersion: 25D125
Platform: macOS Tahoe

Intel or Apple Silicon

Architecture: Apple Silicon

What is the current bug behavior?

Current Bug Behavior

Even when the setting is enforced via MDM and the managed preferences layer shows:

askForPassword = 1

…the compliance validation returns:

askForPassword_js: false
suite_dictionary: {}

Result: the control reports non-compliant despite correct enforcement.

Managed Preferences Layer (MDM materialization)

ls -l "/Library/Managed Preferences/com.apple.screensaver.plist"
defaults read "/Library/Managed Preferences/com.apple.screensaver.plist" askForPassword

Observed output:

-rw-r--r--  1 root  wheel  331 Feb 17 20:04 /Library/Managed Preferences/com.apple.screensaver.plist
1

---

User Defaults Layer

Non-host domain

defaults read com.apple.screensaver askForPassword 2>/dev/null || echo "Non-host unset"

Observed output:

Non-host unset

ByHost domain

defaults -currentHost read com.apple.screensaver askForPassword 2>/dev/null || echo "ByHost unset"

Observed output:

1

What is the expected correct behavior?

When askForPassword is enforced via an MDM configuration profile, the control should evaluate as compliant.

The validation method should correctly resolve the effective managed preference value for com.apple.screensaver on macOS Tahoe.

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)

Output of checks

Compliance Validation Method (Current Rule Logic)

/usr/bin/osascript -l JavaScript << 'EOS'
ObjC.import('Foundation');
var d=$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver');
var v=d.objectForKey('askForPassword');
console.log("askForPassword_js:", v ? v.js : null);
console.log("suite_dictionary:", JSON.stringify(d.dictionaryRepresentation ? d.dictionaryRepresentation.js : null));
EOS

Observed output:

askForPassword_js: false
suite_dictionary: {}

Possible fixes

The current validation logic relies on NSUserDefaults.initWithSuiteName('com.apple.screensaver'), which does not appear to consult the managed preferences domain for this setting on macOS Tahoe, resulting in an empty dictionary and false evaluation.

1. Update the validation logic to consult the managed preferences layer for this control.
2. Adjust the NSUserDefaults resolution logic to correctly resolve host-scoped and managed values.
3. Add fallback logic: if the suite dictionary is empty, validate against the managed preference domain before reporting non-compliance.

[brodjieski]

Hi Jon-
Currently, I am unable to reproduce the behavior as described in the issue on any of my macOS 26 systems. I'm curious if we are doing something a bit different or something else is amiss. Are you seeing the same behavior on macOS 15 systems?

Another thing I'm curious about is the output of this command on a system you are seeing this on:

sudo profiles -P -o stdout | grep askForPassword

Are you able to provide the profile that you are using when you see this behavior?

Thanks!

[jonbrown21]

100% I will get that output later tonight. FWIW its the JAMF Compliance integration with the macOS Compliance Project so trying it out vs the manual approach with their tool or via the native CLI here. Were seeing about a 30% fail rate across a test group of about 10 computers right now just on this very specific enforcement. No DDM etc.. so wasn't sure if this was a true MacOS Security Project issue or a JAMF Implementation issue or just a really strange edge case that we have in our ecosystem. Sit tight.

[jonbrown21]

Result of command:
askForPassword = 1;
askForPasswordDelay = 5;

Control:
system_settings_screensaver_password_enforce

When I run

/usr/bin/osascript -l JavaScript << EOS
$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')
.objectForKey('askForPassword').js
EOS

I get

false

Again it happens on a handful of machines in our ecosystem, it's very odd.

[brodjieski]

This is quite strange... I'm not certain where the disconnect may be? I just tested with Jamf compliance benchmarks and it looked correct.

On a system that is showing false for a result, is it correctly applied in system settings?

[jonbrown21]

Yep looks correct in system settings

[jonbrown21]

Thats kinda why i was wondering if there maybe some fallback logic if this becomes a widespread issue and also why I tested in all the various contexts to try to figure out which preferences this is reading from. This is a DDM capable setting, but if there is a valid managed prefs key it "should" pass in theory. Im prepping for an actual audit so im collecting physical evidence of the failures in case they ask why its failing but I figured I would flag, happy to run any other tests or commands.

[rquigley-sk]

Can confirm we're seeing this behaviour in our environment as well.

[EimisM]

We are seeing this exact issue on our environment. For now I fixed it with a policy that detects this failure and runs:

#!/bin/bash

# Force values where the audit script (running as root) will read them

# 1) System-wide preferences
/usr/bin/defaults write /Library/Preferences/com.apple.screensaver askForPassword -bool true
/usr/bin/defaults write /Library/Preferences/com.apple.screensaver askForPasswordDelay -int 0
/usr/bin/defaults write /Library/Preferences/com.apple.screensaver idleTime -int 900

# 2) Root user preferences (because osascript runs as root inside the audit)
sudo -u root /usr/bin/defaults write /var/root/Library/Preferences/com.apple.screensaver askForPassword -bool true
sudo -u root /usr/bin/defaults write /var/root/Library/Preferences/com.apple.screensaver askForPasswordDelay -int 0
sudo -u root /usr/bin/defaults write /var/root/Library/Preferences/com.apple.screensaver idleTime -int 900

# Reload preference cache
/bin/killall cfprefsd 2>/dev/null || true

exit 0

[peasantman1]

Are u breaking the law?

[rquigley-sk]

@EimisM: Are you finding that the values stick after this? We're finding that our computers are flapping, being compliant one day and non-compliant the next.

[jonbrown21]

@rquigley-sk were seeing the same flapping behavior, and its only happening on a small subset of the machines, very strange. I haven't tried @EimisM script but I did try the commands outlined in the issue and nothing seems to really stick for me.

[rquigley-sk]

@jonbrown21: Doing some testing at the moment but I have suspicions it might be linked to the Jamf Pro Login Window payload monolithic configuration profile where it can set a blank payload for the com.apple.screensaver preference key.

Might be a red herring but will test next week.

[EimisM]

The script did stick. It seems that the compliance check script is checking what settings are set for root because the check script itself is running as root. I have also experienced the flapping before I've set this script up, and it's now gone. Although I only started the migration to Jamf Pro, the number of devices is minimal for now. But it does work for the time being. So this part seems to be the actual fix:

sudo -u root /usr/bin/defaults write /var/root/Library/Preferences/com.apple.screensaver askForPassword -bool true
sudo -u root /usr/bin/defaults write /var/root/Library/Preferences/com.apple.screensaver askForPasswordDelay -int 0
sudo -u root /usr/bin/defaults write /var/root/Library/Preferences/com.apple.screensaver idleTime -int 900

[jmahlman]

If you are using the Jamf UI to set these settings (and simply not setting this one) that's most likely the culprit.

Jamf loves including settings even if you don't set them, they just disable them.

Suggest you download the config you're using with Jamf and inspect it.

You can also run a command to spit out all profile info and see if the config shows up more than once. I don't have the command in me, but I ran into this previously with another config.

[jmahlman]

If you run something like sudo /usr/bin/profiles show -output stdout-xml | grep -i askForPassword, see if you get multiple listings. If you do, that means you may have the setting set in multiple profiles.

You can also just remove the grep and get full output and search.