Kerberos Testing Information

This document describes the testing of all aspects of the Kerberos V4 library release of Summer 95. This includes everything from building Kerberos on supported platforms to building and running client applications using the new libraries, as well as the testing of backward-compatibility of old clients.

The first step in this process is starting with a clean build machine of each platform. Currently supported platforms are:

The first step to the process is the creation of an install target directory \ATHENA with the following structure:

The platform-specific leaves are only necessary when building for the specified platform, but this is the structure assumed by the installation procedure below, so the paths to leaves in use should not change. The root of the tree can be placed anywhere you like, ATHENA is just a suggestion.

The new version of the library uses a configuration include file that allows a single MAKEFILE to be used for builds on all platforms for all libraries and clients, theoretically. The variables that need to be set for proper operation of this MAKEFILE scheme are:

This environment variable must contain a string denoting the target platform of the library or client being compiled. The string is one of DOS16, WIN16, WIN32, or OS2, as denoted in parentheses above in the list of available target libraries and clients.

This environment variable only needs to be set when compiling with the WIN32 target platform. Currently supported values for this value are i386 and ALPHA.

This environment variable is used by NMAKE INSTALL to copy the libraries and binaries to the correct location. It should be set to the directory name of the athena distribution root directory, e.g. d:\ATHENA.

This environment variable must have as one entry the directory containing CONFIGUR.MAK, most likely d:\ATHENA\INCLUDE. For WIN16 compiling, it must also have an entry containing DOSWIN16.MAK (provided with the distribution.) For WIN32 compiling, the variable must also have an entry containing NTWIN32.MAK (provided with MS VC++ 2.0 in the \MSVC20\INCLUDE directory.)

The INCLUDE environment variable should be purged of all links to old include directories, such as LOCALH. The include files were updated quite a bit this summer, and the current makefiles and source files are incompatible with the old includes.

Under DOS, the INCLUDE variable also needs to have a pointer to the Novell LAN WorkPlace programmer's toolkit include directory.

The environment variable should contain a pointer to the appropriate subdirectory of \ATHENA\LIB for the platform being developed for. This directory is used as a repository for the static libraries and import libraries for the specified platforms.

The source code distribution should be unzipped with paths preserved (using PKUNZIP -d or InfoZip's unzip) into any directory. This directory is referred to below as the "build directory."

The "standard build sequence" referred to below is the process undergone for most of the libraries and applications in the Kerberos release. The sequence consists of two steps:

Another NMAKE target available in most directories is NMAKE clean, a command that clears out the output directory for the current platform, allowing a complete recompilation of the targets.

Descriptions of available targets

This is the port of the Unix com_err utilities to the PC platform. The com_err library creates a global error code space that allows mappings of many error codes to string tables. It also allows for the installation of hooks for custom error handlers. It's installed into the appropriate subdirectory of ATHENA\LIB.

More information on com_err is given below in the com_err Programmer's Guide.

DES library
This is the DES encryption library. It's compiled into a static library. Except under DOS, it's linked into the Kerberos dynamic link library and exported from there. Under DOS, it's installed in ATHENA\LIB\DOS16.
Kerberos library
This is the Kerberos client library. Under DOS it's a static library in ATHENA\LIB\DOS16, while under other platforms it's a DLL with exports for the Kerberos API as well as the DES API. If you use the lsh_* APIs in this library, you must also have the Leash UI library compiled, since the Kerberos library now simply searches the Leash UI library for the new versions of these APIs.

Leash UI library
This is the new location for the user interface code, relocated from KRBV4WIN in preparation for the future possibility of inserting code to call Kerberos v5 APIs in the future, making one integrated interface for the two Security libraries in the future.

This library is currently only available under Win16 and Win32.

Command-line utilities
These utilities are KINIT, KLIST, KDESTROY, and KEXPIRE. These ticket handling programs get tickets, list them, destroy them, and check for valid ones, respectively.

These utilities are available on systems with command-line interfaces, namely DOS, Win32, and OS/2.

Leash is the standard GUI app to manage a user's Kerberos tickets. It's available for Win16 and Win32.

Build Instructions


The DOS Kerberos suite consists of a set of libraries and programs. These are, in the order they should be built:

Windows 16-bit

The Windows 16-bit Kerberos suite consists of a set of static libraries, dynamic link libraries, and programs. These are, in the order they should be built:


The Win32 Kerberos suite consists of a set of static libraries, dynamic link libraries, and programs, very much like the Win16 libraries. These are, in the order they should be built:


The OS/2 Kerberos suite consists of a set of static libraries, dynamic link libraries, and programs, very much like the other of the libraries. These are, in the order they should be built:

Expected Build Output

The following tree is the expected output of the build process described above. It is also a complete build environment for developing Kerberized applications. For an environment of user apps in the Kerberos distribution only, only the files marked with a '*' are necessary. There is no problem with copying only the files for the desired platform.

Testing Kerberos

The testing that the Kerberos libraries have undergone is enumerated here.
(_/ is supposed to be a stylized ASCII checkmark symbol)
(Left two columns blank indicate untested feature)
(** indicate a known bug)

Leash API

_/Leash_changepwd_dlg 		leash
_/Leash_kinit_dlg 		leash
_/Leash_kdestroy		leash
_/Leash_klist			leash
_/Leash_kinit			krbtest (via compatibility)
_/Leash_changepwd		krbtest (via compatibility)
_/Leash com_err items		leash
_/proper function of error 	TechMail
    messages (see known bugs)

Backwards compatibility of old Lsh API

_/Lsh_Enter_Password_Dialog	TechMail, TechNotify
_/Lsh_Change_Password_Dialog	krbtest
_/lsh_kinit			krbtest
_/lsh_kdestroy			krbtest
_/lsh_klist			TechMail
_/lsh_checkpwd			krbtest
_/lsh_changepwd			krbtest
_/proper loading and 		TechMail
    unloading of library
_/proper function of error 	TechMail
    messages (see known bugs)

New DES and string_to_key code

_/MIT password recognized	leash (shabby@ATHENA.MIT.EDU)
_/MIT password changed properly	leash (shabby@ATHENA.MIT.EDU)
_/CMU password recognized	leash (pbh@UMICH.EDU)
_/CMU password changed properly leash (pbh@UMICH.EDU)
    (used debugger to verify
    correct string_to_key used)
  Migration from CMU to MIT

Win32 port of Kerberos
_/com_err stuff

Win16 com_err testing

Loading leash alone

_/Incorrect password (krb error 62)
_/Cleartext password did not match key (kadm error 33)
_/Leash-specific error - tickets about to expire, with %b
    MessageBox attributes passed along

Using backward compatibility alone

_/Incorrect password (krb error 62)
_/Insecure password (kadm error 32)

Starting leash, then, while leash is running, starting techmail

See known bugs #2.

Known Bugs

See the Programmer's Guide for information on using these APIs in your own applications: