Kerberos for Windows 3.2 Beta 2

Release Notes

23 April 2007

Table of Contents


Overview

MIT Kerberos for Windows (KfW) is an integrated Kerberos release for Microsoft Windows operating systems. It includes the Kerberos v4 library, Kerberos v5 library version 1.4.4, Kerberos v5 GSS API library, Kerberos 524 library, KClient API library, Leash API library, Network Identity Manager, kinit/klist/kdestroy/krb524init/ms2mit/aklog command-line credentials managers, and an in-memory credentials cache.

Terminology

Kerberos v4 (also Kerberos 4 or Kerberos version 4) and Kerberos v5 (also Kerberos 5 or Kerberos version 5) refer to versions 4 and 5 of the Kerberos protocol. A protocol is a specification for how data is transmitted on a network.

Kerberos credentials and Kerberos tickets are the same thing.


What's New in Kerberos for Windows 3.2


System Requirements

Operating System

Kerberos for Windows 3.2 is designed for 32-bit versions of Windows 2000, XP, 2003, 2003 R2, Vista and WOW64 environments

Microsoft Redistributable DLLs

The following versions or newer of several freely redistributable Microsoft DLLs are required depending on the compiler release used to build the distribution.  The MIT distribution is built using the Microsoft Visual Studio .NET 2003 SP1 C/C++ compiler:

 

Filename

    

Version

    

Description

*

mfc71.dll

 

7.10.3077.0

 

MSVS.NET 2003 MFCDLL Shared Library - Retail Version

*

msvcr71.dll

 

7.10.3031.4

 

MSVS.NET 2003 Microsoft (R) C Runtime Library

*

msvcp71.dll

 

7.10.3077.0

 

MSVS.NET 2003 Microsoft (R) C Runtime Library

*

psapi.dll

 

4.0.1198.1

 

Process Status Helper [not used in Windows 95/98/98SE/ME]

The KfW Installer will install the DLLs marked by an asterisk.

To see what Microsoft products ship with which version of these DLLs, you can use the DLL Help Database.

If you are not using the installer and you are missing some of these DLLs, you can download the Microsoft Redistributable Components component from the MIT Kerberos download site and manually install each missing DLL.

Note: psapi.dll is also available by itself from the Microsoft Download Center.


Installation and Configuration

Binaries

Core Binaries

 

Filename

    

Description

 

krbv4w32.dll

 

Kerberos 4 library

 

krbcc32.dll

 

Kerberos credentials cache library -- required by Kerberos 4; used by Kerberos 5 for in-memory credentials cache

 

krbcc32s.exe

 

Kerberos credentials cache -- required by krbcc32.dll

 

kclnt32.dll

 

KClient library -- required by some Kerberos 4 applications (deprecated)

 

krb5_32.dll

 

Kerberos 5 library

 

krb524.dll

 

Kerberos 524 compatibility library

 

leashw32.dll

 

Exports Ticket Init and Change Password dialogs as well as registry get/set/reset functions for managing Leash configurations.  (Used by third party applications.)

 

xpprof32.dll

 

Kerberos 5 Profile Management library (required by leashw32.dll)

 

comerr32.dll

 

Kerberos 5 Common Error Library (required by Kerberos 5 and Leash32.exe)

 

gssapi32.dll

 

GSS API for Kerberos 5

 

wshelp32.dll

 

Winsock helper used by various things

 

kinit.exe

 

command-line app to get Kerberos credentials

 

klist.exe

 

command-line app to list Kerberos credentials

 

kdestroy.exe

 

command-line app to destroy Kerberos credentials

 

k524init.exe

 

command-line app to get Kerberos 4 credentials using Kerberos 5 credentials instead of a password

 

ms2mit.exe

 

command-line app to transfer Microsoft Kerberos v5 domain credentials into the MIT Kerberos v5 credentials cache.

Network Identity Manager Binaries

netidmgr.exe

Network Identity Manager main executable.

krb4cred.dll

Provides information to Windows about which versions of libraries should be associated with netidmgr.exe.

krb4cred_en_us.dll

Kerberos 4 credentials provider plugin.

krb5cred.dll

English (US) language resources for the Keberos 4 credentials provider.

krb5cred_en_us.dll

Kerberos 5 credentials provider and identity provider plugin.

nidmgr32.dll

English (US) language resources for the Kerberos 5 credentials provider.

It is recommended that all binaries be installed into a single directory in the user's PATH. Make sure that you do not have other Kerberos binaries in your PATH.  The default location is “%ProgramFiles%\MIT\Kerberos\bin”.

Locating Kerberos Configuration Files

The simplest configuration is to put the krb5.ini, krb.con, and krbrealm.con configuration files in the Windows directory (or in the same directory as the Kerberos DLLs).  The NSIS and WIX installers search for configuration files only in the Windows directory.

Kerberos 5

Kerberos 5 needs a single configuration file: krb5.ini. You can put it in the Windows directory;  or you can put it in the same directory as the DLL; or you can point to an arbitrary file by setting the KRB5_CONFIG environment variable.

Kerberos 4

Kerberos 4 needs two configuration files, typically called krb.con and krbrealm.con. You can put these files in the same directory as the DLL and everything should work. You can also set KRB4_KRB.REALMS or KRB4_KRB.CONF to override each file. Or you can set KRB4_CONFIG to force Kerberos 4 to look for both files in a particular directory. If you do none of these, this is where Kerberos 4 will search:

  1. %NDIR%\kerb\
  2. The current directory
  3. The Windows directory
  4. The Windows system directory
  5. The directory containing the executable file for the current task
  6. The directories in the path (*)
  7. The list of directories mapped in a network
  8. %NDIR%\
  9. %ETC%\

(*) Note: If you put the files in the DLL's directory, this part of the search is what will take you there. If you have another config file earlier in the search, that will take precedence, so be careful.

Modifying Kerberos Configuration Files

IMPORTANT: The Network Identity Manager can be used to manage the Kerberos 5 and Kerberos 4 configuration files. NetIDMgr enforces a requirement that the Realm, KDC, and Realm/DNS mapping information is equivalent for both Kerberos 4 and Kerberos 5.  If this is not true for your Realms, you should not use NetIDMgr to manage the configuration files.  Instead use a text editor such as Notepad.

Kerberos 5

See the krb5.conf (MIT website)section in the Kerberos v5 System Administrator's Guide (MIT website).

Kerberos 4

It is anticipated that most sites using Kerberos version 4 on Windows also will have an existing UNIX Kerberos infrastructure. For that reason, the format of the krb.con is identical to the UNIX krb.conf and the format of krbrealm.con identical to the UNIX krb.realms. For many users, the easiest way to configure these files for use at their local sites will be to ftp the corresponding files from a local UNIX machine that is already properly configured.

The krb.con file contains configuration information describing the Kerberos realm and the Kerberos key distribution center (KDC) servers for known realms.

krb.con contains the name of the local realm in the first line, followed by lines indicating realm/host entries. The first token is a realm name, and the second is a hostname of a host running a KDC for that realm. The words "admin server" following the hostname indicate that the host also provides an administrative database server which is contacted when changing a user's password. For example:

ATHENA.MIT.EDU
ATHENA.MIT.EDU kerberos.mit.edu admin server
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu admin server

If this were your krb.con file and you wanted to change the default local realm to CIT.CORNELL.EDU you would edit it to look like:

CIT.CORNELL.EDU
CIT.CORNELL.EDU kerberos.cit.cornell.edu admin server
ATHENA.MIT.EDU kerberos.mit.edu admin server
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu admin server

