Category Archives: User management

How to create an Amazon Cognito User pool for ALB authentication

A step by step procedure to create an Amazon Cognito user pool. All available options are explained.

One of the best features of AWS application load Balancers (ALB) is authentication! You can offload authentication to ALB that leverages Amazon Cognito in the backend. Amazon Cognito offers identity management through user pools or federated identities. This article will walk you through creating a user pool in Amazon Cognito that is used for ALB authentication. Without further delay, let’s get into it.

Login to Amazon Cognito console
Click on Manage User Pools
On the User pools page, click on Create a user pool button on top right hand corner of the page.
That should start user pool creation wizard. Lets go through it one by one –

Name

Enter the Pool name and click on the Step through settings button.

Attributes

Settings on this page can not be edited later so choose wisely!

The first thing you need to choose is the end user’s sign-in method. They should use a username or email address/phone number to signup/sign in. I am choosing a username and also, allowing them to use email addresses while logging in later once they sign up. I am also selecting case sensitive usernames because that makes more sense.

via CognitoChoose the way end-user sign in

The next section of attributes, let you choose through the list of attributes you want the end user to provide when they sign up in Cognito. You can also choose to add a custom attribute here if one is not listed in the standard list.

Policies

End-user password policies and controls are defined in this section. All the fields are pretty self-explanatory.

MFA and verifications

An extra layer of account security can be defined here. MFA and related configurations. Please note that if you are enabling MFA for end-users then you should be enabling phone number attributes in earlier settings and text messages (verification and subsequent messaging) will incur extra charges. Amazon pretty much explained each option here.

If you are opting for adding and managing phone number attributes then you need to create a role that provides access to Cognito for sending text messages on your behalf.

Messages customizations

In this section, you should be customizing the email or SMS messages being sent out by Amazon Cognito on your behalf. It’s a place if you want to have company branding in the communications! Make sure you have a verified email address in Amazon SES to set it as From email address.

In the later part of the page, you can configure how you want verification to be done using codes or clickable links. Also, you can customize the text of the message here.

Devices

Choose if Cognito should remember the user’s device. This will enhance the user experience. But, to use this feature you should have MFA enabled for end-users. Since we did not opt for it, we will simply say No and move forward.

App clients

In this section, you should create an app client which will access this user pool. On the creation of the app client, you will receive the app ID and secret key that you can configure in your applications to access this user pool.

Click on Add an app client

App client name: Add unique name
Refresh token expiration: Refresh tokens are used to retrieve new ID and access token. Control their expiration here. Read more about refresh tokens
Access token expiration: Used for autorizing the API operation. Control expiration here. Read more about access tokens
ID token expiration: It used to claim the authenticated user’s identity. Define its expiration limits here. Read more about ID tokens.
Auth Flows Configuration: Enable depends on your integration requirements. I selected ALLOW_USER_PASSWORD_AUTH and left others untouched.

Security Configuration: It allows to send back generic error. Select recommened unless you have any other reason not to!
Advanced token settings: Enable or disable token revocations.
Attributes read and write permissions: Select list of attributes which this app client can read or write.

Click on Create app client. It will be created along with the user pool when you completes the whole wizard.

Click on the Next step to move forward in the user pool creation wizard.

Triggers

On this page, you can configure lambda functions to be triggered on specific actions or workflow. You need to create Lambda functions in advance to select here from the dropdown. List of triggers available here –

Pre sign up
Pre authentication
Custom message
Post authentication
Post confirmation
Define Auth Challenge
Create auth challlenge
Verify authc challenge response
User migration
Pre token generation

All triggers are listed with descriptions for easy understanding of when they will be activated and execute related Lambda functions. For the simplicity of this article, we are not adding any.

Review

Review all the details you supplied throughout the wizard. You can make edits if necessary and then lastly click on Create pool

You should be greeted with a success message and the user pool management page. You can note the user pool ID generated for this user pool.

Amazon app clients settings

