Run tasks with elevated permissions 1

Set up sudo privileges after installation: 1

System and normal accounts 1

Creating users 3
Adding users by modifying configuration files 3
Adding user by using useradd 3
Configuration files for user management defaults 4
Creating a user environment 4

Creating and Managing Group Accounts 5

Logging In Through an External Authentication Service 5

id ​username​ -> get information about user account, about userid, group membership and
security context.
whoami​ -> get username of the current user.

Run tasks with elevated permissions

su​ -> opens a subshell as a different user, with the advantage that only in the subshell
commands are executed as root.
sudo​ -> allows you to set up an environment where specific tasks are executed with
administrative privileges.
PolicyKit​ -> allows you to set up graphical utilities to run with administrative privileges.

su -​ -> start a login shell. If you start a login shell, all scripts that make up the user environment
are processed.

Set up sudo privileges after installation:

1. Make the administrative user account member of the group ​wheel​ by using ​usermod
-aG​ ​wheel user​ .
2. Type ​visudo​ and make sure the line ​%wheel ALL=(ALL) ALL​ is included.

System and normal accounts

User account properties are kept in two files ​/etc/passwd​ and ​/etc/shadow​.
● /etc/passwd​ -> all information about user accounts, except hashed passwords is kept in
this file. All users can view this file.
 ● /etc/shadow​ -> hashed passwords are kept in this file. Elevated privileges needed for
viewing this file.

Structure of ​/etc/passwd​ file:

username:password:uid:gid:comment:directory:shell

● Username​ -> unique name of the user.

● Password​ -> this field has been obsolete, not used on modern linux. In the old days
used for storing password hashes. As passwd file is viewable by all users it represented
security risk. So now shadow file is used for storing password hashes.
● UID​ -> unique user id, is a numeric id, representing a user on the system. Lower UIDs
until 999 are typically used for system accounts. Higher UIDs, 1000 and above are used
for user accounts. User ID 0 is reserved for root user. Range of UIDs that are used to
create regular users is set-up in ​/etc/login.defs​.
● GID​ -> each user on linux is a member of at least one user group. This group is referred
as a ​primary group​. This group plays a central role in permission management. GID is a
Group ID of the primary group.
● Comment field​ -> optional fields used for storing comments for the users. Also called
the GECOS field (General Electric Comprehensive Operating System).
● Directory​ -> initial directory where user is placed after logging in. Also called ​home
directory​.
● Shell​ -> program started when user has been successfully connected to the server. Also
called the login shell. For regular users this is usually ​/bin/bash​. For system accounts
this is typically a shell like ​/sbin/nologin​. This shell silently denies access to users. You
can create a file ​/etc/nologin.txt​ that contains a message that will be displayed when a
user who has ​/sbin/nologin​ tries to log in.

Structure of ​/etc/shadow ​file:

login_name:hashed_passwd:passwd_last_changed:days_before_passwd_may_be_chan
ged:days_after_passwd_must_be_changed:days_user_warned_passwd_to_expire:days_
after_passwd_expires_and_accout_disabled:days_account_disabled:reserved

/etc/shadow​ -> used to define validity of the passwords.

● Login name​ -> user name.

● Encrypted password​ -> password hash.
● Password last changed​ -> days since the epoch (January the 1st, 1970), that the
password was last changed.
● Days before password may be changed​ -> allows system admin to control after which
period of days password may be changed. By default set to 0.
● Days after which password must be changed​ -> days after which password must be
changed. By default set to 99999.
 ● Days before password is to expire that user is warned​ -> days before password
expire, when a user is warned that password is about to expire. By default set to 7.
● Days after password expires that account is disabled​ -> used to enforce user to
change the password. After password expiry, user can no longer login.
● Days the account is disabled​ -> days since Jan 1, 1970 that account has been
disabled. System admin can use this field to disable account. Better approach than
deleting the account.
● Reserved field for future use​ -> probably never will be used.

Note: Most of the password properties can be managed with ​passwd​ or ​chage​ commands.

Creating users
useradd​ -> add user account. User account can be added by directly editing ​/etc/passwd​ and
/etc/shadow​, which is not recommended.
userdel​ -> remove the user from the system.
userdel -r​ -> remove user from the system, including the complete user environment.

Adding users by modifying configuration files