The krbrealm.con file is the host-to-Kerberos realm translation file. This provides a translation from a local hostname to the Kerberos realm name for the services provided by that host.

Each line of the translation file is in one the following forms (domain_name should be of the form .XXX.YYY, e.g., .LCS.MIT.EDU):

        host_name kerberos_realm
        domain_name kerberos_realm

If a hostname exactly matches the host_name field in a line of the first form, the corresponding realm is the realm of the host. If a hostname does not match any host_name in the file, but its domain exactly matches the domain_name field in a line of the second form, the corresponding realm is the realm of the host.

If no translation entry applies, the host's realm is considered to be the hostname's domain portion converted to uppercase.

Using DNS Lookups for Kerberos Configuration

What is it?

DNS lookups provide Kerberos the ability to determine the Kerberos Realm that a host belongs to and to find the servers associated with a given Realm by using the Domain Name Service instead of or in addition to local configuration files.

When are DNS Lookups used?

DNS lookups are used in either of these two circumstances:

To activate DNS lookups for Kerberos 4 when the krb.con file is present, add the following line to the file as a realm-to-host entry (usually to the end):

.KERBEROS.OPTION. dns

When DNS lookups are used, the first line in the krb.con file (which would contain the default realm) may be left blank to indicate that the default realm should be determined by a DNS lookup.

To activate DNS lookups for Kerberos 5 when the krb5.ini file is present, place:

dns_lookup_kdc = true
dns_lookup_realm = true

into the [libdefaults] section. If a "default_realm" entry is not provided, a DNS lookup will be performed to determine the default realm.

What entries go into the DNS?

Host to realm lookups are performed using DNS TXT records. Example records are:

_kerberos.yclept.kermit.columbia.edu.  IN TXT "KRB5.COLUMBIA.EDU"
_kerberos.columbia.edu.                IN TXT "CC.COLUMBIA.EDU"

Realm to server lookups are performed using DNS SRV records. Example records are:

_kerberos._udp.KRB5.COLUMBIA.EDU.    IN SRV 0 0 88      yclept.kermit.columbia.edu
_kerberos._tcp.KRB5.COLUMBIA.EDU.    IN SRV 0 0 0       .
_krb524._udp.KRB5.COLUMBIA.EDU.      IN SRV 0 0 4444   yclept.kermit.columbia.edu
_kerberos-iv._udp.KRB5.COLUMBIA.EDU. IN SRV 0 0 750     yclept.kermit.columbia.edu
_kerberos-adm._tcp.KRB5.COLUMBIA.EDU IN SRV 0 0 749     yclept.kermit.columbia.edu
_kpasswd._udp.KRB5.COLUMBIA.EDU      IN SRV 0 0 464     yclept.kermit.columbia.edu

A DNS SRV record which specifies a port of "0" and a hostname of "." indicates that the requested service is not available in the requested realm.

Services File

The Kerberos DLLs need to know what port to use to talk to the Kerberos server. Kerberos 4 now defaults to ports 750 (kerberos 750/udp kdc) and 751 (kerberos-master 751/tcp) if there are no kerberos or kerberos-master entries in the services file. Kerberos 5 also has proper defaults (port 88 with a fallback to 750) in case the services file is missing the entries for kerberos and kerberos-sec.

If your site uses non-standard ports, you will still need a services file appropriate for your site.

Ticket Cache

The default for both Kerberos 4 and 5 is to store credentials in memory.

You can specify the name of the ticket file and the directory in which it is stored via the environment variables KRBTKFILE (krb4) and KRB5CCNAME (krb5). The krb4 credentials are always stored in memory. In memory credential caches have a prefix of "API:" in front of the name.

There are also registry settings for these locations. Playing with Leash will reveal where they are (look in HKCU\Software\MIT\Kerberos4 and Kerberos5). You can set machine-wide values by playing with these settings in HKLM.

Kerberos 5 does support using file-based tickets, but their use is not recommend, as they are potentially less secure.

Date and Time Issues

Kerberos authentication uses time stamps as part of its protocol. When the clocks of the Kerberos server and your computer are too far out of synchronization, you cannot authenticate properly. Both the Kerberos server and the Kerberos client depend on having clocks that are synchronized within a certain margin. This margin is normally 5 minutes.

The date and time on the machine running Kerberos must be "accurately" set. If the date or time is off "too far", Kerberos authentication will not work.

You can synchronize your clock using Leash32. It allows you to set the name of the host to which you will synchronize. It saves this information in the registry (under HKCU\Software\MIT\Leash32 -- you can set machine-wide defaults in HKLM).

By default, the server that the libraries contact when synchronizing the time is time. The domain name has been left off on purpose. If local system administrators create a machine with a CNAME of time within the local domain the clients will contact this machine by default.

If local system administrators are opposed to doing this for some reason, you can edit the resource LSH_TIME_HOST in the leashw32.dll to the name appropriate for your local site. You can also edit the header files from the source distribution and recompile for your local site. However, this is not recommended. You can also tweak the registry setting Leash32 uses.

You can also avoid this problem by running a local, properly configured, NTP program on your machine.


Command Line Options

netidmgr

The command line options for netidmgr are:

--kinit, -i               only perform a kinit and then exit
--ms2mit, -import, -m     only perform a ms2mit import and then exit
--renew, -r               only perform a credential renewal and then exit
--destroy, -d             only perform a kdestroy and then exit
--autoinit, -a            perform a kinit if credential cache is empty
--exit, -x                shutdown any running instance of netidmgr

kinit

Usage: kinit [-5] [-4] [-V] [-l lifetime] [-s start_time]
        [-r renewable_life] [-f | -F | --forwardable | --noforwardable]
        [-p | -P | --proxiable | --noproxiable]
        [-A | --addresses | --noaddresses]
        [-v] [-R] [-k [-t keytab_file]]
        [-c cachename] [-S service_name] [principal]
 
    options:                                          valid with Kerberos:
   -5 Kerberos 5 (available)
   -4 Kerberos 4 (available)
      (Default behavior is to try Kerberos 5)
   -V verbose                                        Either 4 or 5
   -l lifetime                                       Either 4 or 5
   -s start time                                     5
   -r renewable lifetime                             5
   -f forwardable                                    5
   -F not forwardable                                5
   -p proxiable                                      5
   -P not proxiable                                  5
   -A do not include addresses                       5
   -v validate                                       5
   -R renew                                          5, or both 5 and 4
   -k use keytab                                     5, or both 5 and 4
   -t filename of keytab to use                      5, or both 5 and 4
   -c Kerberos 5 cache name                          5
   -S service                                        5, or both 5 and 4

klist

Usage: klist.exe [-5] [-4] [-e] [[-c] [-C] [-f] [-s] [-a [-n]]] [-k [-t] [-K]] [name]
 
        -5 Kerberos 5 (available)
        -4 Kerberos 4 (available)
           (Default is Kerberos 5)
        -c specifies credentials cache
   -C enumerates all credentials caches
        -k specifies keytab
           (Default is credentials cache)
        -e shows the encryption type
        options for credential caches:
                -f shows credentials flags
                -s sets exit status based on valid tgt existence
                -a displays the address list
                        -n do not reverse-resolve
        options for keytabs:
                -t shows keytab entry timestamps
                -K shows keytab entry DES keys

kdestroy

