Linux Certified System Administrator exam: User and group management

Linux is a first citizen in Microsoft Azure — and in other cloud providers, for that matter — and getting around in this platform is vital for any heterogeneous environment, which is the norm in medium-to-large enterprises. And for that, certification is important. We will focus on one of the areas of the Linux Certified System Administrator exam, specifically user and group management, which is about 10 percent of the test. Here are some of the topics you will need to know for this part of the Linux Certified System Administrator exam:

  • Manage local user accounts
  • Manage local groups and group memberships
  • Manage systemwide environment profiles
  • Manage template user environment
  • Configure user resource limits
  • Manage user privileges
  • Configure PAM

My initial thought was to describe the commands required to manage several aspects of the user and group management, but after writing that I noticed that I didn’t explain the inner workings and files used to make it happen. So in this article, we will take a step back and look at the files that are needed for user and groups management, and in the next section, we will cover the management process and security involved on it.

Understanding the files used in user and group management in Linux

The first one that we need to understand is the /etc/passwd, and this file contains all users in the current system and some vital information. Here is a view of the /etc/passwd file in a brand-new installation of CentOs (we created a user for me, called Anderson, to illustrate the properties for a regular user).

Any entry in the /etc/passwd file will have the structure listed below, and they are going to be divided by colon, a brief explanation of every field is shown in the image below.

  • Username: The name that the user uses to log on the system.
  • Password: The encrypted password (we should see an x, which means that the password information is being stored in a more secure location /etc/shadow).
  • User ID (UID) (3): An ID provided by the system that is used during the evaluation of the permissions applied to an object/resource process.
  • Group ID (GID) (4): A Group ID which the user is assigned that is the primary group of the given user.
  • Gecos/User Info (5) (comes from Unix): It is a multifield that is used to store user information. We can add a comma to add more fields within this field.
  • Home Directory (6): The path for the user’s home folder.
  • Shell (7): Specifies the shell that will be used by the given user when they log in.

By default, the /etc/passwd file is clear text and anyone logged on the system can read it, so a more secure approach is to move the password to a different file. This process is accomplished using /etc/shadow file. The shadow file is part of the shadow-utils package, and it is installed and enabled by default on Red Hat-based operating system.

Besides making a more secure environment, the shadow file also introduces the ability to control aging passwords and the capability to enforce security policies.

The file is shown in the image below, and we added one user to show how a regular entry looks like for a regular user.

The structure of the /etc/shadow file follows the same pattern of the previous file, where a colon divides the fields. However, it has more areas available to control password features.

  • Username: The username that matches the /etc/passwd entry.
  • Encrypted password: This field contains all info related to the password stored in this file which includes the encryption, salt (random value) and the encrypted/hashed password itself.
  • Days since last change: Number of days since the password was last changed.
  • Minimum password age: How many days before changing the password.
  • Maximum password age: Number of days before the system requires a change.
  • Password change warning period: Number of days before the password change where the user will be informed to change their password.
  • Password inactivity period: Number of days before disabling the account. It starts counting after the password expires.
  • Account expiration date: For how many days the account is being disabled (if applicable).
  • Field reserved for future use.

Note: All number of days are based on Jan. 1, 1970. That is the reason that we see a considerable amount of days for password last change even when we changed it a few days ago.

An important takeaway of the /etc/shadow file is the field encrypted password is comprised of three areas. These areas start with a $ symbol. The first one is the $id, which defines the encryption in use. The second is the $salt, which is a random string to make dictionary attacks more difficult, and the third one is the encrypted password/hash.

If you want to understand in detail the encryption, the following table has all possible values being used in the $id field, as follows.

ID Method
$1 MD5
$2a Blowfish
$5 SHA-256
$6 SHA-512

One last file

The last file of our little journey is the /etc/groups, where all local groups are kept in any given Linux server.


<

  • Group name: The name of the group.
  • Group password: Indicates if a password is used, because we are using shadow the password itself will be located in the /etc/gshadow.
  • Group ID: The ID generated during the group’s creation and used in the permission process.
  • User membership: All users that are a member of the group are listed after the last colon.

There is a fourth file that is not used very often, but it is important to mention —the /etc/gshadow, which stores all group password (in case they are used). The content of such a file is depicted in the image below.

That’s the short story about the files behind user and group management, which are a part of the Linux Certified System Administrator exam. In the next article, we will cover several tasks required for a Linux administrator to maintain users and groups, and we will play with these files that we covered in this article. Some of the commands will only work when we have /etc/shadow in place, and some nuances in finding if a user is disabled or locked can be checked by just checking the files that we explored today.

Featured image: Shutterstock / Wikimedia

Anderson Patricio

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange, CISSP and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at Techgenix.com, MSExchange.org, ITPROCentral.com and Anderson Patricio.org (Portuguese).

Share
Published by
Anderson Patricio

Recent Posts

Rebuild those old monolithic apps using microservices architecture

Monolithic apps don’t cut it in an age of faster development and speedy rollouts of new updates. Rebuild those old…

2 hours ago

Email management: Business email and regulatory compliance — what you need to know

Business email often contains sensitive information, and the issue of compliance quickly raises its head. But what does compliance exactly…

18 hours ago

How virtual networking changes when you adopt VMM

VMM’s approach to virtual networking is more complex than that of native Hyper-V, but the various networking components fit together…

23 hours ago

Kubernetes 2020: What’s in store for next year and beyond?

In 2019, everyone’s got their eggs in one big Kubernetes basket. And it’s safe to say that Kubernetes 2020 will…

1 day ago

Diagnosing common Windows problems with PowerShell troubleshooting packs

Windows has a lot of built-in troubleshooting packs that can help you diagnose problems. Here’s how to unleash these tools…

2 days ago

You can stop using email, but the problem won’t go away

As much as you wish it were so, email is not going away. It’s time to face that fact —…

2 days ago