system.login.screensaver

[stutz]

The command we are using to prevent users other than the logged in user to unlock their screen is:

security authorizationdb write system.login.screensaver authenticate-session-user

My question is does anyone know what file is being changed so that we can monitor if the above command gets reverted back to the original state which is the command below:

security authorizationdb write system.login.screensaver authenticate-admin-or-owner

I've already looked in the authorization.plist in /System/Library/Security but it doesn't look like that controls this command.

[mm2270]

There is a built in Extension Attribute to capture this state. If you go into the Extension Attribute section, choose "New from template" and then look under the Security Reporting section for "OS - Only Logged In User Can Unlock Screensaver" I believe that one is still valid, although its possible it needs some adjustment. Many of the EA template scripts were written a long time ago based on an older OS.

[stutz]

Thanks for the info. Now just need to figure out what replaces PlistBuddy and the file that is being modified to report on if "authenticate-session-user" is changed.

[rtrouton]

Here's a post on how to work with the authorization database in 10.9.x and later:

https://derflounder.wordpress.com/2014/02/16/managing-the-authorization-database-in-os-x-mavericks/

[gachowski]

Does anybody still know if this is still relevant? I think with X.9 or one of the later builds of X.9 you couldn't log in with a different set of credentials and with FileVault encrypted machines your only choice is the logged in user..

C

[stutz]

Yeah its still relevant. I tested it on 10.6-10.11 machines (without FileVault enabled) with a local and domain admin account. On the lock screen just press Option+Return.

Thanks Rich for the info.

[gachowski]

Oh it might be the domain admin options, we don't set that on our machines.. I just tested on X.9.2 with two local accounts and Option+Return didn't work...

Thanks for following up !!! : )

C

[bvrooman]

This is slightly concerning. Our machines, all on the same 10.10.5 image, fall into two categories:
1. Option-return never allows administrators to unlock other users' screens
2. Option-return always allows administrators to unlock other users' screens

At this point, I can't find any system.login.screensaver value which actually modifies the behavior of the screen saver lock. Has anyone else had any luck?

[thoule]

This command shows up current settings for the screensaver.

bash-3.2# security authorizationdb read system.login.screensaver
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>class</key>
    <string>rule</string>
    <key>comment</key>
    <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string>
    <key>created</key>
    <real>465854155.273202</real>
    <key>modified</key>
    <real>465854155.273202</real>
    <key>rule</key>
    <array>
        <string>use-login-window-ui</string>
    </array>
    <key>version</key>
    <integer>1</integer>
</dict>
</plist>
YES (0)

You can see it points to a rule called 'use-login-window-ui'.

bash-3.2# security authorizationdb read use-login-window-ui
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>allow-root</key>
    <false/>
    <key>authenticate-user</key>
    <true/>
    <key>class</key>
    <string>user</string>
    <key>comment</key>
    <string>Authenticate either as the owner or as an administrator.</string>
    <key>created</key>
    <real>465854155.273202</real>
    <key>group</key>
    <string>admin</string>
    <key>modified</key>
    <real>465854155.273202</real>
    <key>session-owner</key>
    <true/>
    <key>shared</key>
    <false/>
    <key>timeout</key>
    <integer>2147483647</integer>
    <key>tries</key>
    <integer>10000</integer>
    <key>version</key>
    <integer>0</integer>
</dict>
</plist>
YES (0)

My interpretation there is that either Admin group, or Session-Owner are authenticated. I haven't figured out the function of the 'shared' key. To modify these settings, like Rich says, send the output to a file, edit it, then < it back in.

The functionality of the screen-saver unlock is Admins can unlock Standard users, but not other Admins, using option-return. Pam.d does authentication in there. (/etc/pam.d/screensaver Passing authentication off to OpenD which uses the security info above, I believe). The last line in that file denies admins access to other admins. Commenting or removing that line allows local admins to unlock the screensaver for other admins.

[stutz]

If you need to reverse this command after you already set it because the username and password box will still appear. The following three files within "/private/var/db" folder need deleted to go back to just seeing the user icon and password box.

auth.db
auth.db-shm (not sure you need to delete this one but I did anyways)
auth.db-wal

Then reboot.

Just an FYI...you cannot use AppleWatch to unlock the screen if the username and password box is present on the lock screen:

[ewinterbourne]

Does anybody still know if this is still relevant? I think with X.9 or one of the later builds of X.9 you couldn't log in with a different set of credentials and with FileVault encrypted machines your only choice is the logged in user..

@gachowski I think you are correct.

With system.login.screensaver set to use-login-window-ui on a MBP Touch Bar and FV2 I found it to fail touchid logon authentication and would launch the screensaver after 30 seconds on macOS 10.13 (although it appeared to work fine on 10.12)

[Thee_Doughboy]

Thank you @stutz that was the issue with our setup.