From Fedora Project Wiki

Revision as of 16:01, 14 February 2011 by Jcholast (talk | contribs) (Created page with '{{QA/Test_Case |description=Authentication testing. |setup= # Make sure you have a working FreeIPA server (see QA:Testcase_freeipav2_installation) # Make sure the CLI works a...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Description

Authentication testing.

Setup

  1. Make sure you have a working FreeIPA server (see QA:Testcase_freeipav2_installation)
  2. Make sure the CLI works as expected (see QA:Testcase_freeipav2_cli)

How to test

User

  1. To test authentication, we need to create a user first.
  2. To create a user, kinit (or log in) as the admin user and run: # ipa user-add --first=User --last=One user1 ------------------ Added user "user1" ------------------ User login: user1 First name: User Last name: One Full name: User One Display name: User One Initials: UO Home directory: /home/user1 GECOS field: user1 Login shell: /bin/sh Kerberos principal: user1@IPA.EXAMPLE.COM UID: 197600003 Then assign the initial password to the user. # ipa passwd user1 Password: Enter Password again to verify: ------------------------------------------ Changed password for "user1@IPA.EXAMPLE.COM" ------------------------------------------ A user1 will now be available, although its password must be changed at the first login. NOTE: ipa user-add does not create a home directory, so you may need to create it to test a user login later. pam_mkhomedir can also be configured to aid in automatic creation of local home directories.
  3. First kinit - Password Change Required
  4. When a user is created, or when an administrator resets a user password, a password change is required for security reasons. The user can change its password by running kinit. If a password needs to be changed, kinit will automatically invoke kpasswd to perform a password change on the fly. In the shell run: # kinit user1 Password for user1@IPA.EXAMPLE.COM: Password expired. You must change it now. Enter new password: Enter it again: The passwords will not be shown, the terminal will not output any character. You should use a password that meets the password policies or the password change may fail. A valid test password is 'Test1234' NOTE: Now you have a TGT for user1, if you need to perform administration tasks you will need to kinit as admin again.
  5. Password Doesn't Meet Policy Criteria
  6. Check password policies by trying to change the password for user1 and use a very short password like 'pwd': # kpasswd user1 Password for user1@IPA.EXAMPLE.COM: Enter new password: Enter it again: Password change rejected: Password change failed Err6: Password too short. Verify that you get the error above.
  7. Password Meets Policy Criteria
  8. Try again to change your password and use a password like 'freeipa1' to verify that it allows you to change the password if it is longer than 8 chars. # kpasswd user1 Password for user1@IPA.EXAMPLE.COM: Enter new password: Enter it again: Password changed.
  9. SSH Login - Password based
  10. Once you have a valid user with a valid password, test it can login using ssh. # ssh user1@localhost Password: Could not chdir to home directory /home/user1: No such file or directory NOTE: You will get the home directory warning if you have not created a home directory for the user. But the user will still be logged in.
  11. SSH Login - SSO Login
  12. Now log out and try again after a kinit: # kinit user1 Password for user1@IPA.EXAMPLE.COM: You should be logged in without being asked for a password by ssh. # ssh user1@server.ipa.example.com Last login: Tue Feb 8 12:59:44 2011 from server.ipa.example.com >
  13. Invalid Password
  14. Test that the system properly behaves wrt wrong passwords. Remove any cached credentials # kdestroy Try to login via ssh and use the wrong password: # ssh user1@server.ipa.example.com Password: Password: Password: user1@server.ipa.example.com's password: Permission denied, please try again. user1@server.ipa.example.com's password: Permission denied, please try again. user1@server.ipa.example.com's password: Received disconnect from 192.168.122.22: 2: Too many authentication failures for user1
  15. Account lockout
  16. By default a user can fail to authenticate only a few times. If a user fails to authenticate more times than the policy allows then the account is temporarily locked. (defaults should be 10 attempts and lock time 10min.) Run kinit and provide a wrong password until the KDC refuses to give you a try: # kinit user1 Password for user1@IPA.EXAMPLE.COM: kinit: Password incorrect while getting initial credentials . . . # kinit user1 kinit: Clients credentials have been revoked while getting initial credentials Once this happens, try again with the right password and make sure you are still denied a ticket. Then wait for the lock timeout and try again with the right password. Make sure you get credentials now. If you want to see details about the lockout you can show the user details with the --all switch (with admin user credentials). The attribute krbloginfailedcount will show the number of failed attempts. The attribute krblastfailedauth containes the date (in UTC) of the last failed account. The account will be unlocked 10 minutes after this date. # ipa user-show user1 --all dn: uid=user1,cn=users,cn=accounts,dc=ipa,dc=example,dc=com User login: user1 First name: User Last name: One Full name: User One Display name: User One Initials: UO Home directory: /home/user1 GECOS field: user1 Login shell: /bin/sh Kerberos principal: user1@IPA.EXAMPLE.COM UID: 197600003 GID: 197600003 Account disabled: False Member of groups: ipausers ipauniqueid: f52859a6-339f-11e0-896a-5254009ccfc2 krblastfailedauth: 20110208202243Z krblastpwdchange: 20110208175427Z krblastsuccessfulauth: 20110208193126Z krbloginfailedcount: 10 krbpasswordexpiration: 20110509175427Z krbpwdpolicyreference: cn=global_policy,cn=IPA.EXAMPLE.COM,cn=kerberos,dc=ipa,dc=example,dc=com mepmanagedentry: cn=user1,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, mepOriginEntry After you successfully logged in the krbloginfailedcount attribute should be 0, and krblastsuccessfulauth should be greater than krblastfailedauth
  17. Graphical Login
  18. Let's test a GDM login. Test on the server or on a client. To make sure GDM is properly set up to accept freeipa login I suggest running # init 3; sleep 2; init 5 In a root shell after ipa-client-install (or ipa-server-install) completes sucessfully. When using freeipa logins for the first time, you may have to select "other.." from the user selection list in GDM in order to enter a Freeipa user name. Enter your password and you should get into the Gnome Shell.
  19. Password Doesn't Meet Policy Criteria
  20. If the user is brand new or after an administrative password reset, at login the user should be asked to change the password. Let's reset a user's password to test this scenario. # ipa passwd psmith set something simple like freeipa123 Now go back to the GDM login screen an try to login. After the password is entered the user is asked to provide a new password, claiming the password is expired. The GDM prompt may ask you to re-enter your valid password as the first thing, so check carefully what it is asking before entering new passwords. Try to change to a simple password like 'password'. GDM should show messages that the password is not strong enough and refuse your attempts, ultimately bringing you back to the main login screen.
  21. Password Meets Policy Criteria
  22. Now try again using a good password. To make sure the password change is accepted use a password like: 'T3s7Pwd1'
  23. No Password Change Required
  24. Now logout from the gnome session, and log back in with the new password to make sure everything has worked successfully during the password change.
  25. Screen Lock and Unlock - KRB Ticket Exists
  26. When you are logged into the desktop, a kerberos credential cache is generated for you. Run klist to show it: $ klist Ticket cache: FILE:/tmp/krb5cc_197600003_HSvKtw Default principal: user1@IPA.EXAMPLE.COM Valid starting Expires Service principal 02/10/11 09:49:34 02/11/11 09:49:34 krbtgt/IPA.EXAMPLE.COM@IPA.EXAMPLE.COM renew until 02/11/11 09:49:37 Now, lock the screen with CTRL+ALT+L And unlock the screensaver using the user password. Run klist again: $ klist Ticket cache: FILE:/tmp/krb5cc_197600003_HSvKtw Default principal: user1@IPA.EXAMPLE.COM Valid starting Expires Service principal 02/10/11 10:00:02 02/11/11 10:00:02 krbtgt/IPA.EXAMPLE.COM@IPA.EXAMPLE.COM renew until 02/11/11 10:00:05 Verify that the Dates have changed meaning the krb TGT has been refreshed when the password was provided.

Expected Results

All the test steps should end with the specified results.