It suffices to add one line in ​/etc/passwd​ and another line to ​/etc/shadow​, in which the user
account and all of its properties are defined. This approach is not recommending, as by making
an error, you might mess up the consistency of the file.
If you insist on modifying configuration files directly, than use the ​vipw​.

vipw​ -> opens ​/etc/passwd​ file in an editor and sets appropriate locks on the file to prevent
corruption. It does not check the syntax.
vipw -s​ -> opens ​/etc/shadow​ in an editor and sets appropriate locks on the file to prevent
corruption.
vigr​ -> opens ​/etc/group​ file in an editor and sets appropriate locks on the file to prevent
corruption. ​/etc/group​ file in which groups are defined.

Adding user by using ​useradd

useradd​ -> tool for creating users.
useradd -m -u ​1201​ -G ​sales,ops​ ​linda​ -> create user linda, who is the member of the
groups sales and ops with UID 1201 and add a home directory to the user account.

home directory​ -> directory where personal files can be stored (regular accounts) or directory
which contains the working environment (service accounts).
useradd -m​ -> add a home directory and copy the content of the ​“skeleton (/etc/skel/)”​ directory
to the newly created home directory, and apply appropriate permissions on copied files, so that
new user can use and access them.
usermod​ -> modify user properties. Set all properties of users stored in ​/etc/passwd​ and
/etc/shadow​, and manage group membership.
usermod -p​ -> use encrypted password for the new password (not useful, as you need to
encrypt password before adding it).
passwd​ -> utility to set user’s password.

Configuration files for user management defaults

useradd​ tool uses two configuration files to set default values: ​/etc/login.defs​ and
/etc/default/useradd​.

/etc/default/useradd​ -> contains some default values that are applied when using ​useradd​.

/etc/login.defs​ -> login-related variables are set. It relates to setting up the appropriate
environment for new users. Most significant properties that can be set from ​/etc/login.defs​:
● MOTD_FILE​: defines the file that is used as “message of the day” file. Messages to be
displayed after the user has successfully logged in to the server.
● ENV_PATH​: defines the ​$PATH​ variable, a list of directories that should be searched for
executable files after logging in.
● PASS_MAX_DAYS​, ​PASS_MIN_DAYS​, and ​PASS_WARN_AGE​: define the default
password expiration properties when creating new users.
● UID_MIN​: the first UID to use when creating new users.
● CREATE_HOME​: create a home directory for new users.
● USERGROUPS_ENAB​: if set to yes, than create a private group for all new users. That
means that a new user has a group with the same name as the user as its default group.
If set to no, all users are made a member of the group users.

chage​, ​passwd​ -> commands used to change user properties set in ​/etc/shadow​.
passwd -n ​30​ -w ​3​ -x ​90​ ​linda​ -> set the password for user linda to a minimal usage
period of 30 days and an expiry after 90 days, where a warning is generated 3 days before
expiry.
chage -E ​2015-12-31 bob​ -> expire the account for user bob on December 31, 2015.
chage –l​ -> see current password management settings.

Creating a user environment

Upon user login, an environment is created. The environment consists of some variables that
determine how the user environment is used.
$PATH​ -> environment variable which defines a list of directories that should be searched when
a user types a command.
These files are used for constructing the user environment:
● /etc/profile​: used for default settings for all users when starting a login shell.
● /etc/bashrc​: used to define defaults for all users when starting a subshell.
● ~/.profile​: specific settings for one user applied when starting a login shell.
 ● ~/.bashrc​: specific settings for one user applied when starting a subshell.
Note: ​When logging in, the files are read in this order, and variables and other settings that are
defined in these files are applied. If a variable or setting occurs in more than one file, the last
one wins.

Creating and Managing Group Accounts

Linux users can be a member of two different kinds of groups:
● primary group​ -> Every user must be a member of a primary group and there is only one
primary group. When creating files, the primary group becomes group owner of these
files. The users primary group membership is defined in ​/etc/passwd​; the group itself is
stored in the ​/etc/group​ configuration file.
● secondary group(s)​ -> users can be a member of one or more secondary groups.
Secondary groups are important to get access to files. If the group a user is a member of
has access to specific files, the user will get access to these files also.
Note: ​Working with secondary groups is important, in particular in environments where Linux is
used as a file server to allow people working for different departments to share files with one
another.