Now, that you created a user pool and app client for it. Let’s look at some of the settings those needs to be checked or changed to make sure your app client is ready to be consumed.

Configure Amazon Cognito app client’s IDP settings

Navigate to App integration > App client settings on the left sidebar menu on the user pool page.

Enable Cognito user pool under Enabled identity providers.
You should be having Callback URLs handy to fill in here. Those are URLs where app will be navigated once successful authentication happens. Your application developers should be able to help you with these details.
Sign out URLs are those where user will be redirected once its signed out from IDP session
OAuth 2.0 settings should be discussed with developer and configured as the app requirement

What is Amazon Cognito domain and how to configure it?

It’s a domain prefix with FQDN https://<prefix>.auth.<region>.amazoncognito.com where,

prefix : unique identifier of your choice
region: AWS region where user pool is hosted.

This domain is used to host sign-up and sign-in pages by Amazon Cognito. You can edit those pages for your company branding as well as explained in the next step.

Navigate to App integration > Domain name on the left sidebar menu on the user pool page.

Enter the prefix in the given text box and click Check availability. It will make sure you chose a unique prefix. Click on Save changes

You can opt to choose your own domain as well. You need to have an associated SSL certificate in ACM and permission to add the ALIAS record in the DNS hosted zone.

Once done, Cognito will create Amazon Cloudfront distribution for that domain in the backend and supply you with the alias target value to be configured in the hosted zone.

Add ALIAS record (CNAME for non-Route53) for Domain name and Alias target mentioned above. Once done and CloudFront distribution is created, your domain status will be set to ACTIVE.

How to change login UI of Amazon Cognito?

Navigate to App integration > App client settings on the left sidebar menu on the user pool page.

On the last part of the page, you can find Hosted UI settings. There you will be able to play around with CSS, logo files to create a new custom login page.

Make sure you have Amazon Cognito domain name defined and at least one OAuth scope defined (above step)

How to retrieve Amazon app client secret?

Navigate to General settings > App clients on the left sidebar menu on the user pool page. And there you can retrieve app client secret.

Understanding /etc/shadow file

Leave a reply

Article to understand fields, formats of /etc/shadow file. Learn each field in detail and how it can be modified.

We have written about /etc/passwd file in the past. In this article, we will see /etc/shadow file, its format, its content, its importance for the Linux system. /etc/shadow file (henceforth referred to as shadow file in this article) is one of the crucial files on system and counterpart of /etc/passwd file.

Unlike the password file, the shadow file is not world-readable. It can be read by the root user only. Shadow file permissions are 400 i.e. -r-------- and ownership is root:root. This means it can be only read and by root users only. The reason for such security is password related information that is being stored in this file.

Typical /etc/shadow file looks like :

# cat /etc/shadow
root:$1$UFnkhP.mzcMyajdD9OEY1P80:17413:0:99999:7:::
bin:*:15069:0:99999:7:::
daemon:*:15069:0:99999:7:::
adm:*:15069:0:99999:7:::
testuser:$1$FrWa$ZCMQ5zpEG61e/wI45N8Zw.:17413:0:33:7:::

Since its normal text file, commands like cat, more will work without any issue on it.

/etc/shadow file has different fields separated by a colon. There are a total of 8 fields in the shadow file. They are –

Username
Encrypted password
Last password change
Min days
Max days
Warn days
Inactive days
Expiry

Lets walk through all these fields one by one.

Username

Username is the user’s login name. Its created on the system whenever the user is created using useradd command.

Encrypted password

Its user’s password in encrypted format.

Last password change

Its number of days since 1 Jan 1970, that password was last changed. For example in the above sample testuser’s last password change value is 17413 days. Means count 17413 days since 1 Jan 1970 which comes to 4 Sept 2017! That means testuser last changed his password on 4 Sept 2017.

You can easily add/subtract dates using scripts or online tools.

Min days

Its minimum number of days between two password changes of that account. That means the user can not change his password again unless min days have passed after his last password change. This field can be tweaked using chage command. This is set to 7 days generally but can be 1 too depends on your organization’s security norms.

