“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

Mountain Lion and MCX

In my last post, I asserted that Local MCX still works in Mountain Lion. And it does. But that doesn’t mean there aren’t issues to deal with.

There have been various reports of certain MCX settings not behaving correctly — for example, it appears that currently you can’t use MCX to manage Dock settings “Once” — only “Always” management works. (And that’s not useful for us — it doesn’t allow one to set certain Dock defaults and then leave the Dock alone for the user to modify as they’d like.)

There’s another challenge if you use Local MCX in an alternate local DirectoryService node, as described here:

In Mountain Lion, dscl refuses to write to non-default local nodes:

# sudo dscl /Local/MCX create /Computers/foo
create: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)

This makes manipulating things in a non-default local node much harder than it was in Leopard through Lion.

You can still copy files into /private/var/db/dslocal/nodes/MCX, and that can serve as a workaround for now. All of the packages I use to configure Local MCX do exactly that — they install plist files into /private/var/db/dslocal/nodes/MCX/computergroups. But there is one major exception.

I have one package that does the setup for Local MCX. It makes sure the /Local/MCX node is present, makes sure it is in the search path, and makes sure that an appropriate record exists in /Local/MCX/Computers to represent the current local machine. This requires writing to the /Local/MCX node to dynamically create the computer record. We can’t just install a file, because the contents of the data in the computer record are unique for each computer.

So there’s our problem: we can’t use dscl to create a computer record in the /Local/MCX node, yet we must dynamically create an object in that node.

There are two solutions, both which rely on the fact that all objects in Local DirectoryService nodes are actually just plist files.

The first:  We could use another plist creation tool to create the needed plist. We could use defaults or PlistBuddy, for example. But that would require us to take the time to figure out how to use one of those tools to create a file that is the same as if dscl created it.

The second: Use dscl to create the record in the /Local/Default node. Then just move the plist from /private/var/db/dslocal/nodes/Default/computers/foo.plist to /private/var/db/dslocal/nodes/MCX/computers/

The second approach is the one I decided to take, since it seemed easier.

Here is the script I currently use for initial Local MCX setup. If you are currently using Local MCX on Lion or earlier, I hope it is of some help if you want to continue to use Local MCX on Mountain Lion.

Mountain Lion and MCX

Mountain Lion: suppress Apple ID / iCloud prompt

This question has come up a few times in the past few days, so I thought I’d better document it.

On Mountain Lion, how do I suppress the Setup Assistant that prompts for an Apple ID to setup iCloud?

The answer is to use MCX. You can use Local MCX, network directory-based MCX, or Profiles.

You can read more about Local MCX here. (And yes, Local MCX still works in Mountain Lion.)

# dscl /Search mcxread /ComputerGroups/setupassistant
App domain: com.apple.SetupAssistant
Key: DidSeeCloudSetup
State: once
Value: 1

App domain: com.apple.SetupAssistant
Key: LastSeenCloudProductVersion
State: once
Value: 10.8

Here is a profile that will do the same thing. You can use the command-line profiles tool to install it.

NOTE: for whatever reason, this doesn’t work if the management frequency is set to “Always” or “Forced”. It does work when set “Once”. I have not tested “Often”, but I imagine that would work as well.

Mountain Lion: suppress Apple ID / iCloud prompt

MacTech magazine May 2012

The May 2012 issue of MacTech is available via the iPad app; dead-tree mailings can’t be far behind.

In this month’s issue I detail a method for creating packages to create a local admin account on your managed machines. This same package will create a working local admin account on Leopard through Lion (and possibly beyond), and will work in the stripped-down Lion install environment. If you need to update the local admin password, you can just install a newer version of the exact same package.

This fits in with my general theme for 2012: which is “Don’t Repeat Yourself!”

MacTech magazine May 2012

Yet again with the Local MCX

Earlier this week, I outlined some changes to my Local MCX implementation. I moved all of my computer and computergroup records (that existed solely to hold MCX data) from the Default local DS store at /var/db/dslocal/nodes/Default/ to a newly created node at /var/db/dslocal/nodes/MCX/.

In order to make this new local node do anything useful, you have to add it to the authentication search path. In this post I used Directory Utility to perform this task. That’s great when you’re doing your initial testing, but not terribly useful when to need to roll this change out to hundreds of machines (or more!).
Continue reading “Yet again with the Local MCX”

Yet again with the Local MCX

MCX in non-default local nodes

Based on some ideas in this thread I started experimenting with some changes to my Local MCX setup with the goal of eliminating warnings like these from /var/log/system.log:

Mar 7 10:41:19 allure com.apple.loginwindow[39]: MCXCCacheGraph(local_laptop, dsRecTypeStandard:Computers): Cannot cache because an existing record named "local_laptop" has conflicting attributes and must be deleted before caching.

This is a common warning when managing MCX data in the local directory service and seems to be harmless. Another seemingly related problem in when the OS deletes local_computer type records from the local DS node at startup, which isn’t so harmless, as it stops local MCX settings from being applied.
Continue reading “MCX in non-default local nodes”

MCX in non-default local nodes

Add a user to the admin group via command line 3.0

One of the more visited articles on this site is several years old – this one on adding a user to the local admin group.

I thought I should update that information since it is somewhat out of date. Apple’s preferred and recommended way to add a user to the local admin group is to use dseditgroup, like so:

/usr/sbin/dseditgroup -o edit -a gneagle -t user admin

This -a(dds) “gneagle”, which is an object of -t(ype) “user”, to the group “admin”.

To delete a user from the local admin group:

/usr/sbin/dseditgroup -o edit -d gneagle -t user admin

You can also use dseditgroup on a network directory service if you have admin credentials for the directory server:

dseditgroup -o edit -n /LDAPv3/ldap.company.com -u dsadminusername -p -a gneagle -t user group_on_network_directory

This will prompt you for the dsadminusername’s password interactively. You can include the dsadminuser’s password like so:

dseditgroup -o edit -n /LDAPv3/ldap.company.com -u dsadminusername -P dsadminuserpassword -a gneagle -t user group_on_network_directory

dseditgroup can do many other things, like create and delete groups, add nested groups to an existing group, and check membership of a given user for a given group.

man dseditgroup for more info.

Add a user to the admin group via command line 3.0

Leopard, MobileAccounts, and NFS homes

HomeSyncOn the MacEnterprise maillist, Arjen van Bochoven wrote of problems with automatic HomeSyncs under Leopard with NFS home directories. Manual syncs worked fine, but the automatic background syncs would fail with errors that looked like this:

1:: [228] Peer "network" is unable to sync. (-[SPeer_FS_PHD mountPeerVolume] (Peer-FS-PHD.m:140): "'((homePath))' is nil")
0:: [228] [2009/02/19 10:45:10.640] Peer "network" is unable to sync. Not enough peers will be available to continue syncing.
0:: [228] [2009/02/19 10:45:10.640] Aborting sync of "HomeSync_Mirror".

I saw the exact same problem in my environment. This also affected login and logout syncs. Here’s the (ugly) fix. Continue reading “Leopard, MobileAccounts, and NFS homes”

Leopard, MobileAccounts, and NFS homes

Converting NetInfo accounts to dslocal

If you are doing an in-place upgrade from Tiger to Leopard without using the Apple Leopard Install DVD, you may need a way to convert existing local or mobile accounts from NetInfo to the dslocal store.

Here’s a script that converts local accounts; it requires the nicl binary, which you can copy from any Tiger installation.

For local accounts, it uses nicl to read the account info, and dscl to create a new corresponding account. For mobile accounts, it uses createmobileaccount to recreate the mobile account.


Converting NetInfo accounts to dslocal