This module handles login accounts on the system. It has two classes that can be included. These are generally included high in the toplevel hierarchy.

Classes

All of these classes can be required. However, the user creation occurs in the users stage, and this is generally the part that is needed.

users::global

This sets up some global (/etc) defaults for user configuration, e.g. PATH.

users::root

This sets up the root user (or, on Windows, Administrator). This provides the following easy-to-use variables, per bug 776641:

• $users::root::username
• $users::root::group
• $users::root::home

users::builder

Installs the builder user (cltbld for releng, although this can be adjusted in manifests/settings.pp). This provides the following easy-to-use variables, per bug 776641:

• $users::root::username
• $users::root::group
• $users::root::home

This class also sets up the builder user's dotfiles appropriately, including SSH configuration, and performs some basic cleanup.

users::builder::autologin

If included, this class will arrange for the builder user to automatically login to a GUI sesssion at boot.

Secrets

See ReleaseEngineering/PuppetAgain/Secrets for info on how secrets are managed in PuppetAgain.

Each role user has a set of representations of its password, for different uses. The users are "root", "signer", and "builder", and the uses are below. For both "signer" and "builder" users, the name of the secret joins the two with an underscore, e.g., "builder_pw_paddedsha1".

*_pw_cleartext

the cleartext version of the password (ah, Windows..)

*_pw_hash

linux md5 password hash for the root password (No Default) (where to find)

*_pw_pbkdf2

Mac OS X 10.8 entropy for the root password (No Default) (where to find) *CHANGE AT THE SAME TIME AS builder_pw_kcpassword_base64!*

*_pw_pbkdf2_salt

Mac OS X 10.8 salt for the root password (No Default) (where to find) *CHANGE AT THE SAME TIME AS builder_pw_kcpassword_base64!*

*_pw_pbkdf2_iterations

Mac OS X 10.8 iterations for the root password (No Default) (where to find) *CHANGE AT THE SAME TIME AS builder_pw_kcpassword_base64!*

*_pw_paddedsha1 -----no longer needed as OS X 10.6 was decommissioned (Bug 1378841)

Mac OS X 10.6 password hash(No Default) (where to find) *CHANGE AT THE SAME TIME AS builder_pw_kcpassword_base64!*

*_pw_saltedsha512

Mac OS X 10.7 password hash(No Default) (where to find) *CHANGE AT THE SAME TIME AS builder_pw_kcpassword_base64!*

As for the "root" user, the name of the secret will be formed in a similar manner but then adding a "!<security-level>" combination at the end, e.g. "root_pw_paddedsha1!medium-security". Since there are four different security levels used ("low", "medium", "high" and "maximum"), there will also be four possible root password values. The right value for each node will be chosen based on their corresponding aspects.

Additionally, on OS X there's another version of the password required:

*_pw_kcpassword_base64

kcpassword-obfuscated cleartext of the builder user's password, for autologin on Darwin (No Default) (where to find) *CHANGE AT THE SAME TIME AS ALL OTHER OS X PASSWORDS!*

And for Linux, where the VNC password is different from the account password:

*_pw_vnc_cleartext

cleartext version of the password that should appear in ~/.vnc/passwd on Linux

Implementation

Windows

Windows passwords are set in cleartext: *_pw_cleartext.

The VNC password is hashed for UltraVNC, and named *_pw_vnc_ultravnc.

Linux

Puppet supports user management on Linux with no difficulty, via the user provider. Password hashes are most easily created by using 'passwd' on a temporary host, then copying the password hash from /etc/shadow.

The linux VNC password is managed in cleartext (but in such a way that it's not exposed to the user).

Darwin

On Mac OS X, user management is much more complex, and works differently on different versions.

Warning: The builder_pw_kcpassword_base64 secret *must* be changed at the same time as the other builder_pw_* secrets, as it is used to support automatic login

10.6 (Snow Leopard) -not needed anymore

In snow leopard, a "paddedsha1" is stored in /var/db/shadow/hash/$UID. You can find the user's UID with

 sudo defaults read /var/db/dslocal/nodes/Default/users/$username

Copy all of the 0's into the password.

10.7 (Lion)

Authentication on Lion requires a single salted sha512 password. You can generate such hashes with setup/lion-password-hash.rb, which prompts for a password and outputs the hash. Stick that into the *_pw_saltedsha512 secrets, and you're good to go.

10.8 (Mountain Lion)

NOTE: no released version of Puppet supported setting passwords on Mountain Lion when we deployed it. PuppetAgain includes a darwinuser type and a CustomDirectoryService provider for that type, both based on the work of Gary Larizza in #12833. What is eventually available in Puppet proper should closely resemble this implementation.

Authentication on Mountain Lion takes place based on three pieces of information: iterations, salt, and password (called 'entropy' by OS X). You can get this information for an existing user with setup/mtnlion-user-info.rb:

 sudo ruby mtnlion-user-info.rb %user%

and then add it to the secrets for your installation.

If you want to retrieve the information for the root account, you may have to enable the root user first.

10.9 (Mavericks)

Seems to be the same as Mountain Lion.

10.10 (Yosemite)

Seems to be the same as Mountain Lion.

Automatic Login

Automatic login on OS X is controlled in two places:

• /Library/Preferences/com.apple.loginwindow key autoLoginUser sets the username to be used to log in
• /etc/kcpassword contains a lightly obfuscated cleartext password for that user.

There's a handy implementation of the obfuscation algorithm at http://www.brock-family.org/gavin/perl/kcpassword.html, but the easier solution is just to set up automatic login through the GUI, and then copy the file.

Note that kcpassword is binary data. It is given in binhex in secrets.csv. The easiest way to get its contents is:

talos-mtnlion-r5-082:~ root# base64 < /etc/kcpassword

Note that for the moment after this change machines need a first reboot(more details in Bug 1376807)