Max days

Its maximum number of days for which the user password is valid. Once this period exhausted, the user is forced to change his/her password. This value can be altered using chage command. It is generally set to 30 days but value differs as per your security demands.

Warn days

Its number of days before password expiry, the user will start seeing a warning about his password expiration after login. Generally it is set to 7 but it’s up to you or your organization to decide this value as per organizational security policies.

Inactive days

A number of days after password expiry, the account will be disabled. This means if the user doesn’t log in to the system after his/her password expiry (so he doesn’t change the password) then after these many days account will be disabled. Once the account is disabled, the system admin needs to unlock it.

Expiry

Its number of days since 1 Jan 1970, the account is disabled. Calculations we already saw in the ‘last password change’ section.

Except for the first 2 fields, the rest of all fields are related to password aging/password policies.

chage command in Linux for password aging control

Leave a reply

Learn chage command in Linux with several examples. View, edit password aging parameters using chage command to secure your Linux accounts.

Controlling password aging of user accounts is very much important for the security of the server. This ensures users are always updated with passwords and there are no old passwords or accounts living on the server which are vulnerable to compromise.

1. Last change date

This is the number of days from Unix date i.e. 1 Jan 1970 when the password was last changed. Normally this date changes automatically when the user changes his password. But, if you want to change it manually you can use chage command with -d switch like below :

# chage -d 2016-03-12 user4  << YYYY-MM-DD format

You can view change in date by comparing before and after the output of chage -l <user> command. This date is displayed against the “Last password change” attribute in the output. We will see this output in detail in the last part of this post.

2. Expiry date

This is the date on which account will expire and the user won’t be able to log in until he changes his account password. It can also be set as YYYY-MM-DD format with -E option as below :

# change -E 2016-12-05 user4

This date changes automatically whenever the user changes his password. It checks the maximum days attribute and adds those many days to the current date (date of password change); the resulting date will be an expiry date.

Setting this to -1 removes the account password expiry. That account will have a non-expiry password and never need to change the password in the future.

3. Minimum days

These are a number of days a user must wait to make another password change on his account. For example, if this is set to 7 then once a user changes the password, he can not change the password again until 7 days. This can be set using -m option.

# chage -m 7 user4

Setting this parameter to 0 enables the user to change his password at any time (no restriction).

4. Maximum days

These are a number of days users can use the same password. For example, if this is set to 20 days then the user must change the password after 20 days. This value decides the password expiration date we saw above. This can be set using -M option

# chage -M 30 user4

If you want to remove this restriction and want to use the same password forever then you need to set the expiration date to -1 which we saw earlier.

5. Warning days

These are a number of days before the password expiry date, the user starts seeing a warning on his login screen about password expiry. User warning will be shown post-login like below :

login as: user4
user4@10.10.2.5's password:
Warning: your password will expire in 6 days
Last login: Thu Dec 29 17:17:32 2016 from 10.10.2.10
#

You can set this attribute using -W option

# chage -W 7 user4

6. Inactivity period

These are a number of days the account can remain inactive after the password is expired. After which account will be locked for security reasons since idle accounts vulnerable to compromise. This can be set using -I option.

# chage -I 10 user4

If you set this to -1 then this restriction will be waived off from that account.

7. Viewing all the above attributes

To view all the above attributes you can use -l option :

# chage -l user4
Last password change                                    : Mar 12, 2016
Password expires                                        : Jun 10, 2016
Password inactive                                       : never
Account expires                                         : Nov 30, 2016
Minimum number of days between password change          : 0
Maximum number of days between password change          : 90
Number of days of warning before password expires       : 7

In above output:

Last password change is Last change date -d
Account expires is the expiry date -E
Password inactive is Inactivity period -I
Account expires is the expiry date for the account. Last change date plus maximum days.
Minimum number of days……. is minimum days -m
Maximum number of days……. is maximum days -M
Number of days of warning …… is warning days -W

