ENIB S7-NSA 07_users - User management

{} Declaring users

In previous tutorials, operations were always carried out by the system administrator (root).
This user is very special in that the operating system imposes no restrictions on their privileges.
Although this user can configure anything in the system, they also run the risk of damaging it (accidentally modifying or deleting sensitive files).
In practice, it is therefore recommended to use the system as much as possible as a user who has full control only over their own data, and to resort to administrative privileges only occasionally when it is strictly necessary.

Start a new virtual machine named A.
As the administrator (root), use cat /etc/passwd to display the list of users known to the system.
Notice that each line consists of seven fields separated by :.
Most of these users correspond to various services that can operate without requiring full control over the system; they have the program nologin as their login shell, which always fails if an attempt is made to log in to such an account.
At the top, however, the root user is a real user account that has the shell bash upon login; its user ID is 0, its group ID is also 0, and its home directory is /root✍.
Similarly, cat /etc/group displays the user groups. Each line again consists of four fields separated by :.
Many of these groups also correspond to services, and there is indeed a root group with the identifier 0.

Before creating users, verify that they do not already exist with id alice bob charlie.
These three users will belong to the users group; check that this group already exists with grep -F users /etc/group.
Enter these commands to create them✍:

useradd -u 1001 -g users -c 'Alice Example' -d /home/alice -s /bin/bash alice
useradd -u 1002 -g users -c 'Bob Example' -d /home/bob -s /bin/bash bob
useradd -u 1003 -g users -c 'Charlie Example' -d /home/charlie -s /bin/bash charlie

Verify, using id alice bob charlie, that these three users are now recognised by the system.
You can also see their properties with cat /etc/passwd.

You have declared a login directory for each of the three new users; create them as follows✍:

install -d -m 700 -o alice -g users /home/alice
install -d -m 700 -o bob -g users /home/bob
install -d -m 700 -o charlie -g users /home/charlie

then carefully verify their properties with ll /home.
Notice that each of them belongs to both the user and the group specified in the command.
The sequences of the form drwx------ at the beginning of each line will be studied later; the d at the very start simply indicates that it is a directory.

Since these three new users are now known to the system and have their own home directories, all that remains is to assign them passwords.
The command passwd alice prompts you to enter a password for the selected user.
Choose something simple for this tutorial, such as alice123.
For privacy reasons, nothing is displayed in the terminal while typing, but the characters are indeed taken into account.
A second entry is requested to minimise the risk of typing mistakes.
Enter similar passwords for the users bob and charlie.

Using the Alt ⟶ or Alt ⟵ keys, switch to new terminals.
Use each of them to log in as alice, bob, and charlie using the passwords you have just entered.
In each of the three cases, verify your identity with id and your location with pwd. In each case, create a file inspired by echo 'Alice was here' >my_file.txt, and list the details of your directory with ll.
Observe that each user is indeed free to create their own files in their home directory.

{} Access rights

Display the details of the home directories again using ll /home.
The attributes displayed among the details are of the form drwx------.
The letter d indicates that this is a directory.
The other nine characters are interpreted as three triplets of bits:

The first triplet rwx applies to the user who owns the directory (alice, bob, or charlie, as appropriate).
It indicates here that the owner may list the entries in this directory (r), add, remove, or rename entries within this directory (w), and access the entries in this directory (x, effectively allowing this user to enter it).
The second triplet --- applies to the group that owns the directory (users in this case).
It indicates here that members of this group cannot perform any of the operations associated with the rwx bits.
The third triplet --- applies to other users (neither owners nor members of the owning group).
It indicates here that other users cannot perform any of the operations associated with the rwx bits.

These three triplets of bits correspond to the mode 700 used in the install commands when creating the directories.
The r bit has a value of 4, the w bit has a value of 2, and the x bit has a value of 1, which means that a triplet has a value of 7 when all three bits are set✍.
This 700 mode is very common for a home directory: the owning user has complete control over the contents of their directory, and nobody else has access to it.

