RH133读书 笔记(5) - Lab 5 User and Group Administration

Lab 5 User and Group Administration

Goal: To build skills for user and group administration.

Estimated Duration: 45 Minutes

Lab Setup:

Instructor: Start ypserv.

Situation: You need to setup groups and accounts for several users in your company. Each department also requires a shared directory for their files.

Sequence 1: Creating the groups and users

Scenario: You need to set up groups for different departments in your company. You also need to set up user accounts for the employees in those departments.

Deliverable: A system with users joshua and alex in the sales group; dax and bryan in the hr group; zak and ed in the web group, and manager in the sales, hr, and web groups.

Instructions:

1. Add accounts for the following seven users to your system: joshua, alex, dax, bryan, zak, ed, and manager. Assign each user this password: password

Since you need to add several users, a for-loop may speed things up. This can be entered on the command line or placed in a file and run as a shell script.

for USER in joshua alex dax bryan zak ed manager
do
　　useradd $USER
　　echo password | passwd --stdin $USER
done

Note that this sets a password of password for each user.

2. Add the following groups to the system:

• sales (GID:200)

• hr (GID: 201)

• web (GID: 202)

a. [root@stationX]# groupadd -g 200 sales

b. [root@stationX]# groupadd -g 201 hr

c. [root@stationX]# groupadd -g 202 web

3. Why should you set the GID in this manner instead of allowing the system to set the GID by default?

The primary group for new users will be created with lowest available GID above 500. Most administrators want to keep additional groups in a specific range of GIDs to ease management.

4. Add joshua and alex to the sales auxiliary group, dax and bryan to the hr auxiliary group. Add zak and ed to the web auxiliary group. Add manager to all of these auxiliary groups.

You can use usermod -G to do this:

[root@stationX]# usermod -G sales joshua
[root@stationX]# usermod -G sales alex
[root@stationX]# usermod -G hr dax
[root@stationX]# usermod -G hr bryan
[root@stationX]# usermod -G web zak
[root@stationX]# usermod -G web ed
[root@stationX]# usermod -G sales,hr,web manager

5. How can you add the web group to dax's auxiliary groups?

[root@stationX]# usermod -G web,hr dax

-OR-

[root@stationX]# usermod -a -G web dax

If you had run the command usermod -G web dax, that would have removed dax from the hr group and any other auxiliary groups to which dax may have belonged.

6. You can login as each user and use the id command to verify that they are in the appropriate groups. How else might you verify this information?

You can use su - user and run the id command, or simply use the username as an argument to id:

for USER in joshua alex dax bryan zak ed manager
do
　　id $USER
done

Sequence 2: Setting up shared directories

Scenario: Each department for which you created a group also needs a shared directory. This will allow users in each department to share files, but will prevent users in other departments from altering, or even seeing those files.

Deliverable: A shared directory for each department that allows only users in that department to enter it or create, view, and alter files within.

Instructions:

1. Create a directory called /depts with sales, hr, and web subdirectories.

[root@stationX]# mkdir -p /depts/{sales,hr,web}

2. Set the group ownership of each directory to the group with the matching name.

for GROUP in sales hr web
do
　　chgrp $GROUP /depts/$GROUP
done

3. Check the permissions on the /depts directory to verify that everyone can access, but not write to the directory. Change the permissions on each each subdirectory to grant full permissions (rwx) to the group and deny access to others.

a. [root@stationX]# ls -ld /depts
drwxr-xr-x 5 root root 4096 May 4 06:04 /depts

b. [root@stationX]# chmod g=rwx,o= /depts/*

-OR-

[root@stationX]# chmod 770 /depts/*

4. Files created within those directories should be owned by the appropriate group. Set the appropriate permissions.

[root@stationX]# chmod g+s /depts/*

5. Experiment by logging in as each user and creating or altering files in each of the directories. Only manager should be able to enter all the directories.

The easiest way is probably su -, but make sure to include the dash and to exit one su session before starting another.

[root@stationX]# su - joshua
[joshua@stationX]$ touch /depts/sales/test
[joshua@stationX]$ exit
[root@stationX]# su - alex
[alex@stationX]$ touch /depts/sales/test
[alex@stationX]$ exit
[root@stationX]# su - dax
[dax@stationX]$ touch /depts/hr/test
[dax@stationX]$ exit
[root@stationX]# su - bryan
[bryan@stationX]$ touch /depts/hr/test
[bryan@stationX]$ exit
[root@stationX]# su - zak
[zak@stationX]$ touch /depts/web/test
[zak@stationX]$ exit
[root@stationX]# su - ed
[ed@stationX]$ touch /depts/web/test
[ed@stationX]$ exit
[root@stationX]# su - manager
[manager@stationX]$ touch /depts/sales/test
[manager@stationX]$ touch /depts/hr/test
[manager@stationX]$ touch /depts/web/test
[manager@stationX]$ exit

Sequence 3: Access Control Lists