Usage: kdestroy.exe [-5] [-4] [-q] [-c cache_name]
        -5 Kerberos 5 (available)
        -4 Kerberos 4 (available)
           (Default is Kerberos 5 and Kerberos 4)
        -q quiet mode
        -c specify name of credentials cache

 


Building from Sources

Building KfW is supported on Windows 2000, Windows XP, Windows 2003 and Windows Vista.

First, make sure that you have a Microsoft Visual .NET 2003 C++ compiler or VS 2005, a recent release of the Microsoft Platform SDK (XP SP2 SDK should be used if Windows 2000 support is desired, the NTSecAPI.H file from the Vista SDK must be used in place of the XP SP2 SDK version if Vista MSLSA ccache extensions are to be supported), ActiveState Perl (build 820 is known to work), doxygen, sed, gawk, cat, and rm in your PATH. You can get sed, gawk, cat, and rm from the Cygwin distribution. Also make sure that your INCLUDE path includes the Microsoft Platform SDK before the Microsoft Visual C++ include files and that perl has been installed so that .pl files are automatically executed with perl. You will also need to be using the default system shell (cmd.exe) so that the Makefiles work properly.

A script to build, sign and package all the KfW distribution components is provided.  To use it:

See the usage (bkw.pl /?) and krb5/windows/build/bkw-automation.html for more details.


Notes on the NSIS Installer scripts

The Kerberos for Windows installer is built using the Nullsoft Scriptable Installation System Version 2.0.  The source files for the installer script are included as part of the KfW SDK component.  These include:

Edit

File Name

Description

N

kfw.nsi

Top level install script

N

kfw-fixed.nsi

script containing kfw install functions

N

utils.nsi

script containing general purpose nsis functions useful to other installers

Y

site-local.nsi

script containing site local definitions detailing how the distribution was compiled and where the source binaries are to be found

N

KfWConfigPage.ini

page layout information for the first configuration page

N

KfWConfigPage2.ini

page layout information for the second configuration page

N

licenses.rtf

Kerberos 5 and Kerberos for Windows License text

N

kfw.ico

Kerberos for Windows icon file

N

killer.cpp

Source code to executable used to terminate running programs during uninstall


To build an installer the site-local.nsi file must be modified to specify the appropriate values for the source files and type of installer you wish to build.

Name

Default Value

Description

KFW_TARGETDIR

 

path to directory containing the subdirectories (bin\i386, lib\i386, doc, inc, install) where the target files may be found

KFW_CONFIG_DIR

 

path to directory containing config files (krb5.ini, krb.con, krbrealm.con) to be bundled with installer

KFW_MAJORVERSION

3

Major Version number of the installed files

KFW_MINORVERSION

2

Minor Version number of the installed files

KFW_PATCHLEVEL

0000

Four digit patchlevel of the installed files

SAMPLE_CONFIG_REALM

ATHENA.MIT.EDU

Default realm specified in the bundled configuration files

HTTP_CONFIG_URL

 

Default URL for obtaining config files via HTTP

must define one of:

 

 

CL_1200

 

Indicator that MSVC 6.0 was used to build the binaries

CL_1300

 

Indicator that MSVS .NET was used to build the binaries

CL_1310

 

Indicator that MSVS .NET 2003 was used to build the binaries

CL_1400

 

Indicator that MSVS 2005 was used to build the binaries

define at most one of:

 

if neither are specified, a time stamped installer containing release versions of the runtime components.

RELEASE

 

Indicates that a release installer is being built.  Installer includes release versions of the runtime components.

DEBUG

 

Indicates that a debug installer is being built.  Installer includes debug versions of runtime components.

optional defines:

 

 

BETA

 

A numeric beta version number


To build an installer execute the following steps:

It is worth noting that the "makensis.exe" used to build the MIT distributed installer was built from the NSIS sources with three modifications to the NSIS\Source\exehead\config.h file:

The installer constructs the following registry keys for maintaining version and module specific information:

Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos
Class Name:        <NO CLASS>
Last Write Time:   1/15/2004 - 9:59 PM
Value 0
  Name:            InstallDir
  Type:            REG_SZ
  Data:            C:\Program Files\MIT\Kerberos
 
Value 1
  Name:            Installer Language
  Type:            REG_SZ
  Data:            1033
 
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Client
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Client\3.1
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
Value 0
  Name:            VersionString
  Type:            REG_SZ
  Data:            3.1
 
Value 1
  Name:            Title
  Type:            REG_SZ
  Data:            KfW
 
Value 2
  Name:            Description
  Type:            REG_SZ
  Data:            Kerberos for Windows
 
Value 3
  Name:            PathName
  Type:            REG_SZ
  Data:            C:\Program Files\MIT\Kerberos
 
Value 4
  Name:            Software Type
  Type:            REG_SZ
  Data:            Authentication
 
Value 5
  Name:            MajorVersion
  Type:            REG_DWORD
  Data:            0x2
 
Value 6
  Name:            MinorVersion
  Type:            REG_DWORD
  Data:            0x6
 
Value 7
  Name:            PatchLevel
  Type:            REG_DWORD
  Data:            0x0
 
Value 8
  Name:            AllowTGTSessionKeyBackup
  Type:            REG_DWORD
  Data:            0x1
 
Value 9
  Name:            AllowTGTSessionKeyBackupXP
  Type:            REG_DWORD
  Data:            0x1
 
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Client\CurrentVersion
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
Value 0
  Name:            VersionString
  Type:            REG_SZ
  Data:            3.1
 
Value 1
  Name:            Title
  Type:            REG_SZ
  Data:            KfW
 
Value 2
  Name:            Description
  Type:            REG_SZ
  Data:            Kerberos for Windows
 
Value 3
  Name:            PathName
  Type:            REG_SZ
  Data:            C:\Program Files\MIT\Kerberos
 
Value 4
  Name:            Software Type
  Type:            REG_SZ
  Data:            Authentication
 
Value 5
  Name:            MajorVersion
  Type:            REG_DWORD
  Data:            0x3
 
Value 6
  Name:            MinorVersion
  Type:            REG_DWORD
  Data:            0x0
 
Value 7
  Name:            PatchLevel
  Type:            REG_DWORD
  Data:            0x0
 
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Documentation
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Documentation\3.0
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
Value 0
  Name:            VersionString
  Type:            REG_SZ
  Data:            3.1
 
Value 1
  Name:            Title
  Type:            REG_SZ
  Data:            KfW
 
Value 2
  Name:            Description
  Type:            REG_SZ
  Data:            Kerberos for Windows
 
Value 3
  Name:            PathName
  Type:            REG_SZ
  Data:            C:\Program Files\MIT\Kerberos
 
Value 4
  Name:            Software Type
  Type:            REG_SZ
  Data:            Authentication
 
Value 5
  Name:            MajorVersion
  Type:            REG_DWORD
  Data:            0x3
 
Value 6
  Name:            MinorVersion
  Type:            REG_DWORD
  Data:            0x0
 
Value 7
  Name:            PatchLevel
  Type:            REG_DWORD
  Data:            0x0
 
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\Documentation\CurrentVersion
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
Value 0
  Name:            VersionString
  Type:            REG_SZ
  Data:            3.1
 
Value 1
  Name:            Title
  Type:            REG_SZ
  Data:            KfW
 
Value 2
  Name:            Description
  Type:            REG_SZ
  Data:            Kerberos for Windows
 
Value 3
  Name:            PathName
  Type:            REG_SZ
  Data:            C:\Program Files\MIT\Kerberos
 
Value 4
  Name:            Software Type
  Type:            REG_SZ
  Data:            Authentication
 
