Creating New Users

[Ref: BSD Certification | User Administration | FAQ 10

Table of Contents
  1. Planning
    • Types of Users
    • Host Access Policy
    • SSH Public Keys
    • Shell
    • Password Policy
      1. Installation Password
      2. User Passwords
  2. Configure SUDO privileges
  3. Audit

If you are new to managing user accounts on OpenBSD, please refer to the above two resources. The BSD Certification, are a very solid grounding in the theory and practise of user administration. Refer FAQ 10 for explicit review of available command-line tools.

These notes discuss general 'principals' we currently practise for creating user accounts, more specifics are in the above two posts. Fortunately, computers lend themselves to automation, get the details specified and much of the mundane work can be performed through scripting.

Planning

Maximising good construction of your users, works best with a lot of forethought about how your users are created and maintained.

If this is your first 10 hosts, then you may take these with a grain of salt.

Types of Users.

We generally have three types of users, which simplifies our
'standard' configuration.

  • Administrators (members of the wheel group)
  • Regular users (not members of the wheel group)
  • Authpf user accounts (no shell)

With the above classification of users, we can specify group-level privileges, enforced through either "group" allocation, and/or "Login Class" (c.f. login.conf)

In our context, we use login-class to set user resource limits, and user-groups are maintained manually.

Host Access Policy.

What is your policy for access to the host.

We only support host access through SSH Public Key Infrastructure which simplifies account creation, because we generate random passwords. We thus require ssh public keys in our account creation process.

SSH public keys

Maintain a validated set of SSH Public Keys. These need to be secured.

Install public keys for all accounts, by:

  • copying users' public keys to the 'new' host, and
  • copy the public keys to their relevant user account.

Shell

Some people prefer bash, other zsh, others choose-m.

As we're a small group, and the 'corporate' hosts are border systems, we've standardised all user shells on the OpenBSD default ksh (again minimise unnecessary variance.)

Selecting a different shell, implies adding that shell to the list of applications to monitor for vulnerability announcements.

Password Generation

What is your policy for passwords?

  • Installation Password
  • User Passwords
Installation Password

We use a known password for the 'root' account during installation. The password was generated by a random process (but with not such a long string.) That password is only valid until we confirm admins have ssh key access to the boxes, and sudo has been configured correctly. At this point, well before deployment, ssh root access is disabled and sshd restarted.

User Passwords

[Ref: spew.pl ]

During account creation, we always generated random passwords. Fortunately, our host access policy is secured physical access and mandatory use of SSH Keys, so there is no need for retaining the password or securing their transfer to users.

spew.pl is a perl script using OpenBSD's /dev/urandom for generating random passwords. The rationale for spew.pl is not to define what is a secure password generator, but an adequate tool using OpenBSD's base services (i.e. perl and /dev/urandom)

Summary

A summary of some of the outcomes from going through the above steps:

  1. Administrator Accounts
    • Users: samt, ...
    • Group: usergroup, wheel
    • Login Class: staff
    • Shell: /bin/ksh
  2. Regular Accounts
    • Users: _monitor
    • Group: usergroup
    • Login Class: default
    • Shell: /bin/ksh
  3. authpf Accounts
    • Users: samt_authpf
    • Group: usergroup
    • Login Class: authpf
    • Shell: /usr/bin/authpf
  4. Audit

Where usergroup is the user's private group (we choose to follow old conventions of assigning a usergroup with the same name as the user-account.)

Configure SUDO Privileges

Depending on policy, set the /etc/sudoers configuration appropriately.

Refer sudo(8) and sudoers.html for further assistance.

Audit

You may need to perform regular audits of your user account configuration, or it may just be sane to make a cursory review after account creation.

  • /etc/passwd
  • /etc/group
  • /etc/sudoers

The following are some basic auditing for verifying aspects of the user accounts on your OpenBSD system.

/etc/passwd

Are there any other users in /etc/passwd with 'root' (uid:0) or 'wheel' (group-id:0) level priviliges ?

$ sudo grep :0: /etc/passwd

No???! there should only be the below single entry.

root:*:0:0:Charlie &:/root:/bin/ksh
/etc/group

Who are members of the group with 'wheel (group-id:0) privileges.

$ sudo grep ":0:" /etc/group

Verify that I'm the only one with group-id:0 privileges (and anyone else you wish, of course.)

wheel:*:0:root,samt
/etc/sudoers

Who have we given privileges to in the /etc/sudoers file.

$ sudo grep -v "^#" /etc/sudoers  | grep -v "^$" | grep -v "^Defaults"

This is what I have, possibly an insane solution.

root    ALL=(ALL) SETENV: ALL
%wheel  ALL=(ALL) NOPASSWD: SETENV: ALL