Harden the macOS login window to require name and password input instead of listing local user accounts
This Automox Worklet™ hardens the macOS login window so it prompts for a username and password instead of listing every local account on the endpoint. The Worklet reads and writes a single boolean preference, SHOWFULLNAME, in the system-scoped /Library/Preferences/com.apple.loginwindow domain. When SHOWFULLNAME is set to true (boolean 1), the macOS LoginWindow process renders Name and Password text fields at the lock screen and on first boot. When the value is false or missing, macOS reverts to the default behavior of displaying every standard user account as a clickable icon, which is the default configuration on most managed Macs.
The Worklet ships as two short bash scripts. The evaluation script runs defaults read /Library/Preferences/com.apple.loginwindow SHOWFULLNAME and exits with code 1 if the returned value is anything other than 1. The remediation script runs defaults write /Library/Preferences/com.apple.loginwindow SHOWFULLNAME -bool true to set the preference and writes the change to disk. No reboot is required; the next time the login window or screen lock is invoked, macOS reads the updated preference and switches to the text-entry layout.
Because the system-level domain is used rather than a per-user domain, the change applies to the login window itself and to every account on the endpoint, including new accounts created after the policy runs. The Worklet is safe on workstations and servers, on Intel and Apple Silicon, and on endpoints bound to directory services such as Active Directory or Jamf-managed JumpCloud, because directory accounts use the same loginwindow preference path as local accounts.
A login window that lists every local account hands an attacker the first half of every credential pair on the endpoint. With a screenshot of the lock screen, an attacker knows which accounts exist, which ones are administrators (the icon and full name often give that away), and which usernames to target with password spraying, phishing, or social engineering. The CIS Benchmark for macOS calls out this exposure directly and requires SHOWFULLNAME to be set to true on every audited Mac. Aligning with the control closes the lowest-effort reconnaissance path on the endpoint and removes a finding that frequently lands in PCI-DSS, HIPAA, and SOC 2 audit reports.
SHOWFULLNAME is one of the easiest values on macOS to lose track of. A user resets their endpoint, an admin reimages a laptop with a stale provisioning profile, or an MDM policy is dropped during a vendor migration, and the system-scoped com.apple.loginwindow plist quietly reverts to the icon-list default. cfprefsd caches the old value in memory until the next login window paint, so a manual check after a profile change can read clean even though the runtime is wrong. The Worklet re-evaluates SHOWFULLNAME against the live plist on every policy run and writes the boolean again the moment it diverges, which catches the drift before it becomes an audit finding or the next lost MacBook becomes a credential disclosure incident.
Evaluation phase: The Worklet runs defaults read /Library/Preferences/com.apple.loginwindow SHOWFULLNAME and captures the returned value. If the value equals 1, the endpoint is compliant and the script exits 0. If the key is missing, set to 0, or returns the literal "does not exist" message, the script prints "Login window is not set to name and password." and exits 1, flagging the endpoint as non-compliant in Automox so remediation is queued.
Remediation phase: The remediation script re-checks SHOWFULLNAME and, if it is not already 1, runs defaults write /Library/Preferences/com.apple.loginwindow SHOWFULLNAME -bool true. The defaults binary writes the boolean to the system-scoped plist, cfprefsd picks up the change, and LoginWindow renders the Name and Password fields the next time the lock screen is invoked. The remediation step is a no-op on endpoints already at boolean 1, so the activity log only shows write events when something has actually drifted.
macOS endpoint running 10.13 (High Sierra) or later, including macOS 14 Sonoma and macOS 15 Sequoia on Intel and Apple Silicon
Root or sudo privileges for the Automox agent so the defaults command can write to /Library/Preferences/ (the default agent context already meets this)
Compatible with WORKSTATION and SERVER device_type values defined in the Worklet metadata
No conflicting MDM configuration profile for com.apple.loginwindow with a different SHOWFULLNAME value; MDM profiles override local defaults writes and will revert the Worklet
FixNow compatible (feature_compatibility includes RunNow), so this Worklet can be triggered ad hoc for incident response, not only on a scheduled policy
Pair with the Disable Show Password Hints Worklet, which sets RetriesUntilHint to 0 in the same /Library/Preferences/com.apple.loginwindow domain, to close two CIS findings with one preference file
After the remediation phase completes, the macOS login screen and the lock screen render two text fields labeled Name and Password instead of the icon grid of local accounts. The system no longer reveals which usernames are valid on the endpoint, and there is no visual cue that distinguishes an administrator from a standard user from a directory account. New accounts created after the policy runs inherit the same behavior, because the preference lives in the system domain, not a per-user domain.
Validate the change from a Terminal session by running defaults read /Library/Preferences/com.apple.loginwindow SHOWFULLNAME and confirming the value is 1. For audit evidence, capture the output of plutil -p /Library/Preferences/com.apple.loginwindow.plist alongside the Automox policy run identifier and the endpoint serial number. Visually verify by locking the screen with Control + Command + Q on the affected endpoint and confirming the Name and Password fields appear. Subsequent Automox evaluations report the endpoint as compliant without re-running remediation, because the evaluation script sees SHOWFULLNAME already set to 1. The setting persists across reboots, macOS minor updates, and FileVault unlock cycles.


Loading...
Consider Worklets your easy button
A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

AUTOMOX + WORKLETS™
Uncover new possibilities with simple, powerful automation.
By submitting this form you agree to our Master Services Agreement and Privacy Policy
By submitting this form you agree to our Master Services Agreement and Privacy Policy.
Already have an account? Log in