Value 5
  Name:            MajorVersion
  Type:            REG_DWORD
  Data:            0x3
 
Value 6
  Name:            MinorVersion
  Type:            REG_DWORD
  Data:            0x1
 
Value 7
  Name:            PatchLevel
  Type:            REG_DWORD
  Data:            0x0
 
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\SDK
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\SDK\3.0
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
Value 0
  Name:            VersionString
  Type:            REG_SZ
  Data:            3.1
 
Value 1
  Name:            Title
  Type:            REG_SZ
  Data:            KfW
Value 2
  Name:            Description
  Type:            REG_SZ
  Data:            Kerberos for Windows
 
Value 3
  Name:            PathName
  Type:            REG_SZ
  Data:            C:\Program Files\MIT\Kerberos
 
Value 4
  Name:            Software Type
  Type:            REG_SZ
  Data:            Authentication
 
Value 5
  Name:            MajorVersion
  Type:            REG_DWORD
  Data:            0x3
 
Value 6
  Name:            MinorVersion
  Type:            REG_DWORD
  Data:            0x1
 
Value 7
  Name:            PatchLevel
  Type:            REG_DWORD
  Data:            0x0
 
 
Key Name:          HKEY_LOCAL_MACHINE\SOFTWARE\MIT\Kerberos\SDK\CurrentVersion
Class Name:        <NO CLASS>
Last Write Time:   1/31/2004 - 3:47 AM
Value 0
  Name:            VersionString
  Type:            REG_SZ
  Data:            3.1
 
Value 1
  Name:            Title
  Type:            REG_SZ
  Data:            KfW
 
Value 2
  Name:            Description
  Type:            REG_SZ
  Data:            Kerberos for Windows
 
Value 3
  Name:            PathName
  Type:            REG_SZ
  Data:            C:\Program Files\MIT\Kerberos
 
Value 4
  Name:            Software Type
  Type:            REG_SZ
  Data:            Authentication
 
Value 5
  Name:            MajorVersion
  Type:            REG_DWORD
  Data:            0x3
 
Value 6
  Name:            MinorVersion
  Type:            REG_DWORD
  Data:            0x1
 
Value 7
  Name:            PatchLevel
  Type:            REG_DWORD
  Data:            0x0

 


Known Issues

Leashw32 API

The list of functions exported from Leashw32.dll which may be used by third party developers is specified below.  Every effort is made to ensure that these functions will remain backward compatible in future releases.  However, no effort is made to ensure that subsequent releases of Leashw32.dll will maintain consistent entry point values.  The header file describing these functions is located in the source tree at  pismere/athena/auth/leash/include/leashwin.h or in the SDK at inc/leash/leashwin.h.

Leash_kinit_dlg
Leash_kinit_dlg_ex
Leash_changepwd_dlg
Leash_changepwd_dlg_ex
Leash_kinit
Leash_kinit_ex
Leash_kdestroy
Leash_klist
Leash_checkpwd
Leash_changepwd
Leash_import
Leash_importable
Leash_renew
Leash_reset_defaults
Leash_timesync
Leash_get_default_lifetime
Leash_set_default_lifetime
Leash_reset_default_lifetim
Leash_get_default_renew_till
Leash_set_default_renew_till
Leash_reset_default_renew_till
Leash_get_default_forwardable
Leash_set_default_forwardable
Leash_reset_default_forwardable
 
Leash_get_default_renewable
Leash_set_default_renewable
Leash_reset_default_renewable
 
Leash_get_default_noaddresses
Leash_set_default_noaddresses
Leash_reset_default_noaddresses
 
Leash_get_default_proxiable
Leash_set_default_proxiable
Leash_reset_default_proxiable
 
Leash_get_default_publicip
Leash_reset_default_publicip
Leash_get_default_use_krb4
Leash_set_default_use_krb4
 
Leash_reset_default_use_krb4
Leash_get_default_life_min
Leash_set_default_life_min
Leash_reset_default_life_min
 
Leash_get_default_life_max
Leash_set_default_life_max
Leash_reset_default_life_max
 
Leash_get_default_renew_min
Leash_set_default_renew_min
Leash_reset_default_renew_min
 
Leash_get_default_renew_max
Leash_set_default_renew_max
Leash_reset_default_renew_max
 
Leash_get_lock_file_locations
Leash_set_lock_file_locations
Leash_reset_lock_file_locations
 
Leash_get_default_uppercaserealm
 
Leash_set_default_uppercaserealm
 
Leash_reset_default_uppercaserealm
 
Leash_get_default_mslsa_import
 
Leash_set_default_mslsa_import
 
Leash_reset_default_mslsa_import
 
Leash_get_default_preserve_kinit_settings
 
Leash_set_default_preserve_kinit_settings
 
Leash_reset_default_preserve_kinit_settings
 
Leash_get_lsh_errno
initialize_lsh_error_table
lsh_com_err_proc
Leash_initialize_krb_error_func
Leash_initialize_kadm_error_table
Leash_krb_err_func
Leash_load_com_err_callback
Leash_set_help_file
Leash_get_help_file

Registry and Environment Settings

Network Identity Manager Settings

Configuration options for Network Identity Manager (NetIDMgr) are stored in the Windows registry.  Each option can exist in the user registry hive or the machine registry hive or both.  The value defined in the user hive always overrides the value defined in the machine registry hive.  All registry keys used by NetIDMgr exist under the key Software\MIT\NetIDMgr under the user and machine hive. 

Common settings for NetIDMgr

The following sections describe a partial list of options that can be specified for NetIDMgr.  Each set of options is described as a set of registry values.  Each section is preceded by the registry key under which the values of that section must be specified.

General settings

    Registry key: 'Software\MIT\NetIDMgr\CredWindow'
    --------------
    Value   : AutoInit
    Type    : DWORD  (0 or 1)
    Default : 0
 
        If this value is '1', shows the new credentials dialog if
        there are no credentials when NetIDMgr starts.
 
    Value   : AutoImport
    Type    : DWORD  (0 or 1)
    Default : 1
 
        If '1', imports credentials from the Windows LSA cache when
        NetIDMgr starts.
 
    Value   : AutoDetectNet
    Type    : DWORD  (0 or 1)
    Default : 1
 
        If '1', automatically detects network connectivity changes.
        Network connectivity change notifications are then sent out to
        individual plug-ins which can perform actions such as renewing
        credentials or obtaining new credentials.
 
    Value   : DestroyCredsOnExit
    Type    : DWORD  (0 or 1)
    Default : 0
 
        If '1', all credentials will be destroyed when NetIDMgr exits.
 
    Value   : KeepRunning
    Type    : DWORD  (0 or 1)
    Default : 1
 
        If '1', when NetIDMgr application is closed, it will continue
        to run in the Windows System Notification Area (System Tray).
        The application can be exited by choosing the 'Exit' menu
        option.  If '0', closing the application will cause it to
        exit completely.
 

Common Plug-in settings

 
    Registry key: 'Software\MIT\NetIDMgr\PluginManager\Plugins\<plug-in name>'
    --------------
 
    The '<plug-in name>' is one of the following for the standard plug-ins :
 
    Krb5Cred : Kerberos 5 credentials provider
    Krb5Ident: Kerberos 5 Identity provider
    Krb4Cred : Kerberos 4 credentials provider
 
    Consult the vendors for the plug-in names of other third party
    plug-ins.  Additionally, the plug-ins configuration panel in the
    NetIDMgr application provides a list of currently registered
    plug-ins.
 
    Value   : Disabled
    Type    : DWORD (0 or 1)
    Default : 0
 
        If '1', the plug-in will not be loaded.
 
    Value   : NoUnload
    Type    : DWORD (0 or 1)
    Default : 0
 
        If '1', the plug-in will not be unloaded from memory when the
        NetIDMgr application exits or if the plug-in is stopped.  The
        plug-in binary will remain loaded until NetIDMgr terminates.
 

