sysprefs_screensaver_ask_for_password_delay_enforce not remediated #229

New Issue

michael · 2026-01-19T18:29:44Z

michael commented

2026-01-19 18:29:44 +00:00

Originally created by @marcindulak on GitHub.

Originally assigned to: @robertgendler on GitHub.

Summary

sysprefs_screensaver_ask_for_password_delay_enforce appears not remediated.
I'm using the main branch 06cc0d2614.

Steps to reproduce

On a fresh system, execute the compliance script generated from baseline (e.g. https://github.com/usnistgov/macos_security/blob/main/baselines/cis_lvl2.yaml) which includes this rule,
and apply remediation with "3. Run Commands to remediate non-compliant settings". Then load the com.apple.screensaver.mobileconfig into "System Preferences -> Profiles", enroll the machine into an MDM.
Run the "2. Run New Compliance Scan" again.

Operating System version

sw_vers
# Output:
# ProductName:      macOS
# ProductVersion:   12.5.1
# BuildVersion:     21G83

# Chip: Apple Silicon M1

What is the current bug behavior?

sysprefs_screensaver_ask_for_password_delay_enforce failed (Result: 300, Expected: {integer: 5})

/usr/bin/osascript -l JavaScript << EOS
$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\
.objectForKey('askForPasswordDelay').js
EOS
# Output:
# 300

It actually appears that the 300 seconds (5 minutes) is needed from the screen saver activation until the password lock is in effect, so the above cli appears correct and the below UI incorrect.

It seems like to mobileconfig is not effective, despite the Profiles menu showing the profile is added.

I'm not sure what is going one here, maybe there is another profile that overwrites the value and takes precedence?
Or is this mobileconfig no longer effective?
06cc0d2614/rules/sysprefs/sysprefs_screensaver_ask_for_password_delay_enforce.yaml (L51-L53)

I still need to perform a manual check of the profiles to see if I find duplicates after I get hold of the machine again. If it turns out that a duplicate mobileconfig is the reason, maybe there is a way to add a rule that checks for duplicate settings as part of the compliance script? Choosing some other values than 300 and 5 may also help in understanding what is going on.

What is the expected correct behavior?

sysprefs_screensaver_ask_for_password_delay_enforce passed (Result: 5, Expected: {integer: 5})

Relevant logs and/or screenshots

Output of checks

sysprefs_screensaver_ask_for_password_delay_enforce failed (Result: 300, Expected: {integer: 5})

Possible fixes

Unknown

Originally created by @marcindulak on GitHub. Originally assigned to: @robertgendler on GitHub.  ### Summary sysprefs_screensaver_ask_for_password_delay_enforce appears not remediated. I'm using the main branch https://github.com/usnistgov/macos_security/commit/06cc0d2614da5b6f478b6f1ff45b059bb7c6aa5a. ### Steps to reproduce On a fresh system, execute the compliance script generated from baseline (e.g. https://github.com/usnistgov/macos_security/blob/main/baselines/cis_lvl2.yaml) which includes this rule, and apply remediation with "3. Run Commands to remediate non-compliant settings". Then load the `com.apple.screensaver.mobileconfig` into "System Preferences -> Profiles", enroll the machine into an MDM. Run the "2. Run New Compliance Scan" again. ### Operating System version ``` sw_vers # Output: # ProductName: macOS # ProductVersion: 12.5.1 # BuildVersion: 21G83 ``` ``` # Chip: Apple Silicon M1 ``` ### What is the current *bug* behavior? ``` sysprefs_screensaver_ask_for_password_delay_enforce failed (Result: 300, Expected: {integer: 5}) ``` ``` /usr/bin/osascript -l JavaScript << EOS $.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\ .objectForKey('askForPasswordDelay').js EOS # Output: # 300 ``` It actually appears that the 300 seconds (5 minutes) is needed from the screen saver activation until the password lock is in effect, so the above cli appears correct and the below UI incorrect. It seems like to mobileconfig is not effective, despite the Profiles menu showing the profile is added. ![Screenshot from 2022-08-30 18-27-00](https://user-images.githubusercontent.com/3178318/187490555-21d372c0-658f-4ed1-a9ba-8a1f5b53a7bc.png) I'm not sure what is going one here, maybe there is another profile that overwrites the value and takes precedence? Or is this mobileconfig no longer effective? https://github.com/usnistgov/macos_security/blob/06cc0d2614da5b6f478b6f1ff45b059bb7c6aa5a/rules/sysprefs/sysprefs_screensaver_ask_for_password_delay_enforce.yaml#L51-L53 I still need to perform a manual check of the profiles to see if I find duplicates after I get hold of the machine again. If it turns out that a duplicate mobileconfig is the reason, maybe there is a way to add a rule that checks for duplicate settings as part of the compliance script? Choosing some other values than 300 and 5 may also help in understanding what is going on. ### What is the expected *correct* behavior? ``` sysprefs_screensaver_ask_for_password_delay_enforce passed (Result: 5, Expected: {integer: 5}) ``` ### Relevant logs and/or screenshots ### Output of checks ``` sysprefs_screensaver_ask_for_password_delay_enforce failed (Result: 300, Expected: {integer: 5}) ``` ### Possible fixes Unknown

michael closed this issue

2026-01-19 18:29:44 +00:00

michael commented

2026-01-19 18:29:45 +00:00

@robertgendler commented on GitHub:

This reminds me of our finding with password policy in a sense.

Turns out they can be wrote to com.apple.screensaver and com.apple.mobiledevice.passwordpolicy based off of the screensaver profile has require password key. I wonder if some other profile you're not expecting is doing this. I'm not sure how you could test other than going 1 by 1 and seeing if the value is set to 300.

@robertgendler commented on GitHub: This reminds me of our finding with password policy in a sense. Turns out they can be wrote to com.apple.screensaver and com.apple.mobiledevice.passwordpolicy based off of the screensaver profile has require password key. I wonder if some other profile you're not expecting is doing this. I'm not sure how you could test other than going 1 by 1 and seeing if the value is set to 300.

michael commented

2026-01-19 18:29:45 +00:00

@marcindulak commented on GitHub:

I checked sudo /usr/bin/profiles -P -o stdout | grep askForPasswordDelay and there is only one hit askForPasswordDelay = 5;, but this setting is not enforced. The device is managed additionally by Microsoft Intune, and none of the Intune profiles, inspected visually on the device include any screensaver details. The "System Preferences -> Security & Privacy -> General" has a grayed-out "Require password 5 minutes after sleep or screen saver begins".

Even if I manually remove and add again the com.apple.screensaver.mobileconfig profile containing askForPasswordDelay of 5, it is not enforced, and askForPasswordDelay of 300 seconds continues to be used.

As soon as I "Remove" the device from Intune, the expected askForPasswordDelay of 5 is detected

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

I "Enroll" the device again, and askForPasswordDelay of 300 comes back.

It's worrying that one could have conflicting settings without being warned about them.
I'll close the issue unless there is a way to further debug it. Maybe conflicting profile settings get logged somewhere?

@marcindulak commented on GitHub: I checked `sudo /usr/bin/profiles -P -o stdout | grep askForPasswordDelay` and there is only one hit `askForPasswordDelay = 5;`, but this setting is not enforced. The device is managed additionally by Microsoft Intune, and none of the Intune profiles, inspected visually on the device include any screensaver details. The "System Preferences -> Security & Privacy -> General" has a grayed-out "Require password 5 minutes after sleep or screen saver begins". Even if I manually remove and add again the `com.apple.screensaver.mobileconfig` profile containing askForPasswordDelay of 5, it is not enforced, and askForPasswordDelay of 300 seconds continues to be used. As soon as I "Remove" the device from Intune, the expected askForPasswordDelay of 5 is detected ``` /usr/bin/osascript -l JavaScript << EOS $.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\ .objectForKey('askForPasswordDelay').js EOS 5 ``` I "Enroll" the device again, and askForPasswordDelay of 300 comes back. It's worrying that one could have conflicting settings without being warned about them. I'll close the issue unless there is a way to further debug it. Maybe conflicting profile settings get logged somewhere?

michael commented

2026-01-19 18:29:45 +00:00

@robertgendler commented on GitHub:

This is odd.

bob@PN111128 macos_security % /usr/bin/osascript -l JavaScript << EOS
$.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\
.objectForKey('askForPasswordDelay').js
EOS
5
bob@PN111128 macos_security %

So the only thing I can think of is a conflicting profile installed on your machine. Run sudo /usr/bin/profiles -P -o stdout and search to see if askForPasswordDelay is there multiple times.

@robertgendler commented on GitHub: This is odd. ``` bob@PN111128 macos_security % /usr/bin/osascript -l JavaScript << EOS $.NSUserDefaults.alloc.initWithSuiteName('com.apple.screensaver')\ .objectForKey('askForPasswordDelay').js EOS 5 bob@PN111128 macos_security % ``` So the only thing I can think of is a conflicting profile installed on your machine. Run `sudo /usr/bin/profiles -P -o stdout` and search to see if `askForPasswordDelay` is there multiple times.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: usnistgov/macos_security#229