This rwx permission system also applies to files:

the r bit indicates whether the contents of the file can be read,
the w bit indicates whether the contents of the file can be modified,
the x bit indicates whether the file is executable (it is a program).

Examine the details of these files again using ll /etc/group /etc/passwd /etc/shadow.
Observe that root has read and write permissions on these files.
By contrast, other users can only view the /etc/group and /etc/passwd files✍ and have no access to the /etc/shadow file✍.
Similarly, ll /usr/bin/ls, for example, shows that this is a file executable by any user, but modifiable only by the system administrator.

In a terminal belonging to the alice, bob, or charlie user, try a command such as echo 'Alice was here' >/alice.txt.
You should observe that creating such a file at the root of the filesystem is denied.
Try again with a command such as echo 'Alice was here' >/tmp/alice.txt; this one should be accepted.
Verify that these two types of behaviour are consistent with the permissions displayed by ll -d / /tmp.

As you have observed, a user cannot access the contents of another user's home directory: the command ls -la /home/bob executed by alice fails.
However, it is possible to temporarily switch users.
The physical person bob can use (with consent) the alice terminal to execute a command on their own behalf (bob).
Entering su bob -c 'ls -la /home/bob' prompts bob to authenticate with their password, allowing access to the contents of their directory.
Similarly, the command cat /etc/shadow executed by alice fails, but su -c 'cat /etc/shadow' prompts for the root password (by default) in order to view a file that is normally inaccessible to alice.

It is quite common for a system administrator to trust a particular user enough to regularly allow them to intervene on the system, for example for maintenance purposes.
In a terminal belonging to root, execute the following commands✍:

echo 'alice ALL=(ALL:ALL) ALL' >/tmp/sudoers_admins
visudo -c -f /tmp/sudoers_admins && \
  install -m 440 /tmp/sudoers_admins /etc/sudoers.d/admins
rm /tmp/sudoers_admins

As recommended, it checks with visudo -c that the file is correct before installing it in /etc/sudoers.d.
From the alice terminal, verify that the commands ls -la /home/bob and cat /etc/shadow are still denied.
Then try sudo ls -la /home/bob; alice is prompted to confirm their own password✍, after which the requested command is executed as root.
Then try sudo cat /etc/shadow; for convenience, the current terminal remembers the recent password confirmation and does not even ask for it again before executing the new command as root.
In practice, the sudo mechanism is strongly recommended.
Indeed, for daily workstation use, it is risky to log in directly as root because a mistake in the many commands entered could damage the system.
On the contrary, it is recommended to configure sudo to grant administrative privileges to a standard user who will most of the time work without elevated rights, and who will only very occasionally use sudo to perform system administration tasks.

{} Working with groups

Even though, thanks to the variety of modern collaborative tools, this practice is no longer very common, the concept of a user group can be used to share common resources.
For example, several users working on the same project may need to be able to modify all the files that make up that project.

In a terminal belonging to root, add a new group project with the command groupadd -g 1000 -U alice,bob project.
You can see its properties with cat /etc/group.
Notice that alice and bob have been specified as members of this new group (but not charlie).
Using the command id alice bob charlie, observe that these three users have retained their primary group users, but that two of them now have project among their secondary groups.
For these two already logged-in users to benefit from this change, they must log out and log back in; verify this with id for each of them.

Still as root, create a directory dedicated to this project as follows✍:

install -d -m 2770 -g project /home/project
setfacl -d -m g::rwx /home/project

and display its details with ll -d /home/project.
Observe that it belongs to the project group, that members of this group have full control over it (rws) while other users have no access to it.
The 2 preceding the directory creation mode is the setgid bit; it is visible in the details as the letter s replacing the x permission.
The setgid bit ensures that the group owning this directory (project here) is automatically inherited by its contents (everything created inside will belong to the project group).
The setfacl command used here is also used to propagate the rwx permissions of this directory to its contents.