Settings for the Kerberos 5 credentials provider plug-in

 
    Registry key: 'Software\MIT\NetIDMgr\PluginManager\Plugins\Krb5Cred\Parameters'
    --------------
 
    Value   : CreateMissingConfig
    Type    : DWORD (0 or 1)
    Default : 0
 
        If '1', creates any missing configuration files.
 
    Value   : MsLsaImport
    Type    : DWORD (0, 1 or 2)
    Default : 1
 
        Controls how credentials are imported from the MSLSA cache.
        This setting can be one of the following.
 
        0 : Never
        1 : Always
        2 : Only if the principal matches
 
        Note that this setting only controls how the Kerberos 5
        plug-in handles importing of credentials from the MSLSA cache.
        Whether or not credentials are imported at start-up is
        controlled via general NetIDMgr settings as described in
        section 3.1.1.
 
    Value   : MsLsaList
    Type    : DWORD (0 or 1)
    Default : 1
 
        If '1', includes credentials from the MSLSA cache in the
        credentials listing.
 
    Value   : AutoRenewTickets
    Type    : DWORD (0 or 1)
    Default : 1
 
        If '1', automatically renews expiring tickets.  The thresholds
        at which renewals happen are controlled in general NetIDMgr
        settings.
 
    Value   : UseFullRealmList
    Type    : DWORD (0 or 1)
    Default : 0
 
        If '1', uses the full realms list as determined by parsing the
        krb5.ini configuration file in the new credentials dialog box.
        If this is '0', only the last recently used list of realms
        will be used.
 

Per-identity settings

 
    Registry key 1: 'Software\MIT\NetIDMgr\KCDB\Identity\<principal name>\Krb5Cred'
    Registry key 2: 'Software\MIT\NetIDMgr\PluginManager\Plugins\Krb5Cred\Parameters\Realms\<realm>'
    Registry key 3: 'Software\MIT\NetIDMgr\PluginManager\Plugins\Krb5Cred\Parameters'
    --------------
 
    These settings are generally maintained per-identity.  However, if
    a particular setting is not specified for an identity or if the
    identity is new, then the values will be looked up in the
    per-realm configuration key and in the global parameters key in
    turn.  Global defaults should be set in the global parameters key
    (key 3).
 
    Value   : DefaultLifetime
    Type    : DWORD
    Default : 36000
 
        Default ticket lifetime, in seconds.
 
    Value   : MaxLifetime
    Type    : DWORD
    Default : 86400
 
        Maximum lifetime, in seconds.  This value is used to set the
        range of the user interface controls that allow setting the
        lifetime of a ticket.
 
    Value   : MinLifetime
    Type    : DWORD
    Default : 60
 
        Minimum lifetime, in seconds.  This value is used to set the
        range of the user interface controls that allow setting the
        lifetime of a ticket.
 
    Value   : Forwardable
    Type    : DWORD (0 or 1)
    Default : 1
 
        Obtain forwardable tickets.
 
    Value   : Proxiable
    Type    : DWORD (0 or 1)
    Default : 0
 
        Obtain proxiable tickets.
 
    Value   : Addressless
    Type    : DWORD (0 or 1)
    Default : 1
 
        Obtain addressless tickets.
 
    Value   : Renewable
    Type    : DWORD (0 or 1)
    Default : 1
 
        Obtain renewable tickets.
 
    Value   : DefaultRenewLifetime
    Type    : DWORD
    Default : 604800
 
        Default renewable lifetime, in seconds.
 
    Value   : MaxRenewLifetime
    Type    : DWORD
    Default : 2592000
 
        Maximum renewable lifetime, in seconds.  The value is used to
        set the range of the user interface controls that allow
        setting the renewable lifetime of a ticket.
 
    Value   : MinRenewLifetime
    Type    : DWORD
    Default : 60
 
        Minimum renewable lifetime, in seconds.  This value is used to
        set the range of the user interface controls that allow
        setting the renewable lifetime of a ticket.
 

Settings for the Kerberos 4 Credentials Provider Plug-in

 
    Registry key 1: 'Software\MIT\NetIDMgr\KCDB\Identity\<principal name>\Krb4Cred'
    Registry key 2: 'Software\MIT\NetIDMgr\PluginManager\Plugins\Krb4Cred\Parameters'
    ---------------
 
    Theses settings are also maintained per identity.  However, if the
    setting is not specified for some identity or if the identity is
    new, then the global default will be used (registry key 2).
    Global defaults should be set in the second registry key.
 
    Value   : Krb4NewCreds
    Type    : DWORD (0 or 1)
    Default : 1
 
        If '1', obtains Kerberos 4 credentials.  Note that currently,
        only one identity can have Kerberos 4 credentials at one time.
 
    Value   : Krb4Method
    Type    : DWORD (0, 1 or 2)
    Default : 0
 
        Method for obtaining Kerberos 4 credentials.  The values are
        as follows:
 
        0 : Automatically determine method
        1 : Use password
        2 : Use Kerberos 5 to 4 translation
 
    Value   : DefaultLifetime
    Type    : DWORD
    Default : 36000
 
        The default ticket lifetime, in seconds.
 
    Value   : MaxLifetime
    Type    : DWORD
    Default : 86400
 
        Maximum lifetime, in seconds.  This value is used to set the
        range of the user interface controls that allow setting the
        lifetime.
 
    Value   : MinLifetime
    Type    : DWORD
    Default : 60
 
        Minimum lifetime, in seconds.  This value is used to set the
        range of the user interface controls that allow setting the
        lifetime.

Leash32 DLL

default lifetime ( minutes )

   1. Use LIFETIME environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,lifetime) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,lifetime) if present.
   4. Otherwise, use Kerberos 5 profile if present
   5. Otherwise, use resource string if present.
   6. Otherwise, default to 0.

default renew till time ( minutes )

   1. Use RENEW_TILL environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,renew_till) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,renew_till) if present.
   4. Otherwise, use Kerberos 5 profile if present
   5. Otherwise, use resource string if present.
   6. Otherwise, default to 0.

default renewable tickets setting ( 0 or 1 )

   1. Use RENEWABLE environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,renewable) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,renewable) if present.
   4. Otherwise, use Kerberos 5 profile if present
   5. Otherwise, use resource string if present.
   6. Otherwise, default to 0.

default forwardable tickets setting ( 0 or 1 )

   1. Use FORWARDABLE environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,forwardable) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,forwardable) if present.
   4. Otherwise, use Kerberos 5 profile if present
   5. Otherwise, use resource string if present.
   6. Otherwise, default to 1.

default addressless tickets setting ( 0 or 1 )

   1. Use Kerberos 5 profile setting (or default) if TRUE.
   2. Otherwise, use NOADDRESSES environment value if defined.
   3. Otherwise, use value from registry
      (HKCU\Software\MIT\Leash,noaddresses) if present.
   4. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,noaddresses) if present.
   5. Otherwise, use resource string if present.
   6. Otherwise, default to 1.