Scenario: Some data needs to be accessible to several groups. Use ACLs to accomplish this.

Deliverable: Directories accessible by several groups and users.

System Setup: Note: The /depts/ directory is part of the / partition. Since this partition was created during installation it automatically includes the acl mount option. Filesystems created after installation must be specifically mounted with the acl option. See the “Filesystem Management” unit for details.

Instructions:

1. Create a new directory in /depts/ called tech. Change the permissions such that root
is the owner and hr is the group. Give full access to the user and group, and no access to
anyone else. Don't forget to set the SGID bit.

a. [root@stationX]# mkdir /depts/tech/

b. [root@stationX]# chown root:hr /depts/tech/

c. [root@stationX]# chmod 2770 /depts/tech/

2. Use ACLs to give full permission for /depts/tech/ to the additional web group.

a. setfacl -m g:web:rwx /depts/tech/

3. Allow alex read/execute (but not write) permission on the /depts/tech/ directory. Set a default ACL of read/write for alex on that directory.

a. [root@stationX]# setfacl -m u:alex:rx /depts/tech/

b. [root@stationX]# setfacl -m d:u:alex:rw /depts/tech/

4. Create some files in /depts/tech/ as several of the users and verify access. Does alex or joshua have access to files? Does manager?

a. [root@stationX]# su - joshua
[joshua@stationX]$ touch /depts/tech/joshua
touch: cannot touch `/depts/tech/joshua': Permission denied
[joshua@stationX]$ exit

[root@stationX]# su - manager
[manager@stationX]$ touch /depts/tech/manager
[manager@stationX]$ getfacl /depts/tech/manager
... output truncated ...
[manager@stationX]$ exit

[root@stationX]# su - alex
[alex@stationX]$ touch /depts/tech/manager
[alex@stationX]$ touch /depts/tech/alex
touch: cannot touch `/depts/tech/alex': Permission denied
[alex@stationX]$ exit

Sequence 4: Understanding Security Context

Scenario: A set of files need to be migrated to the webserver and made to operate within the SELinux framework.

Deliverable: A webserver with three viewable pages.

Instructions:

1. Install the httpd package and test that the webserver is displaying pages.

Use yum to install httpd.

[root@stationX]# yum install httpd -y
... output truncated ...

Start the service:

[root@stationX]# chkconfig httpd on
[root@stationX]# service httpd start
Starting httpd: [ OK ]

You could test the server with Firefox, but elinks might be faster.

[root@stationX]# elinks -dump http://localhost | head
Red Hat Enterprise Linux Test Page
... output truncated ...

2. Ensure SELinux is in the Enforcing mode.

[root@stationX]# setenforce 1
[root@stationX]# getenforce
Enforcing

3. Create a user account named student on your system.

[root@stationX]# useradd student

4. In student's home directory create a file named home.html containing a line that reads "home directory". Also, create a file in /tmp named tmp.html containing a line that reads "temporary directory". Inspect each file's security context.

[root@stationX]# echo "home directory" > /home/student/home.html
[root@stationX]# echo "temporary directory" > /tmp/tmp.html

Inspect each file's security context.

[root@stationX]# ls -Z /home/student/home.html
-rw-r--r-- root root root:object_r:user_home_t home.html
[root@stationX]# ls -Z /tmp/tmp.html
-rw-r--r-- root root root:object_r:tmp_t tmp.html

Notice that home.html and tmp.html have different type elements in their security context.

5. Standard Apache webserver configuration does not allow access to the home or temporary directories. Move home.html to the server's default directory: /var/www/html. Investigate the file's security context.

[root@stationX]# mv /home/student/home.html /var/www/html
[root@stationX]# ls -Z /var/www/html
-rw-r--r-- root root root:object_r:user_home_t home.html

Notice that security context information was maintained during the move.

6. Attempt to view the webpage with the command:

# elinks -dump http://localhost/home.html

You should be forbidden from viewing the page. Change SELinux to the Permissive mode and try again.

Change SELinux to the Permissive mode and try again.

[root@stationX]# setenforce 0
[root@stationX]# elinks -dump http://localhost/home.html
home directory

7. Return SELinux to the Enforcing mode. Copy tmp.html to /var/www/html and investigate the security context. Attempt to view the webpage.

[root@stationX]# setenforce 1

Copy tmp.html to /var/www/html and investigate the security context. Attempt to view the webpage.

[root@stationX]# cp /tmp/tmp.html /var/www/html
[root@stationX]# ls -Z /var/www/html
-rw-r--r-- root root root:object_r:user_home_t home.html
-rw-r--r-- root root root:object_r:httpd_sys_content_t tmp.html
[root@stationX]# elinks -dump http://localhost/tmp.html
temporary directory

Since /var/www/html/tmp.html is a new file (a copy of the original) it inherited the security context of the parent directory. Since it has the correct context, the httpd process can view the file.

8. Use restorecon to correct the context of the home.html file. Use elinks to test your fix.