You can check this output before changing any attribute using the above commands. Check change in attribute post command execution again!

Let us know queries, suggestions, feedback, corrections in the comments below.

9 Linux account password policies explained

1 Reply

Learn 9 different account password policies in Linux. Understand how to view them, how to change them and what is their impact on user management.

User management is one of the important aspects of Linux system administration. Restricting unauthorized access to systems can be prohibited by implementing strong password policies on accounts. That’s why this is a mandatory task in system hardening.

In this post, we will be seeing below nine different password policies that can be implemented in Linux.

Password Max days
Password Min days
Password warning days
Password history depth
Password minimum length
Minimum upper case characters
Minimum lower case characters
Minimum digits in password
Wrong password retry

In the above list first 3 parameters are password aging-related whereas rest decides password strength.

1. Password Max days

This parameter decides how many days the maximum a password can be used. Once account password ages for these many days, it’s mandatory for the user to change his/her account password. This forbids users from using the same password for a long duration. In short, this is a maximum number of days password is valid on the system. This value can be set under file /etc/login.defs against parameter PASS_MAX_DAYS as shown below:

# cat  /etc/login.defs

----- file clipped -----
#       PASS_MAX_DAYS   Maximum number of days a password may be used.
PASS_MAX_DAYS   90
----- file clipped -----

File parameter values affect only newly created accounts after the file has been edited. But for existing accounts, you need to change this value manually by using chage command with -M option. You can check the current set value by using -l option.

# chage -l user4

----- output clipped -----
Maximum number of days between password change          : 30
Number of days of warning before password expires       : 7

# chage -M 45 user4

# chage -l user4

----- output clipped -----
Maximum number of days between password change          : 45
Number of days of warning before password expires       : 7

Observe in the above example, max days for an existing account have been changed from 30 to 45 days using chage command.

2. Password min days

These attributes control a minimum number of days before a password can be changed. This forbids users from changing passwords too frequently. For example, if this parameter is set to 7 days & user changed password today. Then he will be able to change it again only after 7 days from now. This value can be set under file /etc/login.defs against parameter PASS_MIN_DAYS as shown below:

# cat  /etc/login.defs

----- file clipped -----
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
PASS_MIN_DAYS 1
----- file clipped -----

File parameter values affect only newly created accounts after the file has been edited. But for existing accounts, you need to change this value manually by using chage command with -M option.

# chage -l user4

----- output clipped -----
Minimum number of days between password change          : 3

# chage -m 1 user4

# chage -l user4

----- output clipped -----
Minimum number of days between password change          : 1

3. Password warning days

This attribute controls a number of days before the password expires, the user starts seeing a warning about password change after login. This gives sysadmins a chance to educate and made aware of their system users about password expiry. So that users can change their password well before its expiry time. This is not really adding any security to the system but helping users to avoid unwanted service impacts due to password expiry. Its value can be defined under /etc/login.defs file against PASS_WARN_AGE parameter.

# cat  /etc/login.defs 

----- file clipped -----
#       PASS_WARN_AGE   Number of days warning given before a password expires.
PASS_WARN_AGE   7
----- file clipped -----

Same as the last two parameters, this file parameter values affect only newly created accounts after the file has been edited. But for existing accounts, you need to change this value manually by using chage command with -W option.

# chage -l user4

----- output clipped -----
Number of days of warning before password expires       : 7

# chage -W 10 user4

# chage -l user4

----- output clipped -----
Number of days of warning before password expires       : 10

4. Password history depth

When the user sets a new password, it will be checked against historical passwords. If the user tries to set the same old password then the system will forbid the user to use that password. This password history depth is defined by this attribute. If it is set to 3 then the user won’t be able to use any password which matches his last 3 passwords used.

This depth can be set in /etc/pam.d/system-auth file against the remember parameter.

# cat /etc/pam.d/system-auth |grep -i pass

----- file clipped -----
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok remember=2
----- file clipped -----

In the above example, the last 2 passwords will be kept in history to check against the new one since remember is set to 2.

5. Password minimum length

Minimum characters needed in the password are defined by this attribute. This ensures the enforcement of strong passwords to be used by users. It can be defined in /etc/pam.d/system-auth file against minlen parameter.

# cat /etc/pam.d/system-auth |grep -i pass

----- file clipped -----
password    requisite     pam_cracklib.so try_first_pass retry=3 minlen=8 dcredit=-1 ucredit=-1 lcredit=-1
----- file clipped -----

This will be used whenever a new password is being set.

6. Minimum upper case characters

Another password strengthening attribute like the previous one. This ensures the enforcement of the use of uppercase characters in the password. It can be defined in /etc/pam.d/system-auth file against ucredit parameter.
Example in point 5.

7. Minimum lower case characters

This ensures the enforcement of the use of lowercase characters in the password. It can be defined in /etc/pam.d/system-auth file against lcredit parameter.
Example in point 5.

8. Minimum digits in password

This ensures the enforcement of the use of digits in passwords. It can be defined in /etc/pam.d/system-auth file against dcredit parameter.
Example in point 5.

9. Wrong password retry

This is a number of tries users get to try passwords without locking the account. As universally accepted, this is always set to be 3. Its value can be defined in retry parameter in /etc/pam.d/system-auth file.

Example in point 5.

Please make a note that all the above configurations files are taken into account from the RHEL flavor. If you have any questions, queries, suggestions, corrections please let us know in comments.

Different ways to disable user access in Linux

Leave a reply

Learn different ways to restrict users from accessing the system apart from locking him out. One of the essential tips for user management for user access.

Whenever there is a requirement of disabling user access on the Linux system first thing that came to mind is locking the user out of the system. But there are many different ways out to achieve the same motto i.e. refraining users from accessing the account.

We have already seen how to lock/unlock user account in Linux. See below list which shows other ways of disabling access :

Using usemod command
Editing password hash /etc/passwd file
Editing login shell in /etc/passwd file
By expiring account lifetime
By emptying user password

1. Using usermod command

usermod command is used to modify user characteristics. This command has -L option to lock the account and -U option to unlock the account.

2. Editing password hash in /etc/passwd

This is the same as above. The only thing is we will edit /etc/passwd file using vi, vipw or any text editor manually and put up ! mark in front of the encrypted password! It is always recommended to use vipw command to edit /etc/passwd to maintain the integrity of file unless you know what you are doing.

3. Editing login shell in /etc/passwd file

As you know the last field in /etc/passwd file is a shell. By editing this parameter to /sbin/nologin or /bin/false shell one can restrict access of the user.

4. By expiring account lifetime

On the Linux system, every account comes with a lifetime defined hence account expiry is tagged to each account. Setting this expiry date to past date, one can pose an account’s lifetime as expired to the kernel. Hence kernel won’t permit the user to log on. The account expiry date can be set using chage -E option. The date format should be in yyyy-mm-dd.

# date
Thu Dec  1 20:38:36 EDT 2016
# chage -E 2016-11-30 user5
# chage -l user5
Last password change                                    : Dec 01, 2016
Password expires                                        : Mar 01, 2017
Password inactive                                       : never
Account expires                                         : Nov 30, 2016
Minimum number of days between password change          : 0
Maximum number of days between password change          : 90
Number of days of warning before password expires       : 7

In the above example, we set the expiry date as yesterday i.e. account is already expired for today. And hence it won’t be able to log in. See account expires showing as 30 Nov where the current system date is 1 Dec.

5. By emptying user password

This another tricky way to refrain users from accessing the system. But in this method, you will be using the user’s set password. So when you enable the user back on the system, user won’t be able to use its old password. A new password needs to be set up for his account.

In this method, you have to empty the user password. Since the password is empty, at login prompt user won’t be able to get in. You can empty the password using -d option.

# passwd -d slavhate
Removing password for user slavhate.
passwd: Success
# passwd -S slavhate
slavhate NP 2016-12-07 1 90 7 -1 (Empty password.)

You can verify if password is removed using passwd -S command.

Linux user management (useradd, userdel, usermod)

Leave a reply

Learn how to create, delete, and modify a user in Linux (useradd, userdel, usermod). Basic user management which is must know for every Linux/Unix administrator.

Anyone accessing system locally or remotely has to has a user session on the server hence can be termed as a user. In this post, we will be seeing user management which is almost similar for all Linux, Unix systems. There are three commands useradd, userdel and usermod which are used to manage users on Linux systems.

Interesting related articles –

Command: useradd

Command to add a new user to the system. This command can be as short as just one argument of userid. When running with just userid as an argument then it takes all default values for creating that user as defined in /etc/default/useradd file. Or else a number of options can be specified which defines parameters of this new user while creation.

# cat /etc/default/useradd
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

The command supports the below options :

-b <base_dir> If the home directory is not specified this one is mandatory.
-c <comment> Any text like a description of the account
-d <home_dir> Home directory
-e <expire_date> Account expiry date in YYYY-MM-DD
-f <inactive> No of days after which acc will be disabled after password expiry
-g <gid> group id
-u <uid> User id
-G <groups> Secondary groups
-k <skel_dir> Files within skel_dir will be copied to home_dir of the user after creation
-K <key=value> To override default parameters in /etc/login.defs
-m Create the home directory if it doesn’t exist.
-o Allow non-unique UID
-p Encrypted password (not normal text one). It can be obtained from the crypt command.
-r Create a system account. This won’t have password aging and UID from system UID range
-s shell

# useradd -c "Test user" -d /home/test -m -e 2016-12-05 -f 7 -g 100 -u 956 -o -s /bin/bash testuser1
# cat /etc/passwd |grep testuser1
testuser1:x:956:100:Test user:/home/test:/bin/bash
# useradd testuser2
# cat /etc/passwd |grep testuser2
testuser2:x:54326:54329::/home/testuser2:/bin/bash

See the above example with and without using options. Also, check the below list, it shows where you can verify the account-related particular parameter which you specified in useradd command.

home_dir Check using ls -lrt
uid, gid In /etc/passwd and /etc/group
comment, shell In /etc/passwd file
groups In /etc/group file
skel_dir files Check-in home_dir
expire_date, inactive Check-in chage -l username output.
Encrypted password In /etc/shadow file

Command: userdel

As the name suggests its a command to delete users. It has only two options –

-r Remove user’s home_dir & mail spool
-f Removes user even if he/she logged in. Removes home_dir, mail spool & group of the same name even these are being shared by another user. Dangerous!

If none of the options used and command just ran with userid argument. It will only remove the user from the system keeping its home_dir, mail spool and a group of the same name (if any) intact on the server.

#  ll /home |grep testuser
drwx------   4 testuser   testuser  4096 Nov 23 10:43 testuser
# userdel testuser
#  ll /home |grep testuser
drwx------   4      54326    54329  4096 Nov 23 10:43 testuser

# userdel -r testuser
#  ll /home |grep testuser
#

See above example which shows without using -r option keeps home directory intact.

Command: usermod

This command used to modify user parameters which we saw in useradd command. All parameter options with useradd command compatible with this command. Apart from those options, it supports below ones –

-l <new_login> Change login name to different. You have to manually rename home_dir
-L Lock account. Basically it puts ! in front of encrypted password in passwd or shadow file.
-U Unlock account. It removes!
-m <new_home> Moves home_dir to new_dir. -d is mandatory to use with it.

# useradd usr1# cat /etc/passwd |grep usr1
usr1:x:54326:54330::/home/usr1:/bin/bash
# usermod -l usr2 usr1
# cat /etc/passwd |grep usr2
usr2:x:54326:54330::/home/usr1:/bin/bash