default proxiable tickets setting ( 0 or 1 )

   1. Use PROXIABLE environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,proxiable) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,proxiable) if present.
   4. Otherwise, use Kerberos 5 profile if present
   5. Otherwise, use resource string if present.
   6. Otherwise, default to 0.

default public ipv4 address ( unsigned long, network byte order )

   1. Use PUBLICIP environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,publicip) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,publicip) if present.
   4. Otherwise, use resource string if present.
   5. Otherwise, default to 0.

request kerberos iv tickets ( 0 or 1 )

   1. Use USEKRB4 environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,usekrb4) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,usekrb4) if present.
   4. Otherwise, use resource string if present.
   5. Otherwise, default to 0.

hide advanced kinit options in dialog ( 0 or 1 )

   1. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,hide_kinit_options) if present.
   2. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,hide_kinit_options) if present.
   3. Otherwise, use resource string if present.
   4. Otherwise, default to 0.

minimum kinit dialog lifetime ( minutes )

   1. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,life_min) if present.
   2. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,life_min) if present.
   3. Otherwise, use resource string if present.
   4. Otherwise, default to 5.maxmimum kinit dialog lifetime ( minutes )
   1. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,life_max) if present.
   2. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,life_max) if present.
   3. Otherwise, use resource string if present.
   4. Otherwise, default to 1440.

minimum kinit dialog renew till time ( minutes )

   1. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,renew_min) if present.
   2. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,renew_min) if present.
   3. Otherwise, use resource string if present.
   4. Otherwise, default to 600.

maximum kinit dialog renew till ( minutes )

   1. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,renew_max) if present.
   2. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,renew_max) if present.
   3. Otherwise, use resource string if present.
   4. Otherwise, default to 43200.

upper case realm:

   1. Use value from registry 
      (HKCU\Software\MIT\Leash32\Settings,uppercaserealm) if present.
   2. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash32\Settings,uppercaserealm) if present.
   3. Otherwise, use resource string if present.
   4. Otherwise, default to 1.

timesync host:

   1. Use TIMEHOST environment value if defined.
   2. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash32\Settings,timehost) if present.
   3. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash32\Settings,timehost) if present.
   4. Otherwise, use resource string if present.
   5. Otherwise, default to #defined value "time".

Preserve ticket initialization dialog options:

   1. Otherwise, use value from registry 
      (HKCU\Software\MIT\Leash,preserve_kinit_options) if present.
   2. Otherwise, use value from registry 
      (HKLM\Software\MIT\Leash,preserve_kinit_options) if present.
   4. Otherwise, use resource string if present.
   5. Otherwise, default to 0.

Kerberos 4:

A. location of krbrealm & krbconf:

   1. First, check for environment overrides:
      a. Use %KRB4_KRB.REALMS% as full filename for realms file if defined.
      a. Use %KRB4_KRB.CONF% as full filename for config file if defined.
      b. Otherwise, look for krbrealm.con and krb.con in dir %KRB4_CONFIG%.
   2. If nothing defined so far, look in registry:
      a. HKCU\Software\MIT\Kerberos4,krb.realms for realms full pathname.
      a. HKCU\Software\MIT\Kerberos4,krb.conf for config full pathname.
      b. HKCU\Software\MIT\Kerberos4,config as dir for both files.
      c. HKLM\Software\MIT\Kerberos4,krb.realms for realms full pathname .
      c. HKLM\Software\MIT\Kerberos4,krb.conf for config full pathname.
      d. HKLM\Software\MIT\Kerberos4,configdir as dir for both files.
   3. If any of the above are set, use it even if the files are not there.
      If none of them are set, use the old krb4 search.

B. ticket file

   1. %KRBTKFILE% if defined
   2. Registry setting, if setting is present
      (HKCU\MIT\Kerberos4,ticketfile)
   3. Registry setting, if setting is present
      (HKLM\MIT\Kerberos4,ticketfile)
   4. Otherwise, "API:krb4cc".
  (
   If a file-based cache is ever supported for Kerberos 4, code should do this:
   4. %TEMP%\ticket.krb, if var defined and dir exists
   5. %TMP%\ticket.krb, if var defined and dir exists
   6. c:\temp\ticket.krb if c:\temp exists
   7. c:\tmp\ticket.krb if c:\tmp exists
   8. GetWindowsDirectory()\ticket.krb as a last-ditch default?  It's
      either that or c:\ticket.krb!
   )Kerberos 5:

A. location of krb5.ini:

   1. %KRB5_CONFIG% if defined
   2. (HKCU\Software\MIT\kerberos5,config) if defined
   3. (HKCU\Software\MIT\kerberos5,config) if defined
   4. Otherwise, use GetWindowsDirectory()\krb5.ini

B. Default credentials cache name

   1. %KRB5CCNAME% if defined
   2. (HKCU\Software\MIT\kerberos5,ccname) if defined
   3. (HKLM\Software\MIT\kerberos5,ccname) if defined
   4. If RegKRB5CCNAME is set under [Files] in kerberos.ini,
      look at that path in the registry (code already in krb5 for compat
      with Gradient DCE installations, I believe).
   5. Otherwise, if using CCAPI, default to "API:krb5cc".
                 if no CCAPI, use "FILE:" with:
      a. %TEMP%\krb5cc, if var defined and dir exists
      b. %TMP%\krb5cc, if var defined and dir exists
      c. c:\temp\krb5cc if c:\temp exists
      d. c:\tmp\krb5cc if c:\tmp exists
      e. GetWindowsDirectory()\krb5cc as a last-ditch default?
         it's either that or c:\krb5cc!

C. MSLSA: credential cache client principal identity generation

   1. (HKCU\Software\MIT\Kerberos5,PreserveInitialTicketIdentity) if defined
   2. (HKLM\Software\MIT\Kerberos5,PreserveInitialTicketIdentity) if defined
   3. Default is 1.

 


 

Integration with Microsoft Kerberos LSA

As of the Kerberos v5 1.3.2 release, a new cache type, MSLSA:, has been added for use in accessing the Microsoft Kerberos Logon Session credentials cache.  The MSLSA: cache is available when the user logon is performed using Kerberos either to an Active Directory Domain or a non-Microsoft KDC.

Windows Vista: As of the Kerberos v5 1.6.0 release, the MSLSA: support contains functionality that permits the credentials cache to be read-write on Windows Vista.  Windows Vista places restrictions on the use of Kerberos tickets when the User Account Control (UAC) when the active account is a member of the local machine Administrators group.  In that situation, MSLSA: support is disabled.   Users are strongly encouraged to not login to Windows Vista using accounts that are members of the local machine Administrators group.

A user is able to logon to Windows using the Kerberos LSA if the machine is part of a Windows 2000 or Windows 2003 Active Directory domain or if the machine has been configured to authenticate to a non-Microsoft KDC such as MIT.  The instructions for configuring a Windows 2000 XP workstation to authenticate to a non-Microsoft KDC are documented in TechNet somewhere.  In brief:

  1. Install the Windows 2000 or XP support tools in order to obtain the tools: KSETUP.EXE and KTPASS.EXE.
  2. Install the Windows 2000 or XP Resource Kit to obtain the tools KERBTRAY.EXE and KLIST.EXE
  3. Add Realms and associated KDCs with: KSETUP /AddKdc <realm> [<kdcname>].  If you leave off the <kdcname> DNS SRV records will be used.
  4. Specify the password change service host for the realm with: KSETUP /AddKpasswd <realm> <Kpwdhost>
  5. Assign the realm of the local machine with: KSETUP /SetRealm <realm> where realm must be all upper case.
  6. Assign the local machine's password with: KSETUP /SetComputerPassword <Password>
  7. Specify the capabilities of the Realm KDC with: KSETUP /SetRealmFlags <realm> <flag> [<flag> ...] where flags may be None, SendAddress, TcpSupported, Delegate, or NcSupported,
  8. Map principal names to local accounts with: KSETUP /MapUser <principal> <account>

