“unsetpassword” alternatives

Recently, prolific Mac admin documentation writer Rich Trouton blogged about a new tool available in Yosemite: unsetpassword. It’s a tool with a rather specific purpose: to clear the password for a local admin user account and set it to require a new password.

Rich’s post is here.

Rich’s suggested use-case for this tool is this: you create a local account for a user on a new machine. Instead of then handing the machine over with a password you now know (and the user may not change) or with an empty password (that the user may not replace with a better one), instead, you run unsetpassword before returning the machine to the user. The user now logs in with a blank password and is immediately prompted to change it.

You actually have to run sudo unsetpassword while logged into the account. This limits its functionality to admin accounts — you can’t use this tool to unset the account password if you’ve set up a standard account for a user. It’s pretty common to provide standard accounts — that is, accounts without admin rights — to users in many organizations, so this is a significant limitation.

The tool also leaves the login.keychain and Local Items keychains in place, but does not reset their passwords, leading to an almost certainly confusing prompt when the user logs in after the password is unset.

unsetpassword also forces a shutdown after running. This doesn’t seem strictly needed. Certainly a logout is needed, but it seems annoying to have to go through a restart cycle.

Finally, this tool is available only on Yosemite. If you are still supporting and even deploying machines running older versions of OS X, you can’t use it. But there is good news. You can accomplish the same basic task (“unsetting” a local user account password) with other tools that exist in Yosemite and older versions of OS X.

Here are the commands:

sudo dscl . passwd /Users/username ""
sudo pwpolicy -u username -setpolicy "newPasswordRequired=1"

Where “username” is the short username of the user for whom you wish to “unset” their password.

The dscl command sets the user’s password to an empty string.
The pwpolicy command marks the account as requiring a new password.

If the user account is an admin account capable of running commands with sudo, you can run these commands while logged in as that account. You should then immediately log out. (Shutting down as the unsetpassword command does isn’t required.)

If you have a different admin account available (either locally or via directory services), or you can SSH in as root, you can run these commands for a non-admin user account.

We can also eliminate the keychain prompts. Since the intention here is a new account setup, there shouldn’t be anything of value stored in the login keychain, so we could just delete the login.keychain and Local Items keychains. When the user logs back in, these keychains will be recreated without prompting the user.

sudo rm -r ~username/Library/Keychains/*

As always, you should test these commands on some test accounts to get a feel for how they work. While the unsetpassword command is much easier to remember, the techniques presented here are more flexible and usable in more contexts.

“unsetpassword” alternatives

Configuration Profiles and Identity payloads

In today’s MacTech deployment lab, the subject of using Identity payloads in configuration profiles came up.

Here: https://raw.githubusercontent.com/gregneagle/profiles/master/Identity_payload_demo.mobileconfig is a sample/demo configuration profile that contains both an Identity payload and an Email configuration payload.

When installed (by double-clicking the profile, after the normal warnings, the user is presented with a form for entering identification information:

Profiles identity

After entering the requested information and clicking Continue, Mail.app gets a new Gmail account added with the information you entered.

Configuration Profiles and Identity payloads

MacTech Conference 2014: What’s New with Munki?

Here are links from my MacTech Conference 2014 presentation: “What’s New with Munki?”.

Munki itself:

GUI tools:

Web interfaces/Web reporting consoles:

Alternate Munki servers:

Update management:

Miscellaneous tools and add-ons:

Managed Software Center help page link:

Munki 2 documentation:

Munki discussion group:

Munki demonstration setup:

Removing Munki:

MacTech Conference 2014: What’s New with Munki?

You Oughta Check Out AutoPkg: Links

If you attended my presentation on AutoPkg today, thanks! Here are the links:





AutoPkg recipe repos:




AbsoluteManage Processor:


AutoPkg Change Notifications script:


MacSysAdmin 2013 session:


Steve Yuroff’s AutoPkg and Jenkins notes:


AutoPkg Wiki:


You Oughta Check Out AutoPkg: Links

Preventing users from disabling FileVault 2

FileVaultI’ve seen a few online questions about how to prevent users from turning off FileVault 2.

The first line of defense, of course, is to not give admin rights to those users. As of Mavericks, however, there is an additional tool — you can use a configuration profile to prevent turning off FileVault (or at least disable the controls in the Security and Privacy preference pane — very clever users with admin rights might still able to turn it off using Disk Utility or the command-line diskutil tool).

Here is a configuration profile that disables the “Turn off FileVault” button in the FileVault tab of the Security and Privacy preference pane.

Since admin users can also remove configuration profiles, you should probably also lock this profile, requiring a password to remove it. That’s an exercise left for the reader, but here’s a starting point…

Add something like this to the PayloadContent array:

    <string>Configures Configuration Profile security</string>
    <string>Profile Security</string>
Preventing users from disabling FileVault 2

OS X Beta Seed Program


I’ve always advocated that Mac admins join the Mac Developer Program in order to get early access to OS X builds for testing and deployment planning.

I still think that’s a good idea. But if for whatever reason you can’t, Apple has a new program of interest:

OS X Beta Seed Program

I think it’s unlikely this will get you access to early builds of 10.10 (or whatever it’s numbered), but you can test 10.9.3…

OS X Beta Seed Program


If you’ve been using InstaDMG to create compiled modular deployment images, you may find it takes some work to get it to work with Mavericks.

Might I suggest a look at AutoDMG?

Works great to build Mountain Lion and Mavericks modular images; comes with a GUI(!) but usable from the command-line as well if you want to automate it!

Congratulations to MagerValp (Per Olofsson) on an excellent tool. It’s still in early development, but is shaping up very quickly.