# cat /etc/shadow |grep usr2
usr2:$6$nEjQiroT$Fjda8KiOIbnELAffHmluJFRC8jjIRWuxEWBePK1gun/ELZRi3glZdKVtPaaZ4tcQLIK2KPZTxdpB3tJvDj3/J1:17128:1:90:7:::
# usermod -L usr2
# cat /etc/shadow |grep usr2
usr2:!$6$nEjQiroT$Fjda8KiOIbnELAffHmluJFRC8jjIRWuxEWBePK1gun/ELZRi3glZdKVtPaaZ4tcQLIK2KPZTxdpB3tJvDj3/J1:17128:1:90:7:::
# usermod -U usr2
# cat /etc/shadow |grep usr2
usr2:$6$nEjQiroT$Fjda8KiOIbnELAffHmluJFRC8jjIRWuxEWBePK1gun/ELZRi3glZdKVtPaaZ4tcQLIK2KPZTxdpB3tJvDj3/J1:17128:1:90:7:::

See the above examples of usermod command showing locking, unlocking user and changing user names.

These three commands take almost most of the user management tasks in Linux Unix systems. Password management is another topic which does not fall in user management. We will see it on some other day.

Understanding /etc/group file

Leave a reply

/etc/group is the key file in any Linux Unix system for user management. Learn fields, formats within /etc/group file. Understand the meaning of each field and how it can be set.

In this post, we are going to see the format, the content of /etc/group file. /etc/group (will be called as group file henceforth in this post) is the popular file after /etc/passwd, when it comes to user in any Linux or Unix based system. Every administrator should be familiar with this file. Rather whenever one starts working on Linux Unix based system this file should be covered during his/her basis learning itself.

The group file is a human-readable file that contains information about user groups on the system. Typical /etc/group file looks like below :

# cat /etc/group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:

Since its normal text file, commands like cat, more will work without any issue on it.

If you observe the above file, it has values separated by colons :. Each row is one entry. One entry is for one group. For every group (row) there are 4 fields defined separated by a colon. Those four fields are :

Group name
encrypted password for the group
group id
group members

Let’s see one by one :

Group name

Its a group name by which group is being identified for admins/humans. This name is used in all group management/user management related commands. New group name entry gets added in this file when groupadd command is used.

Encrypted password for the group

Its password in an encrypted format. In the above example, you see x instead of encrypted password since /etc/shadow file is generated on the system. The encrypted password is found in /etc/gshadow file in such a case.

Group ID

Its numeric id assigned to the group. Normally kernel identifies group by this field. This ID also features in /etc/passwd file in the 4th field. More information on GID can be found here. Group id gets generated automatically when a group is created using groupadd command.

Group Members

This is a list of user names separated by commas which are member of this group. File or directory permissions assigned to the group will be inherited to all these group members.

Understanding /etc/passwd file

2 Replies

/etc/passwd is the key file in any Linux Unix system. Learn fields, formats within /etc/passwd file. Understand the meaning of each field and how it can be set.

In this post, we are going to see the format, the content of /etc/passwd file. /etc/passwd (will be called as password file henceforth in this post) is a popular and most accessed file when it comes to user in any Linux or Unix based system. Every administrator should be familiar with this file. Rather whenever one starts working on Linux Unix based system this file should be covered during his/her basis learning itself.

The password file is a human-readable file that contains information about users on the system including their encrypted passwords. Some systems don’t have encrypted passwords in this file if /etc/shadow file is generated. Typical /etc/passwd file looks like below :

# cat /etc/passwd
root:x:0:0:ROOT account:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
myuser:x:513:520:Test User:/home/myuser:/bin/bash
----- output truncated -----

Since its normal text file, commands like cat, more will work without any issue on it.

By default /etc/passwd file permission is 644 i.e. -rw-r--r-- and ownership root:root. Means file is world-readable and only root users can edit it. However, it is not recommended it manually.

If you observe the above file, it has values separated by colons :. Each row is one entry. One entry is for one user. For every user (row) there are 7 fields defined separated by a colon. Those seven fields are :

