Adding User Account(s)

[#usradmpl]: Adding a user: Implementation-specific details
Implementation-specific details for Unix

In Unix, new users might be addable with a command called adduser or useradd or perhaps user. Some operating systems may support multiple of these commands. For any of those commands, a requirement for superuser (“root”) access may be common, so prepare to use sudo if needed. (e.g., run: sudo adduser.) The commands may require command line arguments or may be more interactive so that some or all command line arguements are not required. These commands might work differently on differnet operating systems, so be sure to learn details specific to an operating system before believing that the commands will work similar to another implementation. Another option may be to modify one or more text files, possibly by using vipw, although as OpenBSD FAQ 10.9: Adding/deleting users points out, “this is more difficult for most operations.”

In OpenBSD: Adding a user (including details for a user who is expected to be an Administrator)

The easy way is to use adduser. If this is the first time that adduser is going to be run, then back up the file called /etc/adduser.conf if appropriate. (Or not? Maybe the file doesn't pre-exist?)

If a user and a group is going to be added, it may be a bit faster to create the group first. e.g. “ groupadd -v sshok ” could be used to create a group for specifying who is allowed to use SSH. (Whether a user is in that group or not will not have any impact until something causes there to be an impact, such as a line in /etc/ssh/sshd_config which says “AllowGroups sshok” and which exists when the SSH server is reading that configuration file.)

$ adduser
You are not root!
$ sudo adduser
First time

The first time that a user is added, OpenBSD may ask some questions about what the default values will be when creating new users. These default values may be customized but they also have default values themselves, and those defaults are likely fine. Here is an example output session:

Couldn't find /etc/adduser.conf: creating a new adduser configuration file
Reading /etc/shells
Enter your default shell: bash csh ksh nologin sh [ksh]:
Your default shell is: ksh -> /bin/ksh
Default login class: authpf daemon default staff [default]:
Enter your default HOME partition: [/home]:
Copy dotfiles from: /etc/skel no [/etc/skel]:
Send message from file: /etc/adduser.message no [no]:
Do not send message
Prompt for passwords by default (y/n) [y]:
Default for encryption method for passwords: auto blowfish des md5 old
Use option ``silent'' if you don't want to see all warnings and questions.

pwd_mkdb: warning, unknown root shell
Reading /etc/shells
Check /etc/master.passwd
Check /etc/group

Ok, let's go.
Don't worry about mistakes. There will be a chance later to correct any input.

The attentive user may notice the warning line. If the root shell has been tampered with, that may be a sign of a security breach. That may seem unlikely for a fairly new system, but the severity of the problem, if it does exist, warrants checking this out to understand what is going on. So, if this message is seen, hop on over to another terminal and check this out. See what shell root defaults to, by running:

grep ^root: /etc/passwd

(The carrot is interpreted by grep to represent the start of a new line.)

Perhaps the results look something like this:

root:*:0:0:Charlie &:/root:/sbin/nologin

That looks reasonably secure. (The phrase “Charlie &” equates to “Charlie Root” as described by a manual page for the /etc/passwd file's discussion about an ampersand.)

However, /sbin/nologin is not listed in the /etc/shells file.

Here are some guidelines for creating a user. (This guide should not be considered an absolute requirement: use flexibility to customize when appropriate.)

  • When OpenBSD gets to the point of asking about a username, simply choose the user's (login) username.
  • Then, after the username is asked for, OpenBSD will ask about the user's display name.
  • For the initial question about groups, the login group, the default is going to be to name the group after the user. That default is probably okay.
  • However, the second question about groups may benefit from some customization: The default answer is likely going to be to not invite the user into other groups. That default is NOT desired for a staff member who should be given Administrator access and access to log in. Often, Administrators need to be given access to the group “wheel” and they should also be allowed to be given access to remote access capabilities. If OpenSSH has been set up to require that remote users are in a group called sshok (which is not the default for OpenSSH, but is a sensible setup that improves the basic default security of OpenSSH), then type in two words (without surrounding quotation marks) when the adduser program asks for groups to join:

    wheel sshok

    However, if adduser replies with “Group ``sshok'' does not exist”, realize that means that the system has not (yet) been secured according to the guidelines recommended by ][Cyber Pillar]['s guide to setting up an operating system / guide to making virtual machines : hardening and enabling a remote access program. If the machine is still considered to be tightly secured (not allowing network access to any untrusted machine, perhaps because the machine has always been protected by a firewall which would currently block any remote access traffic), then just add to wheel for the time being. The whole “sshok”-related setup may be handled at a later time (after creating the user which may help get this set up, but note that this should be done before opening up network traffic which would allow remote access to actually work).

  • After choosing the login groups, if the user is going to be an Administrator, then specify that the user has a logon class called staff.

(The following details are written from memory/reading, and may need to be re-verified/checked... With older versions of FreeBSD, some users (especially new administrators of FreeBSD) may enjoy the text mode graphical approach of using sysinstall. However, that software may have been replaced with a newer installer, so further details may need to be investigated. FreeBSD does not seem to have a useradd command (unlike NetBSD or OpenBSD).

Other Unix-like operating systems
Adding a user in Microsoft Windows

A very common way to do this is to have the machine join a network domain (using Active Directory), at which point all domain account become available. If a user account is created, it may then be a domain account. However, even machines on a domain come with at least one local account by default, and may have more added.

To make a domain user, a full/tested guide is not yet available here. However, some information may be available:

[#iosmkusr]: Creating a user in Cisco IOS
Standard Cisco IOS Warning

See: Standard warning about Cisco IOS.

Note: These steps are provided for people who already know the basics of interacting with a router. A technician who doesn't have that experience may wish to start with an introduction to using Cisco IOS. See: Cisco Introduction, Cisco Equipment, Cisco IOS basic usage guide.

Using the CLI

Specifically, details about handling users is mentioned by: Cisco Basic Usage Guide: section about the device's local “user database”. An abbreviated summary is also shown here for convenience, but that referenced location may provide more details.

There may certainly be different types of passwords used with a Csico IOS, and perhaps also user accounts (considering all of the different protocols that a Cisco IOS device may support). This section is about adding a user to a device's “running configuration”, also known as the “local database&Rdquo; of users. This is how to create a user account that lets somebody log into the device and make changes.

Adding a user to the local database

The instructions here are about adding a user to the “running configuration”, which is also called the “local user database”. Other terms are the “local database” (which is a term that is commonly used when referring to users on a Cisco IOS device), or the device's “local configuration”.

username myUser privilege 15 passwordDetails



Specify a custom username.

privilege 15

This is one of the privilege levels. By default, commands are (typically?) level 1 or level 15. Other privilege levels can be made useful (by using something like “ privilege exec level 2 traceroute ”, which would cause traceroute to require a privilege level of at least 2, which can be obtained using “enable 2 ” or whatever other number the user wishes to elevate to.)


e.g.: secret 0 plainTextPassword

Note that the example shown here is just one option. A password hash could be entered, instead of using method 0 which specifies that the password is being provided as plain text. Further details are provided in the Cisco Basic Usage Guide: section about the device's local “user database”.

Making use of the user account

Just because a user account is created doesn't mean that the user account does much. Be sure to remember to do something useful with it. For example, going into the configuration for a line (e.g. “ line vty 0 4 ” or “ line console 0 ”), and then running “ login local ” on a line will result in the local user database being used when someone tries to log into that line..

Note that this approach does not work in all circumstances; it could be ignored if AAA commands specify that a different approach should be used. However, for most basic setups, this ought to work relatively okay.

This simply shows the command, for quick reference. For a more detailed discussion, see: Cisco Basic Usage Guide: section about the device's local “user database”.

Additional options

Users can be automatically logged into using a specific parser view. e.g.:

username customUserName view customParserViewName passwordDetails

for example:

! remove existing line that lets user log in
no username lowuser
! Make user account
username lowuser view limitedView 0 plainTextPassword
Using CCP

Cisco Device Management Software mentions Cisco Configuration Professional. “Configure > Router > Router Access > User Accounts/View” ought to have an “Add” button.

Follow-up work

Often, there are some general expectations of some things to cover when adding a user. One examples includes making sure the user account is in the necessary group(s) and that the user is not in other group(s) that the user definitely should not be a part of. Another is to make sure that the user's home directory exists and has the security permissions so tht the user can access files in that area, and making sure the user's properties such as the name's spelling and contact information are all accurate.

Additionally, some organizations would like to see certain users having access to certain network drives, certain users having access to certain printers, certain users having visible access to certain printers and having a specific printer set to the default printer, and having certain programs installed and configured. The exact details may vary from one organization to another, so an administrator may need to rely on documented information or may need to ask questions to make sure it is all set up correctly. Not addressing the needs at all can be frowned upon by some people (who would view such sloppiness as being sheer laziness or ignorant incompetance, or both, or perhaps some other trait(s) of a bad nature).