On the MIT KDC, you must then create service principals using the "Password" assigned to the machine.  So far the minimum list of principals required appear to be for a machine named "mymachine" in the realm "EXAMPLE.COM" with a domain name of "example.com":

There may very well be other services for which principals must be created depending on what services are being executed on the machine.

It is very important to note that while you can successfully log into a Windows workstation by authenticating to the KDC without creating a host key; the logon session you receive will not be a Kerberos Logon Session.  There will be no Kerberos principal and no LSA cache to access.

The result of a real KSETUP configuration looks like this:

 

   [C:\4\4NT]ksetup
   default realm = KRB5.COLUMBIA.EDU (external)
   ATHENA.MIT.EDU:
           kdc = kerberos.mit.edu
           kdc = kerberos-1.mit.edu
           kdc = kerberos-2.mit.edu
           kdc = kerberos-3.mit.edu
           Realm Flags = 0x0 none
   CC.COLUMBIA.EDU:
           kdc = kerberos.cc.columbia.edu
           Realm Flags = 0x0 none
   GRAND.CENTRAL.ORG:
           kdc = penn.central.org
           kdc = grand-opening.mit.edu
           Realm Flags = 0x0 none
   KRB5.COLUMBIA.EDU:
           kdc = yclept.kermit.columbia.edu
           Realm Flags = 0x0 none
   OPENAFS.ORG:
           kdc = virtue.openafs.org
           Realm Flags = 0x0 none
   Mapping jaltman@KRB5.COLUMBIA.EDU to jaltman.
   Mapping jaltman@CC.COLUMBIA.EDU to jaltman.
   Mapping jaltman@ATHENA.MIT.EDU to jaltman.
   Mapping all users (*) to a local account by the same name (*)

The MSLSA: credential cache relies on the ability to extract the entire Kerberos ticket including the session key from the Kerberos LSA.  In an attempt to increase security Microsoft has begun to implement a feature by which they no longer export the session keys for Ticket Getting Tickets. This has the side effect of making them useless to the MIT krb5 library when attempting to request additional service tickets.

This new feature has been seen in Windows 2003 Server, Windows 2000 Server SP4, and Windows XP SP2.  We assume that it will be implemented in all future Microsoft operating systems supporting the Kerberos SSPI.  Microsoft does work closely with MIT and has provided a registry key to disable this new feature.

  HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
    AllowTGTSessionKey = 0x01 (DWORD)

On Windows XP SP2 the key is specified as

  HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos
    AllowTGTSessionKey = 0x01 (DWORD)

It has been noted that the Microsoft Kerberos LSA does not provide enough information within its KERB_EXTERNAL_TICKET structure to properly construct the Client Principal simply by examining a single ticket.  From the MSDN Library:

ClientName
    KERB_EXTERNAL_NAME structure that contains the client name in the ticket.     This name is relative to the current domain.

DomainName
    UNICODE_STRING that contains the name of the domain that corresponds to the ServiceName member. This is the domain that issued the ticket.

 

TargetDomainName
    UNICODE_STRING that contains the name of the domain in which the ticket is valid. For an interdomain ticket, this is the destination domain.

AltTargetDomainName
    UNICODE_STRING that contains a synonym for the destination domain. Every domain has two names: a DNS name and a NetBIOS name. If the name returned in the ticket is different from the name used to request the ticket (the Kerberos Key Distribution Center (KDC) may do name mapping), this string contains the original name.

Unfortunately, there is no field here which contains the domain of the client. In order for the krb5_ccache to properly report the client principal name, the client principal name is constructed by utilizing the ClientName and DomainName fields of the Initial TGT associated with the Kerberos LSA credential cache. To disable the use of the TGT info and instead simply use the "DomainName" field of the current ticket define one of the following registry keys depending on whether the change should be system global or just for the current user.

   HKLM\Software\MIT\Kerberos5\
      PreserveInitialTicketIdentity = 0x0 (DWORD)
   HKCU\Software\MIT\Kerberos5\
      PreserveInitialTicketIdentity = 0x0 (DWORD)

As of KFW 2.6.4 it may be possible sometime in the future for the correct client realm to be obtained from the LSA credential cache contents.  However, it will require a fix from Microsoft which at the present time is not available.

Microsoft Windows XP64 and 2003 64-bit edition do not properly implement the LSA Kerberos functionality within the WOW64 32-bit compatibility environment.  As a result, calling the LSA functions within WOW64 causes the Kerberos 5 library to crash.  Therefore, the MSLSA ccache support is disabled in these environments.  Microsoft has fixed this problem as of Vista Beta 2.


GSSAPI Sample Client (gss.exe):

The GSS API Sample Client provided in this distribution is compatible with the gss-server application built on Unix/Linux systems.  This client is not compatible with the Platform SDK/Samples/Security/SSPI/GSS/ samples which Microsoft has been shipping as of January 2004.  Revised versions of these samples are available upon request to krbdev@mit.edu.  Microsoft is committed to distribute revised samples which are compatible with the MIT distributed tools in a future SDK and via MSDN.

The following configuration options may be set for testing GSSAPI connections with a compatible server:

The Output window is a read-only text edit field which will allow text to be selected and copied to the clipboard with Ctrl-C.

Press the Test button to begin a test and the Exit button to quit the application.


Release History

In general, the latest release of KfW is recommended. However, it may be useful (and entertaining) to understand the history of KfW by looking at its release history.

3.1.0

1.                                                                              A serious memory leak has been fixed

2.                                                                              Principal names containing numbers are no longer considered invalid

3.                                                                              Locales other than en_US are now supported

4.                                                                              Arbitrary sort ordering of credentials

5.                                                                              Support for FILE: ccaches

6.                                                                              Credential properties may be selected by the user for display

7.                                                                              User selected font support

8.                                                                              Tool Tip support added to the Toolbar

9.                                                                              Identities can be added without obtaining credentials

10.                                                                          Kerberos 5 Realm editor has been added

3.0.0

2.6.5

2.6.4

2.6.3

2.6.2

2.6.1

2.6.0

What's New in Kerberos for Windows 2.5

2.5.1

2.5.0 (includes all changes since 2.1)

KfW 2.2

KfW 2.1.2

KfW 2.1.1

KfW 2.1

Each Windows NT/2000 login session can access only its own credentials cache. Even Windows NT/2000 security impersonation will not allow a process to access the cache of the user the process is impersonating. This is by design.

This implementation has a much smaller memory footprint and is far more robust than the fleavius implementation. It can support a very large number of caches and credentials. The only downside to the LRPC implementation is that it is currently about 35% slower than the fleavius implementation.

For more information, read the krbcc32 Architecture and krbcc32 Implementation documentation at athena/auth/krbcc/doc/architecture.txt and athena/auth/krbcc/doc/implementation.txt. (krbcc32 documentation links work only if this is the source package.)

Pre-KfW Era

Before there was KfW, MIT had other Kerberos releases for Windows and even for DOS (gasp!). Read on if you dare...

Kerberos for Microsoft Operating Systems Release 2.0