Username
Encrypted password
UID
GID
Comment
Home directory
Shell

Let’s see one by one :

Username

Its user name being used by the user to login. This field gets populated when new users are created on a system using useradd command.

Encrypted Password

Its password in an encrypted format. In the above example, you see x instead of encrypted password since /etc/shadow file is generated on the system. The encrypted password is found in /etc/shadow file in such case.

# cat /etc/shadow
root:$6$FCGlEAUb$nRMJdwjadnw7.OL6L2oxeMQzM445gv0NK1AfjpjSMyth5JHXolCQnhA0:17075:0:99999:7:::

For example, see the above output where the encrypted password for root account can be seen in the second field.

Read also: Learn how to reset forgotten root password

UID

Its user id. Its unique number assigned to every account on the system. More information on UID can be found here. This can be set using -u argument in useradd, usermod command. If you want to assign the same UID to some new user which is being used to the old user already then you need to specify -o in command but this is not recommended.

Also read: Password file commands

GID

Its group id. Its unique number of groups of which account is member of. GID is created on the system with groupadd command. More information on GID can be found here. This can be set using -g argument in useradd, usermod command.

Comment

This field is introduced to have some descriptions against the account. This is purely for humans to identify/understand what related account is or to whom it belongs to. In the above example, the “ROOT account” is the description defined for the root users. This can be the name of the person or name of application etc. This can be set using -c argument in useradd, usermod command.

Home Directory

Its a directory where normally user lands into when he/she login. The home directory is where the user’s history file, profile, etc basic account stuff resides. Every user is recommended to have a unique directory. In the above example /root is defined as the home directory for the root account. This can be set using -d argument in useradd, usermod command. If the directory does not exist on server then -m can be accompany -d option so that the directory will be created automatically.

Shell

This is a shell that will be spawn when the user successfully logs in. In the above example /bin/bash is shell defined for the root account. This can be set using -s argument in useradd, usermod command.

How to remove password expiry in linux

Leave a reply

Know how to remove password expiry in a Linux system. This is helpful in setting app accounts that need non-expiry passwords to run.

Requirement :

To set never expire attribute on account password. Some applications/users are required to have the same password for a longer duration. This requires them to exit from the system-wide password expiry policy. So that those accounts can run a lifetime without the need of changing their passwords.

How to do it :

Check the account’s current policy.

# chage -l testuser

Last password change                                    : Sep 01, 2016
Password expires                                        : Oct 04, 2016
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 33
Number of days of warning before password expires       : 7

Here the second line shows when the password is expiring post which user will be prompted to set a new password. Set password to never expire with below command

# chage -M -1 testuser

Verify changes in the account. Note here in output, Password expires field changed its value to never.

# chage -l testuser

Last password change                                    : Sep 01, 2016
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 33
Number of days of warning before password expires       : 7

Name

Attributes

Policies

MFA and verifications

Messages customizations

Tags

Devices

App clients

Triggers

Review

Amazon app clients settings

Configure Amazon Cognito app client’s IDP settings

What is Amazon Cognito domain and how to configure it?

How to change login UI of Amazon Cognito?

How to retrieve Amazon app client secret?

Username

Encrypted password

Last password change

Min days

Max days

Warn days

Inactive days

Expiry

1. Last change date

2. Expiry date

3. Minimum days

4. Maximum days

5. Warning days

6. Inactivity period

7. Viewing all the above attributes

1. Password Max days

2. Password min days

3. Password warning days

4. Password history depth

5. Password minimum length

6. Minimum upper case characters

7. Minimum lower case characters

8. Minimum digits in password

9. Wrong password retry

1. Using usermod command

2. Editing password hash in /etc/passwd

3. Editing login shell in /etc/passwd file

4. By expiring account lifetime

5. By emptying user password

Command: useradd

Command: userdel

Command: usermod

Group name

Encrypted password for the group

Group ID

Group Members

Username

Encrypted Password

UID

GID

Comment

Home Directory

Shell

Requirement :

How to do it :