[root@stationX]# restorecon /var/www/html/home.html
[root@stationX]# ls -Z /var/www/html
-rw-r--r-- root root root:object_r:httpd_sys_content_t home.html
-rw-r--r-- root root root:object_r:httpd_sys_content_t tmp.html
[root@stationX]# elinks -dump http://localhost/home.html
home directory

Sequence 5: Client-side NIS account management

Scenario: Your site is centrally managing user account information in a NIS directory service on 192.168.0.254, using the NIS domain name notexample. Set up your client to get user information from NIS, authenticating users with the NSS information provided by the NIS server.

Note: Home directories for these users are exported through NFS to all workstations as well. You can set up the automounter to automatically mount and unmount these directories as needed. Automounter is covered in the Filesystem Management unit and the lab in that unit will have us configure this.

Deliverable: Your system configured as an NIS client.

Instructions:

1. Install the necessary RPMs on your system if they are not already installed. For example, to test for portmap, you can run rpm -q portmap.

The RPMS are:

• portmap
• ypbind
• yp-tools
• authconfig
• authconfig-gtk

2. Configure your client to use NIS for authentication. Use notexample as the domain and 192.168.0.254 as the server.

If you are using the graphical interface, check the option Enable NIS Support on the User Information tab. You can leave the Authentication tab alone. Click the Configure NIS... button, and in the NIS Settings window specify notexample for the NIS Domain and server1.example.com for the NIS Server. Click on the OK button for the NIS Settings window, and again on the main window.

If you are using a (text-based) virtual console or the authconfig-tui command, then under User Information check Use NIS. Under Authentication leave Use MD5 Passwords and Use Shadow Passwords checked. Then select the Next button, and on the next screen specify notexample for Domain and 192.168.0.254 for Server. Select Ok.

Either way, ypbind should now start up successfully. If it does not, check the configuration
for misspellings, or /var/log/messages for errors.

3. Restart the sshd service to make sure that it registers the changes to authentication. You can test NIS with the user guest20XX (where XX is a two-digit version of your station number), and a password of password. ssh should succeed, but display an error message about the missing home directory.

a. [root@stationX]# service sshd restart

b. Try to ssh into your system as guest20XX. The password for this account is password.

[root@stationX]# ssh guest20XX@stationX.example.com

c. The ssh command should succeed, but display an error message about the missing home directory. This could be fixed by using automounter.

Sequence 6: Client-side LDAP account management

Scenario: Your site is migrating new user account information into an LDAP directory service, also served by server1.example.com under the search base dc=example,dc=com. The administrator of the LDAP server requires clients to use TLS (SSL) encryption, and the LDAP server's TLS certificate is digitally signed by a locally-run TLS Certificate Authority so that clients may verify that they are communicating with the real LDAP server.

Using TLS encryption, set up your client system to get user information and authenticate users using the LDAP server. Home directories for these LDAPmanaged users use the same NFS export as your old NIS-managed users, so you will not have to make any changes to your automounter configuration.

Deliverable: Your system configured as an LDAP client. Since we are in transition, leave the NIS Client configuration active from the previous lab.

Instructions:

1. Install the necessary RPMs on your system. Your system should already have the authconfig and authconfig-gtk. Several RPMs are needed for LDAP: openldap, openldap-clients, and nss_ldap.

# yum install -y openldap openldap-clients nss_ldap

2. Use system-config-authentication to configure your client to use LDAP for user information and authentication. Do not disable the NIS Client configuration from the previous lab sequence. The LDAP server is server1.example.com. The Search Base DN is: dc=example,dc=com. The server is only available via TLS. You will need to Download CA Certificate from the following URL:

ftp://server1/pub/EXAMPLE-CA-CERT

Use system-config-authentication to configure your client to use LDAP for user information and authentication. In the graphical interface, on the User Information tab check Enable LDAP Support. Switch to the Authentication tab and also check Enable LDAP Support.

Select the Configure LDAP... button on either tab. On the window that opens, set your LDAP Search Base DN to dc=example,dc=com. Set your LDAP Server to server1.example.com.

Using TLS is critical for security if you enable LDAP on the Authentication tab, because the PAM module used for LDAP will send passwords as cleartext over the network to the directory server on each authentication if this is not selected. Finally, press the Download CA Certificate button and enter the following in the Certificate URL:

ftp://server1/pub/EXAMPLE-CA-CERT

Note: If you do not add the certificate, you will notice the warning box about the missing
certificate file.

3. Restart the sshd service to make sure that it registers the changes to authentication. You can use the user account ldapuserX with a password of password for testing.

# service sshd restart

# ssh ldapuserX@stationX.example.com

4. If you see any errors, look at the logs in /var/log/messages and /var/log/secure. You can also try running the command ldapsearch -x -Z, which should dump user information in LDIF format from your LDAP server to standard output if the server is reachable.

TLS can be tested with openssl s_client. See s_client(1) for details.

a. [root@stationX]# openssl s_client -connect server1.example.com:636