Difference between revisions of "Manual Testing"

Revision as of 07:39, 7 October 2009

This page describes manual testing procedures. There are two reasons these exist:

1. Manual testing is sometimes simpler than running an automated test and instrumenting it.
2. In some cases we have a manual testing procedure for part of the code, but not an automated test.

Basic Test KDC Setup

Test KDCs are a crucial building block of testing. You can do so as follows:

1. Pick a name for your test KDC; this example will assume EXAMPLE.COM.

2. Do a build and install of the krb5 sources into some prefix; this example will assume /usr/local, but anywhere is fine. Put the prefix's bin and sbin directories in your path, or use full pathnames for the commands below.

3. Pick two port numbers, for the KDC and admin server. This example will assume 50000 and 50001.

4. Set up a krb5.conf file somewhere; this example will assume /usr/local/etc/krb5.conf. Make it look something like:

 [libdefaults]
   default_realm = EXAMPLE.COM
   # Depending on what you are testing, you may want something like:
   # default_keytab_name = FILE:/usr/local/var/keytab
 [realms]
   EXAMPLE.COM = {
     admin_server = 127.0.0.1:50001
     kdc = 127.0.0.1:50000
     database_module = DB2
     kdc_ports = 50000
     kadmind_port = 50001
   }
 [dbmodules]
   DB2 = {
     db_library = db2
   }
 [logging]
   # Use any pathnames you want here.
   kdc = FILE:/usr/local/var/krb5kdc/kdc.log
   admin_server = FILE:/usr/local/var/krb5kdc/kadmin.log
 # Depending on what you are testing, you may want:
 # [domain_realm]
 #   .your.domain = EXAMPLE.COM

Set the environment variable KRB5_CONFIG to the pathname of this krb5.conf file. Set the environment variable KRB5_KDC_PROFILE to /dev/null.

5. Run:

 kdb5_util create -s

Enter a master password; it can be something insecure like "master". The DB will be created in /usr/local/var/krb5kdc/principal and a few other similarly-named files. The master key stash will be created in /usr/local/var/krb5kdc/.k5.EXAMPLE.COM.

6. Run:

 kadmin.local
 addprinc user
 quit

Enter a user password; it can be something insecure like "user".

7. Start the KDC by running:

 krb5kdc

Check the log file specified in krb5.conf if the KDC has any trouble starting. You should be able to "kinit user" at this point.

8. If you need kadmind, add another principle user/admin (using kadmin.local as described above), and create the file /usr/local/var/krb5kdc/kadm5.acl containing:

 user/admin *

Then start the kadmind server with:

 kadmind

If it has trouble starting, check the log file specified in krb5.conf.

Services4User testing

A test for Services4User can be found in tests/gssapi/t_s4u.c. You will need a W2K3 or higher AD domain to test this. Notes follow:

• Create a computer account FOO$ using Active Directory Users & Computers (ADUC)
• Set the UPN to host/foo.domain (no suffix); this is necessary to be able to send an AS-REQ as this principal, otherwise you would need to use the canonical name (FOO$), which will cause principal comparison errors in gss_accept_sec_context() (note: apparently only W2K8 supports suffix-less UPNs; you should use the domain as a suffix for earlier versions). There is an attribute editor in the W2K8 ADUC that lets you do this, otherwise you will need to use LDP.exe or a generic LDAP client.
• Add a SPN of host/foo.domain. (Again, you can use ADUC in W2K8, or LDP.exe/generic client.)
• Configure the computer account to support constrained delegation with protocol transition (Trust this computer for delegation to specified services only / Use any authentication protocol)
• Add host/foo.domain to the keytab (possibly easiest to do this manually with ktadd)

For S4U2Proxy to work the TGT must be forwardable too.

kinit -k -t test.keytab -f 'host/test.win.mit.edu@WIN.MIT.EDU'
./t_s4u delegtest@WIN.MIT.EDU HOST/winhost.win.mit.edu@WIN.MIT.EDU test.keytab

In the above example delegtest@WIN.MIT.EDU is the principal on whose behalf credentials are acquired using S4U2Self; HOST/winhost.win.mit.edu is the host to which we wish to delegate using S4U2Proxy; and test.keytab contains the long term key for test.win.mit.edu.

To test S4U2Self with the MIT KDC, set the ok_to_auth_as_delegate attribute on the service principal using kadmin.

GSS-API Naming Extensions testing

Note: the S4U test also tests the GSS-API naming extensions, but there also is a specific test in tests/gssapi/t_namingexts.c. This tests the following APIs:

• gss_import_name() with composite names
• gss_inquire_name()
• gss_get_name_attribute()
• gss_set_name_attribute()
• gss_delete_name_attribute()
• gss_export_name_composite()
• gss_map_name_to_any
• gss_release_any_name_mapping

Note: gss_display_name_ext() is not tested because we don't yet have a concrete implementation of it.

The usage of this test is:

t_namingexts [--spnego] [principal] [keytab]

where the optional --spnego argument uses the SPNEGO (as opposed to the krb5) mechanism; principal is the service principal to test with, and keytab is a path to the keytab containing the key for the service principal. (The client and service principal are identical in the test. To test with another client principal, use the S4U test.)

You likely want to test this against a Windows KDC, in order to validate PAC introspection; however, you can also test with the greet_client (and greet_server) plugins that are included in plugins/authdata/greet_{client,server}.

Principal lockout testing

Testing for lockout is identical for the LDAP and DB2 backends, although if you wish to test the replication functionality, you'll need to use a DB2 backend. No changes are required for configuring kprop/iprop; it's business as usual (the only difference being that lockout-related attributes will not be replicated, so as part of testing you should verify on each KDC that this is the case).

First, you need to create a password policy that specifies a lockout policy. Do this with kadmin. Here we create a policy where a maximum failure count of 3, a failure count reset interval of 180 seconds, and a lockout duration of 60 seconds.

kadmin: addpol -maxfailure 3 -failurecountinterval 180 -lockoutduration 60 lockout_test

Then, you need to associate a principal with the lockout policy. Note also that the pre-authentication required attribute must be set on the principal; principals without this attribute set are not subject to the lockout policy (as they are not required to prove knowledge of their long-term key to the KDC).

kadmin:  modprinc -policy lockout_test +requires_preauth lukeh
Principal "lukeh@MIT.DE.PADL.COM" modified.

Now, perform a successful authentication with kinit. You should see the last successful authentication timestamp updated in the information returned by kadmin:

kadmin: getprinc lukeh
...
Last successful authentication: Wed Oct 07 14:07:08 CEST 2009

Perform an unsuccessful authentication (ie. kinit with an incorrect password) and you should see the failed authentication timestamp and count updated:

kadmin: getprinc lukeh
...
Last failed authentication: Wed Oct 07 14:07:58 CEST 2009
Failed password attempts: 1
Account locked time: [never]

Another two authentication failures (recall, the maximum failure count above is 3) and you should see that the principal is locked out:

kadmin: getprinc lukeh
...
Last failed authentication: Wed Oct 07 14:08:37 CEST 2009
Failed password attempts: 3
Account locked time: Wed Oct 07 14:08:37 CEST 2009

You can try to unlock the account explicitly with modprinc -unlock, or you can wait the lockout duration (here, 60 seconds) and you should be able to authenticate again.