Bookmark this page

Guided Exercise: The System Security Services Framework

Modify the PAM configuration and review the effects, use command-line tools to interact with SSSD, and review the changes that the authselect command implements.

Outcomes

  • Interact with the pluggable authentication modules (PAM) stack and review authselect usage.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command prepares your environment and ensures that all required resources are available.

[student@workstation ~]$ lab start technology-sssd

Instructions

  1. Log in to the client machine as the student user and become the root user.

    [student@workstation ~]$ ssh student@client
    [student@client ~]$ sudo -i
    [sudo] password for student: student
  2. Review the PAM rules for the sshd daemon.

    1. Review the /etc/pam.d/sshd file.

      Note that the sshd daemon uses the system default stack for authentication.

      [root@client ~]# cat /etc/pam.d/sshd
      ...output omitted...
      auth       substack     password-auth
      ...output omitted...
    2. Review the auth section in the /etc/pam.d/password-auth file.

      Note the sufficient control for the pam_unix module. If the module returns PAM_SUCCESS, no further rules are processed.

      [root@client ~]# cat /etc/pam.d/password-auth
      ...output omitted...
      auth        sufficient    pam_unix.so nullok
      ...output omitted...
    3. Review the pam_unix man page command to determine what the nullok argument does.

      [root@client ~]# man 8 pam_unix
      ...output omitted...
      
             nullok
                 The default action of this module is to not permit the user access to a service if their official password is
                 blank. The nullok argument overrides this default.
      
      ...output omitted...
  3. Create the demo user, but do not set a password. Try to log in to the client machine as the demo user.

    1. Create the demo user with default parameters.

      [root@client ~]# useradd demo
    2. From a second terminal window on the workstation machine, log in to the client machine as the demo user.

      Because the PAM configuration includes the nullok argument, you should gain access with an empty password. After successfully logging in, exit the client machine in the second terminal window.

      [student@workstation ~]$ ssh demo@client
      Register this system with Red Hat Insights: insights-client --register
      Create an account or view all your systems at https://red.ht/insights-dashboard
      [demo@client ~]$ exit
      Connection to client closed.
      [student@workstation ~]$
  4. From the first terminal session still open to the client machine, edit the /etc/pam.d/password-auth file to remove the nullok argument and add try_first_pass. Try to log in to the client machine again as the demo user.

    1. Edit /etc/pam.d/password-auth to remove the nullok argument. The resulting line should match the following example.

      [root@client ~]# cat /etc/pam.d/password-auth
      ...output omitted...
      auth        sufficient    pam_unix.so try_first_pass
      ...output omitted...
    2. From the second terminal window on the workstation machine, try to log in to the client machine again as the demo user.

      [student@workstation ~]$ ssh demo@client
      Register this system with Red Hat Insights: insights-client --register
      Create an account or view all your systems at https://red.ht/insights-dashboard
      [demo@client ~]$ exit
      Connection to client closed.
      [student@workstation ~]$
    3. On the first terminal session, review the /var/log/secure log file to determine why removing the nullok argument did not succeed in denying access with a null password.

      Log entries show that access was granted because SSH key authentication bypassed the password check.

      ...output omitted...
      Jan 20 07:09:07 client sshd[1692]: Accepted publickey for demo from 172.25.250.9 port 33298 ssh2: RSA SHA256:...
      Jan 20 07:09:07 client systemd[1696]: pam_unix(systemd-user:session): session opened for user demo(uid=1003) by (uid=0)
      Jan 20 07:09:07 client sshd[1692]: pam_unix(sshd:session): session opened for user demo(uid=1003) by (uid=0)
      Jan 20 07:09:10 client sshd[1705]: Received disconnect from 172.25.250.9 port 33298:11: disconnected by user
      ...output omitted...
    4. On the second terminal session, review the /home/student/.ssh/config file on the workstation machine.

      The lab_rsa key is used to connect to all hosts. This key is part of this classroom environment to ease automated exercise configuration.

      Host *
      	IdentityFile ~/.ssh/lab_rsa
      	StrictHostKeyChecking no
    5. Try to log in to the client machine as the demo user, but force SSH to use password authentication only.

      Under this condition, the access fails.

      [student@workstation ~]$ ssh -o PubkeyAuthentication=no \
        -o PreferredAuthentications=password demo@client
      demo@client: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
    6. On the first terminal tab, review the /var/log/secure file entries on the client machine.

      Only one message references the failed login action.

      ... client sshd[1871]: Connection closed by authenticating user demo 172.25.250.9 port 58550 [preauth]
  5. Review the sssctl command information.

    1. On the second terminal tab, log in to the idm machine as the admin user, and become the root user.

      [student@workstation ~]$ ssh admin@idm
      [admin@idm ~]$ su -
      Password: redhat
      [root@idm ~]#
    2. Review the help for the sssctl command.

      [root@idm ~]# sssctl
      Usage:
      sssctl COMMAND COMMAND-ARGS
      
      Available commands:
      
      SSSD Status:
      * domain-list        	 List available domains
      * domain-status      	 Print information about domain
      * user-checks        	 Print information about a user and check authentication
      * access-report      	 Generate access report for a domain
      
      Information about cached content:
      * user-show          	 Information about cached user
      * group-show         	 Information about cached group
      * netgroup-show      	 Information about cached netgroup
      
      Local data tools:
      * client-data-backup 	 Backup local data
      * client-data-restore	 Restore local data from backup
      * cache-remove       	 Backup local data and remove cached content
      * cache-upgrade      	 Perform cache upgrade
      * cache-expire       	 Invalidate cached objects
      
      Log files tools:
      * logs-remove        	 Remove existing SSSD log files
      * logs-fetch         	 Archive SSSD log files in tarball
      * debug-level        	 Change SSSD debug level
      * analyze            	 Analyze logged data
      
      Configuration files tools:
      * config-check       	 Perform static analysis of SSSD configuration
      
      Certificate related tools:
      * cert-show          	 Print information about the certificate
      * cert-map           	 Show users mapped to the certificate
      
      Help options:
        -?, --help         	 Show this for a command
        --usage            	 Show brief usage message for a command
    3. List the domains that are configured in SSSD.

      [root@idm ~]# sssctl domain-list
      lab.example.com
    4. Review the cached information for the admin user. When finished, exit the idm system and close the terminal tab.

      [root@idm ~]# sssctl user-show admin
      Name: admin
      Cache entry creation date: 01/27/23 05:37:12
      Cache entry last update time: 01/27/23 05:37:12
      Cache entry expiration time: 01/27/23 07:07:12
      Initgroups expiration time: 01/27/23 07:07:12
      Cached in InfoPipe: No
      [root@idm ~]# exit
  6. In the first terminal window on the client machine, review the authselect command.

    1. List the available authselect profiles.

      [root@client ~]# authselect list
      - minimal	 Local users only for minimal installations
      - sssd   	 Enable SSSD for system authentication (also for local users only)
      - winbind	 Enable winbind for system authentication
    2. Review the examples for the sssd profile.

      [root@client ~]# authselect show sssd
      ...output omitted...
      
      EXAMPLES
      --------
      
      * Enable SSSD with sudo and smartcard support
      
        authselect select sssd with-sudo with-smartcard
      
      * Enable SSSD with sudo support and create home directories for users on their
        first login
      
        authselect select sssd with-mkhomedir with-sudo
    3. Review the authselect man page.

      [root@client ~]# man 8 authselect
      ...output omitted...
      
           test profile_id [options] [features]
               Print content of files generated by authselect without actually writing anything to system configuration.
      
               -a, --all
                   Print content of all files.
    4. Use the authselect test command to review the file changes that would be made with the sssd with-mkhomedir with-sudo PAM addition. Note the possible changes to the /etc/pam.d/password-auth file.

      [root@client ~]# authselect test -a sssd with-mkhomedir with-sudo
      ...output omitted...
      
      File /etc/pam.d/password-auth:
      auth        required                                 pam_env.so
      auth        required                                 pam_faildelay.so delay=2000000
      auth        [default=1 ignore=ignore success=ok]     pam_usertype.so isregular
      auth        [default=1 ignore=ignore success=ok]     pam_localuser.so
      auth        sufficient                               pam_unix.so nullok
      auth        [default=1 ignore=ignore success=ok]     pam_usertype.so isregular
      auth        sufficient                               pam_sss.so forward_pass
      auth        required                                 pam_deny.so
    5. Return to the workstation machine as the student user.

      [root@client ~]# exit
      [student@client ~]# exit
      Connection to client closed.
      [student@workstation ~]$

Finish

On the workstation machine, change to the student user home directory and use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish technology-sssd

Revision: rh362-9.1-4c6fdb8