This was a version of KfW before it was called KfW. It had an in-memory credentials cache (called fleavius) that had many problems, including large memory footprint, a single per-machine shared cache (even on NT).

A Long, Long Time Ago...

Once upon a time, 16-bit Windows was supported. There was even DOS support at one point. As far as MIT Kerberos is concerned, those days are best forgotten.


Upcoming in a Future KFW distribution


Important notice regarding Kerberos 4 support

In the past few years, several developments have shown the inadequacy of the security of version 4 of the Kerberos protocol.  These developments have led the MIT Kerberos Team to begin the process of ending support for version 4 of the Kerberos protocol.  The plan involves the eventual removal of Kerberos 4 support from the MIT implementation of Kerberos.

 

The Data Encryption Standard (DES) has reached the end of its useful life.  DES is the only encryption algorithm supported by Kerberos 4, and the increasingly obvious inadequacy of DES motivates the retirement of the Kerberos 4 protocol.  The National Institute of Standards and Technology (NIST), which had previously certified DES as a US government encryption standard, has officially announced[1] the withdrawal of the Federal Information Processing Standards (FIPS) for DES.

 

NIST's action reflects the long-held opinion of the cryptographic community that DES has too small a key space to be secure.  Breaking DES encryption by an exhaustive search of its key space is within the means of some individuals, many companies, and all major governments. Consequently, DES cannot be considered secure for any long-term keys, particularly the ticket-granting key that is central to Kerberos.

 

Serious protocol flaws[2] have been found in Kerberos 4.  These flaws permit attacks which require far less effort than an exhaustive search of the DES key space.  These flaws make Kerberos 4 cross-realm authentication an unacceptable security risk and raise serious questions about the security of the entire Kerberos 4 protocol.

 

The known insecurity of DES, combined with the recently discovered protocol flaws, make it extremely inadvisable to rely on the security of version 4 of the Kerberos protocol.  These factors motivate the MIT Kerberos Team to remove support for Kerberos version 4 from the MIT implementation of Kerberos.

 

The process of ending Kerberos 4 support began with release 1.3 of MIT Kerberos 5.  In release 1.3, the default run-time configuration of the KDC disables support for version 4 of the Kerberos protocol.  Release 1.4 of MIT Kerberos continues to include Kerberos 4 support (also disabled in the KDC with the default run-time configuration), but we intend to completely remove Kerberos 4 support from some future release of MIT Kerberos, possibly as early as the 1.5 release of MIT Kerberos.

 

The MIT Kerberos Team has ended active development of Kerberos 4, except for the eventual removal of all Kerberos 4 functionality.  We will continue to provide critical security fixes for Kerberos 4, but routine bug fixes and feature enhancements are at an end.  We recommend that any sites which have not already done so begin a migration to Kerberos 5.  Kerberos 5 provides significant advantages over Kerberos 4, including support for strong encryption, extensibility, improved cross-vendor interoperability, and ongoing development and enhancement.

 

If you have questions or issues regarding migration to Kerberos 5, we recommend discussing them on the kerberos@mit.edu mailing list.

References

[1] National Institute of Standards and Technology.  Announcing Approval of the Withdrawal of Federal Information Processing Standard (FIPS) 43-3, Data Encryption Standard (DES); FIPS 74,Guidelines for Implementing and Using the NBS Data Encryption Standard; and FIPS 81, DES Modes of Operation.  Federal Register 05-9945, 70 FR 28907-28908, 19 May 2005.  DOCID:fr19my05-45

 

[2] Tom Yu, Sam Hartman, and Ken Raeburn. The Perils ofUnauthenticated Encryption: Kerberos Version 4. In Proceedings of the Network and Distributed Systems Security Symposium. The Internet Society, February 2004.    http://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf


Developer Notes

Network Identity Framework

See devdocs.chm in the SDK

Some older notes from prior releases...

  1. Modification of the Kerberos 4 credential cache:

We encountered a problem at MIT that we felt needed to be addressed even though it broke some backwards compatibility. We found that if someone used a Kerberized application spanning multiple PPP sessions a Kerberos error would be generated and few applications would catch this error and try to get new tickets instead. E.g. Suppose a user starts a PPP connection and then starts Eudora, fetching mail. The user then decides to close down the PPP connection while they read their mail and compose responses. Next they initiate a new PPP connection and incorporate mail again. Note that the user never exited Eudora. Instead of prompting the user for their name and password Eudora will generate and error message. The only way for the user to recover the functionality would be to use Leash, Kview, or kdestroy to destroy their old tickets so that Eudora would get new tickets.

This happened because many ISPs hand out a new IP address to a user each time that user reconnects to the system. Also a Kerberos ticket includes the machines local IP address in an encrypted form this is used by most severs to insure that the ticket has not been copied to another users machine.

Since the local IP address is stored in the ticket it seems that it should be easy to compare this data to the machine's local IP address at the same time that an application is checking to see if the ticket has expired. Unfortunately the IP address in the ticket is encrypted in the server's session key and so is inaccessible to the local machine.

Instead we borrowed an idea from Kerberos version 5 and decided to store the local IP address, unencrypted, in the credential which is cached in the local cache. Within the KClient function IsCredExpired() or the krbv4wXX.dll function kchktkt we verify that the ticket has not expired and that the local IP address matches the IP address stored in the ticket.

This implies that machines with multiple copies of kclnt32.dll or krbv4w32.dll, of different versions, may encounter unexpected errors when using Kerberized applications. The normal error message generated will be BAD_TKT_FILE_FORMAT or NO_TKT_FILE.

Users of applications that use other vendors Kerberos implementations may also be affected. E.g. some software from FTP, Inc.

  1. Add a new function to the KClient DLL. This function is SendTicketsForService(). It is basically a send_auth() type function. Before everyone complains please read the following explanation.

Qualcomm has been working with Platinum on a 32-bit KClient which would supports both Kerberos v4 and v5. From what I have heard this is a commercial implementation. It ignores GSS or other abstraction layers above the Kerberos layer that application developers should write to. It keeps its ticket cache in the DLL, as such it will not share the ticket cache with other Kerberos implementations that may reside on the user's system.

Platinum and Qualcomm decide to add a new API call to the KClient interface. Eudora uses this new function if it finds a KCLNT32.DLL. In this case it does not use the thunking application KERB16.

We have duplicated this function in our release of KCLNT32 so that Eudora will not GPF. Please DO NOT WRITE APPLICATIONS TO THIS FUNCTION.

  1. We stole an idea from Cornell. If the clock is out of synch when we are trying to obtain a ticket we synchronize the clock and try again. We inform the user if this occurred.
  2. Fixed up some problems relating to DLL initialization. WSAStartup() will be called if necessary by a few functions. This was needed to handle some differences in DLL initialization under Win32 when multiple applications were using the DLL at the same time. Also fixed up some initialization of the com_err functions due to similar issues.
  3. Added two new functions to leashw32.dll. The first is Leash_set_help_file(char*szHelpFile) which allows an application developer to specify which help file to use from the dialog box presented when using the Leash_kinit() function. If the argument is NULL the function will check the environment variable KERB_HELP. If this is not set the hard coded value of kerberos.hlp will be used. The other function is Leash_get_help_file() which allows an application developer to determine the name of the help file being used. These are defined in lshfunc.c.
  4. Fix the send_auth so that we do not fail on a null realm. Also detects when an invalid socket descriptor has been passed. (Special thanks to Eudora 3.0 for providing a test case.)