In the terminals of alice and bob, execute commands similar to echo 'Alice was here' >/home/project/alice.txt and check the contents of the directory with ll /home/project.
You should observe that the files created in this way belong to the project group and are modifiable by members of that group.
To verify this, ensure that each of the two users modifies the file created by the other using commands similar to echo 'and Alice too' >>/home/project/bob.txt.

The user charlie is not part of the project group.
In a terminal belonging to charlie, try to access the project files with ll /home/project or echo 'Charlie was here' >/home/project/charlie.txt.
The denial you observe shows that precise permission management allows a selected set of users to share resources without making those resources accessible to any other user.

{} Authentication server

The users and groups declared previously are known only to a single system.
If they need to be recognised across an entire fleet of workstations, an authentication service must be provided that all systems can query; this is the purpose of an LDAP server.

Shut down the A virtual machine used previously and delete its A_sda.img disk in order to start again from a clean configuration.
In a terminal, set up a switch named 9991 with s7nsa_hub_switch.py s:9991.
From another terminal, start a virtual machine named A connected to it with s7nsa_machine.py A 9991.
In its file /etc/custom/10_network_setup.sh, configure its network interface as follows ip addr add 192.168.10.1/24 dev eth0 and restart this network configuration.

Setting up the base configuration of an LDAP server is quite tedious.
To simplify the tutorial and focus on the essentials, a Python script is provided for this initialisation.
On the host system, download and place the ldap_server_setup.py file in the SHARED directory and use it as follows: python SHARED/ldap_server_setup.py 192.168.10.1 s7nsa.lab.
This will create the base configuration of a server named 192.168.10.1✍ responsible for the LDAP domain s7nsa.lab✍.
A password will be required to manage this LDAP server; choose something simple for this tutorial, such as secret.
As indicated by the script, this service can now be enabled; to do so, use the command systemctl enable --now slapd.service✍.
Verify with ps aux and ss -pant that the slapd process is running and listening on TCP port 389.

An LDAP server is a directory service that can be used in a variety of domains; it is not necessarily dedicated to users and groups.
You must begin by defining the structure of this directory service before specifying the information relevant to this use case (users and groups).
You can inspect its initial state with the command ldapsearch -xLLL -b "dc=s7nsa,dc=lab" "(objectClass=*)" to see that the initialisation script has prepared the organisation s7nsa.lab.
The process for specifying the information it must store consists of writing a file describing elements to add or modify, and then submitting it to the directory service.
The following command creates a file change.ldif describing two organisational units, people and groups✍:

cat <<'EOF' >change.ldif
dn: ou=people,dc=s7nsa,dc=lab
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=s7nsa,dc=lab
objectClass: organizationalUnit
ou: groups
EOF

Submit this file to the directory service with ldapadd -x -D "cn=Manager,dc=s7nsa,dc=lab" -W -f change.ldif; you must enter the password you chose for the LDAP server manager.
Inspect the state of the directory service again with ldapsearch -xLLL -b "dc=s7nsa,dc=lab" "(objectClass=*)" to observe the additions.

Now add a user group named personnel with the identifier 2000✍:

cat <<'EOF' >change.ldif
dn: cn=personnel,ou=groups,dc=s7nsa,dc=lab
objectClass: posixGroup
cn: personnel
gidNumber: 2000
EOF
ldapadd -x -D "cn=Manager,dc=s7nsa,dc=lab" -W -f change.ldif

Inspect the state of the directory service again with ldapsearch -xLLL -b "dc=s7nsa,dc=lab" "(objectClass=*)" to observe the addition.

Now add three users belonging to this group✍:

cat <<'EOF' >change.ldif
dn: uid=alice,ou=people,dc=s7nsa,dc=lab
objectClass: posixAccount
objectClass: inetOrgPerson
uid: alice
cn: Alice Example
givenName: Alice
sn: Example
uidNumber: 2001
gidNumber: 2000
homeDirectory: /home/alice
loginShell: /bin/bash