vigr​ -> open an editor interface directly on the ​/etc/group​ configuration file. In this file, groups
are defined in four fields per group: ​group_name:group_passwd:group_ID:members​.
● Group name​ -> name of the group.
● Group password​ -> feature that is hardly used anymore. A group password can be
used by users that want to join the group on a temporary basis, so that access to files
the group has access to is allowed.
● Group ID​ -> unique numeric group identification number.
● Members​ -> contains the names of users that are a member of this group as a
secondary group. It does not show users that are a member of this group as their
primary group.

groupadd​ -> command for creating new groups.

groupadd -g ​5001 test​ -> adds test group with group id 5001 (from advanced options ​-g​ is
the only significant).

groupmod​ -> manage group properties. Use this command to change the name or group ID of
the group. To add group members use ​usermod​.
usermod -aG​ -> add users to new groups that will be used as their secondary group.

groupmems -g ​sales​ -l​ -> see which users are a member of the group sales. Show users
who are a member of this group as a secondary group assignment, but also users who are a
member of this group as the primary group assignment.
Logging In Through an External Authentication Service
LDAP is used to provide centralized authentication services.
The Lightweight Directory Access Protocol (LDAP) was developed as a protocol to get
information from an X.500 directory service. This service was originally developed as an
address book.
LDAP is an open standard, and many directory services are available that are using LDAP as
their access protocol. Common LDAP solutions are OpenLDAP, FreeIPA (LDAP server
integrated in the Red Hat Identity Management).

LDAP directory servers are organized in a hierarchical, distributed and replicated way:
● hierarchical​ -> organized like DNS, using domains (in LDAP called containers) to
organize the leaf objects (such as users) in a way that makes sense.
● distributed​ -> entire database does not have to be available on one single server. The
different containers in the LDAP hierarchy can be spread over multiple servers to make
the information available where it needs to be available. To distribute the information in
the LDAP directory, the directory tree is partitioned into different parts.
● replicated​ -> multiple copies of one partition can be created.

When users are connecting to LDAP, they need to specify which specific server to access.
When enabling LDAP access, users need to specify which container they are using as their
base environment. This is referred to as the base context. The name of the base context is
always written out as a name that includes the complete path (a fully distinguished name). The
two containers that contain users are therefore dc=sfo,dc=rhatcert,dc=com and
dc=ams,dc=rhatcert,dc=com.
To ensure a base level of security, Transport Layer Security (TLS) certificates are used. These
certificates ensure that the server that LDAP users are authenticating against is verified, and
that user credentials are secured while transported over the network.
To authenticate on an LDAP server, there are two options:
● Password authentication (RHCSA)
● Kerberos authentication (RHCSE)
To set up RHEL7 for LDAP authentication, you need to create a configuration file in which you
define:
● LDAP server
● TLS certificate
● Base LDAP URL (container in LDAP which should be used)
To setup this three different tools can be used:
● authconfig​ -> command-line utility in which you have to specify all you want to do by
using command-line options.
● authconfig-tui​ -> menu-driven text user interface that allows you to select options to be
used from a list. Use of this utility is recommended.
● authconfig-gtk​ -> utility with a GUI, which for that reason can be used from a GUI
environment only.
Depending on which tool you use, a different authentication backend is configured.
● nslcd​ -> service is configured and started when using ​autconfig-tui​.
● sssd​ -> service used as backend when ​authconfig-gtk​ is used.

When you use ​authconfig-tui​, the ​nslcd​ service is configured on your server to connect to the
LDAP service. The ​nscld​ service is using a configuration file with the name ​/etc/nslcd.conf​.

The important parameters that are added by authconfig-tui are:

● uri​ -> name of the LDAP server.
● base​ -> base container where LDAP users should be looked for.
● tls_reqcert​ -> option which allows TLS connections without a trusted certificate authority
(CA).
● ssl​ -> option which specifies that TLS should be used for establishing trusted
connections.

If you initialize the connection to the LDAP server using ​authconfig-gtk​, the configuration is
written to ​sssd​. The LDAP-related configuration lines are stored in ​/etc/sss/sssd.conf​ file. The
sssd​ service integrates with the local authentication procedure and redirects all authentication
requests to LDAP.
Note: When you use ​authconfig-tui​, the variable ​FORCELEGACY=yes ​is set in
/etc/sysconfig/authconfig​. This makes that n​ slcd​ is used instead of ​sssd​.