Description: Candidates should be able to add, remove, suspend and change user accounts.
Key Knowledge Areas
◈ Add, modify and remove users and groups.
◈ Manage user/group info in password/group databases.
◈ Create and manage special purpose and limited accounts.
Terms and Utilities
◈ /etc/passwd
◈ /etc/shadow
◈ /etc/group
◈ /etc/skel
◈ chage
◈ groupadd
◈ groupdel
◈ groupmod
◈ passwd
◈ useradd
◈ userdel
◈ usermod
In this tutorial we take a look at user management and the account life cycle; in other words resetting their forgotten passwords every week. If we can recall local users are defined within in the file /etc/passwd, their passwords are usually stored in the file /etc/shadow and groups are defines in /etc/group. We will look at these files and also spend time looking as password management and aging and where home directories come from.
Migrating passwords to and from /etc/shadow
Traditionally the user’s password was stored with their account details in the /etc/passwd file but more recently the passwords have been stored in the /etc/shadow file. Now, the name passwd does not seem so odd when considering user accounts.
The move from the passwd file to the shadow file was for reasons of security. The passwd file needs to world-readable so unauthenticated users can authenticate to the system. Take a look at the output of ls -l against the /etc/passwd file:
Compare that with the permissions on the file /etc/shadow:
We can see the read permission for others exists for the passwd file but not the shadow file.
The password is always encrypted; no matter if it is in the shadow or passwd file but having read access only to root helps protect the passwds from being hacked through programs like “John the Ripper”. Passwords can be migrated to and from the /etc/passwd file with the pwconv (/usr/sbin/pwconv) and pwunconv (/usr/sbin/pwunconv) commands.
User and Group IDs
Each user and group in Linux has its own unique ID, or at least unique to that system. The root user is always UID 0 for example. Using the command id(/usr/bin/id) a user can display their associated UID and GID ( User ID and Group ID), if used with arguments users may also see details of others users. As the user andrew on my Raspberry Pi I can see my ID details with:
id
To display the id of another user we pass the user name as an argument:
id user3
There are various options that we can supply to id so that it will display just the users id -u or just the group id with -g. There is an option -r for the real id used with either -g or -u. If the shell was running with the Set UID permissions then the id -u would show the effective UID, whereas id -ur would show the real UID.
◈ UIDs below 100 are reserved for system accounts
◈ UIDs between 100 and 499 are usually used for service accounts, these account often have a default shell set to /bin/false to prevent an interactive login
Public and Private groups
Red Hat and CentOS and other including Raspbian, use a private group scheme where each user is a member of their own private group. If we create a user named bob then a corresponding group also named bob is created with the user bob as the only member. Other distributions such as SUSE use a public group system and it would be normal for users to default to belonging to the users group. If you using a Red Hat style distribution with private groups then using the -N switch with useradd will disable the private group for that user and they will belong to the normal users group.
For example:
useradd -N joe : will create the user joe as a member of the users group
useradd joe : will create the user and the group joe
Without the -N option Red Hat systems use private groups, -N meaning “No User Group”
Managing users and groups
User management is maintained the commands by:
◈ /usr/sbin/useradd
◈ /usr/sbin/usermod
◈ /usr/sbin/userdel
◈ useradd joe : will create the user joe but without a home directory
◈ useradd -m joe : will create the user joe and his home directory
◈ useradd -m -N joe : will create the user joe and home directory and joe will belong to a public group
◈ useradd -m -N -G sudo joe : will create the user joe, his home directory, his primary group will be the users public group but he additionally will belong to the secondary group sudo
◈ useradd -m -N -G sudo -c “Joe Smith” joe : As before but joe now has a full name of Joe Smith
The contents of the /etc/skel directory are used to create users home directories and if you need additional documents or folders to be created for new users accounts then you can pre-populate this directory. The use of the -k option to useradd allows an alternative skeleton directory to be used.
It is important to note that the username in Linux is case sensitive as well as the password. Where options are not populated at the command line then defaults are read from the file /etc/default/useradd, an extract follows:
We can delete users with userdel:
◈ userdel joe : would delete joe but leave his home directory, crontab and mail spool file
◈ userdel -r joe : would remove joe and is associated files
Group management is effected with the commands:
◈ /usr/sbin/groupadd
◈ /usr/sbin/groupmod
◈ /usr/sbin/groupdel
Groups are created in the file /etc/group.
Password management
In general passwords are managed with either passwd(/usr/bin/passwd) or chage(/usr/bin/chage) . Passwords and their aging informations, (when they expire), are stored on most systems in the /etc/shadow file which should be accessible only by root. As we mentioned before the use of the pwunconv command can return passwords to the less secure /etc/passwd file.
The fields in the shadow file show :
◈ Username
◈ Password : If it starts with ! then the password is locked. The first characters show the encryption algorithm and the random SALT – A password starting $1 is MD5 encrypted and $6 indicates SHA512
◈ The number of days (since January 1, 1970) since the password was last changed.
◈ The number of days before password may be changed (0 indicates it may be changed at any time)
◈ The number of days after which password must be changed (99999 indicates a very long time and if usually the system default)
◈ The number of days to warn user of an expiring password (7 is often the default)
◈ The number of days after password expires that account is disabled or the inactive time, normally not set
◈ The number of days since January 1, 1970 that the account is disabled, normally this is not set.
The information can be convenient displayed and converted to more meaningful dates with the command
chage -l andrew
The following command will expire or disable the user3 account on the Ist July 2014, require a password change every 30 days and the account will be disabled after 14 days of the password expiring
chage -E 2014-07-01 -M 30 -I 14 user3
These settings can also be made with the passwd command; however the chage command can also change the recorded time of when the password was last set with chage -d.
Locking of passwords
If it is necessary to temporarily disable an account then the password can be locked. This will retain the original password but prefix it with the ! making the password invalid; unlocking the password will remove the !
To lock a password:
◈ passwd -l user3
◈ usermod -L user3
To unlock a password:
◈ passwd -u user3
◈ usermod -U user3
We can see that usermod uses upper-case options to effect this and passwd lower-case.
Posts
0 comments:
Post a Comment