dn: uid=bob,ou=people,dc=s7nsa,dc=lab
objectClass: posixAccount
objectClass: inetOrgPerson
uid: bob
cn: Bob Example
givenName: Bob
sn: Example
uidNumber: 2002
gidNumber: 2000
homeDirectory: /home/bob
loginShell: /bin/bash

dn: uid=charlie,ou=people,dc=s7nsa,dc=lab
objectClass: posixAccount
objectClass: inetOrgPerson
uid: charlie
cn: Charlie Example
givenName: Charlie
sn: Example
uidNumber: 2003
gidNumber: 2000
homeDirectory: /home/charlie
loginShell: /bin/bash
EOF
ldapadd -x -D "cn=Manager,dc=s7nsa,dc=lab" -W -f change.ldif

Inspect the state of the directory service again with ldapsearch -xLLL -b "dc=s7nsa,dc=lab" "(objectClass=*)" to observe the additions.

Now add a user group named project with the identifier 3000 and with alice and bob as members✍:

cat <<'EOF' >change.ldif
dn: cn=project,ou=groups,dc=s7nsa,dc=lab
objectClass: posixGroup
cn: project
gidNumber: 3000
memberUid: alice
memberUid: bob
EOF
ldapadd -x -D "cn=Manager,dc=s7nsa,dc=lab" -W -f change.ldif

Inspect the state of the directory service again with ldapsearch -xLLL -b "dc=s7nsa,dc=lab" "(objectClass=*)" to observe the addition.

To enable authentication, each user must be assigned a password (the LDAP manager password is still required here)✍:

ldappasswd -x -D "cn=Manager,dc=s7nsa,dc=lab" -W -s "alice123" \
  "uid=alice,ou=people,dc=s7nsa,dc=lab"
ldappasswd -x -D "cn=Manager,dc=s7nsa,dc=lab" -W -s "bob123" \
  "uid=bob,ou=people,dc=s7nsa,dc=lab"
ldappasswd -x -D "cn=Manager,dc=s7nsa,dc=lab" -W -s "charlie123" \
  "uid=charlie,ou=people,dc=s7nsa,dc=lab"

Each of these passwords can be verified with the following commands: (each user password is required here)✍:

ldapwhoami -x -D "uid=alice,ou=people,dc=s7nsa,dc=lab" -W
ldapwhoami -x -D "uid=bob,ou=people,dc=s7nsa,dc=lab" -W
ldapwhoami -x -D "uid=charlie,ou=people,dc=s7nsa,dc=lab" -W

In its current state, the LDAP server maintains an organisation of users and groups similar to what was previously implemented at the level of a single system.

{} Distributed authentication

It is now a matter of allowing other machines to refer to the user and group organisation maintained by the LDAP server.
From the host system, start a new virtual machine B connected to the same network as the LDAP server with s7nsa_machine.py B 9991.

On machine B, in its file /etc/custom/10_network_setup.sh, configure its network interface as follows ip addr add 192.168.10.2/24 dev eth0 and restart its network configuration.
Verify with ping that A and B can communicate without any issues.

On machine B, verify with id alice bob charlie that the users from the LDAP server are initially unknown.
The sssd service must be configured and started in order to query the LDAP server set up at 192.168.10.1✍:

cat <<'EOF' >/etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = default

[domain/default]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://192.168.10.1
ldap_search_base = dc=s7nsa,dc=lab
ldap_user_search_base = ou=people,dc=s7nsa,dc=lab
ldap_group_search_base = ou=groups,dc=s7nsa,dc=lab
ldap_id_use_start_tls = true
# do NOT allow self-signed certificates in production! OK for this tutorial
ldap_tls_reqcert = allow
EOF
chmod 600 /etc/sssd/sssd.conf
systemctl enable --now sssd.service

Verify with ps aux and ss -pant that the sssd process is running and connected to the TCP port 389 of the LDAP server.

At the time of their setup, the system files that define sources of information about users and groups did not yet consider the use of the sssd service.
Check with cat /etc/nsswitch.conf and cat /etc/pam.d/system-auth that anything related to sss is commented out.
Now that the sssd service is running, the following commands enable its use again✍:

sed -i -re 's/# sss/sss/' /etc/nsswitch.conf
sed -i -re 's/^# (.*pam_sss.so.*)/\1/' /etc/pam.d/system-auth

Using the command id alice bob charlie, observe that these users defined on the LDAP server are now known.
The commands getent group personnel project and getent passwd alice bob charlie display lines similar to what you would have defined directly in the files /etc/group and /etc/passwd.

Using the Alt ⟶ or Alt ⟵ keys, switch to a new terminal.
You can now log in as alice, bob, or charlie by entering the password defined for that user on the LDAP server.
However, the home directory does not exist on this machine!

{} Network filesystem

Since the goal of setting up the LDAP server is to provide users with the ability to be recognised across an entire set of machines, each host must provide a personal directory for every user.
Although it is technically possible to have a home directory stored locally on each host, this is not very convenient in practice; the user does not find the same data depending on whether they log in to one machine or another.
For greater convenience, home directories must themselves be accessible from all machines in this environment.

On machine A, which already acts as the LDAP server, set up an NFS server that exports the /home directory✍:

echo '/home 192.168.10.0/24(rw,sync)' >>/etc/exports
exportfs -arv
systemctl enable --now nfs-server.service
systemctl status --no-pager nfs-server.service

In practice, nothing requires the LDAP server and the NFS server to be on the same machine.
This choice has been made here to simplify the completion of the tutorial.

Even though machine A hosts an LDAP server, it is not yet configured for its own system to query it.
On machine A, repeat the same procedure used on B to configure and enable sss✍.
Verify with id alice bob charlie that machine A now recognises these users. The home directories for these users can then be prepared✍:

install -d -m 700 -o alice -g personnel /home/alice
install -d -m 700 -o bob -g personnel /home/bob
install -d -m 700 -o charlie -g personnel /home/charlie

Verify with ll /home that the details of these directories are consistent with your expectations.

From machine B, verify with showmount -e 192.168.10.1 that you can see the NFS export from machine A.
Also check with ll /home that your local /home directory is empty.
You can then instruct your system that the /home directory exported by A can be automatically mounted onto the local /home directory✍:

echo '192.168.10.1:/home /home nfs _netdev,soft 0 0' >>/etc/fstab
systemctl daemon-reload
mount -a

Check the /home directory again and observe that it now reflects what is exported by machine A.

Using the Alt ⟶ or Alt ⟵ keys, switch to a new terminal.
You can now log in as alice, bob, or charlie by entering the password defined for that user on the LDAP server.
From now on, their home directory is accessible; check with id and pwd that for these users the situation is similar to what is usual with local users and directories.
Have these users execute commands similar to echo 'Alice was here' >my_file.txt.
Although these commands were executed on machine B, check with the command ll /home/* as root on machine A that the files have indeed been written to machine A.

Of course, the users alice, bob, and charlie can also log in to machine A and work on their files.
Have these users execute commands on machine A similar to echo 'Alice was also there' >>my_file.txt, then verify on machine B with cat my_file.txt that the content is shared across all machines.

Since the LDAP server indicates that users alice and bob belong to the project group, you can reuse the procedure performed in this step.
On machine A, as root, prepare a shared directory for the project group✍:

install -d -m 2770 -g project /home/project
setfacl -d -m g::rwx /home/project

On machine B, as alice, run echo 'Alice was here' >/home/project/alice.txt, then as bob, run echo 'and Bob too' >>/home/project/alice.txt.
Check that the project has correctly reflected the actions of these two users.
Of course, charlie, who does not belong to the project group, cannot access this data.

It would also be entirely possible to create multiple machines C, D, etc. all similar to B in order to verify that the distributed account and filesystem processes are highly scalable across the network✍.