Release Notes

Dell OpenManage Essentials 2.2.0. Dell OpenManage Essentials is a 'one to many' console used to monitor Dell Enterprise hardware. It can discover, inventory, and monitor the health of Dell Servers, Storage, and network devices. Essentials can also update the drivers and BIOS of your Dell PowerEdge Servers and allow you to. Aug 22, 2000 Developer's Description. Windows Sockets 2 upgrades the WinSock 1.1 TCP/IP system present on nearly all Internet-enabled Windows 95 platforms. If you connect to the Internet using. Welcome to my First Tutorial Part 2.Link Winsock: in VB: Richtextbox1.text.

April 10, 2002

Table of Contents

• Installation and Configuration
  • Locating Kerberos Configuration Files
  • Modifying Kerberos Configuration Files
• Developer Notes

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, Kerberos v5 GSS API library, KClient library, Leash32 GUI credentials manager, kinit/klist/kdestroy 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

• Kerberos v5 support is from MIT Kerberos v5 Release 1.2.5 beta 1. In addition to bug fixes, this release of Kerberos 5 includes several important changes:
  • The public API has been more clearly defined. The krb5.h header file now marks non-public functions with KRB5_PRIVATE and deprecated functions with KRB5_DEPRECATED. You should not define these in your builds.
  • The krb5_32.dll exports have been cleaned up to try to reflect that API. However, the Kerberos 5 DLL still exports some private functions that are currently used by the GSSAPI implementation. Make sure you do not use these (check krb5.h).
  • The Kerberos 5 ccache and keytab accessors are now functions instead of macros.

  See the README file for Kerberos 5 for more information.

System Requirements

Operating System

KfW requires Windows 95, 98, Me, NT 4.0, 2000, XP or higher.

Winsock 2

KfW requires Winsock 2. All version of Windows newer than Windows 95 have Winsock 2 built-in. A system running Windows 95 may or may not have Winsock 2 already installed. If not, it will need the Winsock 2 Update for Windows 95. For more information about Winsock 2 on Windows 95, see these Microsoft Knowledge Base articles:

To actually download the Winsock 2 Update for Windows 95, go to the Windows Socket 2 Update for Windows 95 page.

Microsoft Redistributable DLLs

The following versions or newer of several freely redistributable Microsoft DLLs are also needed:

Filename	Version	Description
mfc42.dll	6.0.8665.0	MFCDLL Shared Library - Retail Version
msvcrt.dll	6.0.8168.0	Microsoft (R) C Runtime Library
msvcp60.dll	6.0.8168.0	Microsoft (R) C++ Runtime Library
psapi.dll	4.0.1198.1	Process Status Helper [not used in Windows 9x/Me]

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

The KfW Installer will install any of these DLLs that are missing.

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. The other DLLs can also be retrieved from the Visual Studio Service Pack 5 Merge Modules, though that is kind of difficult to do.

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 as well
krbcc32s.exe	Kerberos credentials cache -- required by krbcc32.dll
kclnt32.dll	KClient library -- required by some Kerberos 4 applications (such as Eudora)
krb5_32.dll	Kerberos 5 library
leash32.exe	Leash32 GUI Kerberos credentials manager
leashw32.dll	used by Leash32
xpprof32.dll	used by Leash32
comerr32.dll	used by Leash32 and Kerberos 5
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
ms2mit.exe	command-line app to get Microsoft Kerberos v5 domain credentials transferred into the MIT Kerberos v5 credentials cache.

Winsock Fix

Extra Binaries

These binaries are built from sources that are not included in the source distribution. They include SASL libraries for Kerberos v4 support and the k524init program. These binaries are unsupported.

Filename	Description
k524init.exe	Client that requests Kerberos 4 tickets using Kerberos 5 credentials instead of a password
libsasl.dll	SASL library
saslKERBEROSV4.dll	Kerberos v4 SASL support

It is recommended that all core and extra binaries be put into a single directory in the user's PATH. Make sure that you do not have other Kerberos binaries in your PATH.

Locating Kerberos Configuration Files

The simplest configuration is to put the krb5.ini, krb.con, and krbrealm.con configuration files in the same directory as the Kerberos DLLs or in the Windows directory.

Kerberos 5

Kerberos 5 needs a single configuration file: krb5.ini. You can put it in the same directory as the DLL and everything will work fine. You can also put it in the Windows directory. You can even 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: Leash32 can edit the Kerberos 5 and Kerberos 4 configuration files. However, it could potentially screw up the files because it tries to mirror the configuration files. To avoid this issue, modify the files in a text editor.

Kerberos 5

See the krb5.conf section in the Kerberos v5 System Administrator's Guide. (Note: Unfortunately, these links work only if you are browsing from the source archive.)

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:

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:

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):

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:

• No krb.con file is found for Kerberos 4 or no krb5.ini file is found for Kerberos 5.
• The krb.con file or krb5.ini file contains a command to activate DNS Lookups and the lookup cannot be answered by data found in the appropriate configuration file.

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):

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:

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:

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

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 new default for Kerberos 4 and 5 is to store their tickets 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 always go into memory. The ticket string you see always has an 'API:' in front of it.

There are also registry settings for these locations. Playing with Leash32 will reveal where they are (look in HKCUSoftwareMITKerberos4 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 HKCUSoftwareMITLeash32 -- 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.

Winsock 2.2 Free Download

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

leash32

The command line options for leash32 are:

kinit, klist, kdestroy

The options for kinit, klist, and kdestroy can be viewed by typing the name of the utility followed by -? (e.g., kinit -?).

Building from Sources

Building KfW is supported on Windows NT 4.0, Windows 2000, and Windows XP. While building on Windows 9x/Me might work, it is not supported.

First, make sure that you have Microsoft Visual C++ 6.0, a recent release of the Microsoft Platform SDK (August 2001 or higher is known to work), ActiveState Perl (build 631 is known to work), 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 probably also need to be using the default system shell (cmd or command, depending on whether you're running NT/2000 or 9x/Me) so that the Makefiles work properly.

Then, go into the athena directory and type

..scriptsbuild.pl --softdirs

to build everything with debug information. For a release build, run

..scriptsbuild.pl --softdirs NODEBUG=1

For help, do

..scriptsbuild.pl -?

and

..scriptsbuild.pl --docs
[NOTE: does not work in 9x/Me]

If you are running 9x/Me, you will need to invoke the build.pl script using perl. For example:

perl ..scriptsbuild.pl [args]

If krb5 does not build properly, it is probably because sed/gawk were not in your path. To fix this, delete athena/auth/krb5/src/Makefile, fix your PATH, and try again.

To make your life easier, you might try putting the scripts directory in your path. (Under 9x/Me, that will not help you since you always need to invoke the script through perl.)

If you use the build.pl script, the targets should get copied into the target directory at the same level as the athena directory. You can go into targetbini386dbg (replacing i386 with the right CPU and dbg with rel if building release targets), and run the binaries. The debug symbols for the debug build also get placed there in case you need to debug.

Known Issues

• The Kerberos Credentials Cache implementation does not support locking across calls. Each call is atomic, however.
• If the krbcc32s LRPC server process is ever terminated while another process is supposed to have a valid handle to it, the other process will need to grab new handles. The moral of the story is: do not kill krbcc32s if you have any such processes around (e.g., if Leash is running). In fact, you generally should never have to kill krbcc32s.
• If writing a server that uses Kerberos and might use the Kerberos Credentials Cache as opposed to the Kerberos v5 file credentials cache (FILE:), please read the krbcc32 Architecture documentation. (krbcc32 Architecture link works only if this is the source package.)

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.

KfW 2.1.2

• Kerberos v5 support is from MIT Kerberos v5 Release 1.2.3. This release of Kerberos v5 includes the ms2mit program to transfer a user's Microsoft Windows domain Kerberos credentials into the MIT Kerberos 5 credentials cache.
• ms2mit was removed from the Extra Binaries package since it is now part of the included MIT Kerberos v5 component.
• The Microsoft Redistributable Components package no longer includes the Winsock 2 Update for Windows 95. A pointer to download it from Microsoft is now included.
• The release notes have been significantly revamped.

KfW 2.1.1

• Kerberos v5 support is from MIT Kerberos v5 Release 1.2.2.
• KfW now works on Windows XP. (The RPC endpoint names used by the credentials cache had to be shortened for XP.)

KfW 2.1

• 'Kerberos for Win32' is now 'Kerberos for Windows', or 'KfW' for short.
• Kerberos v4 and v5 now build with DNS support by default.
• Kerberos v5 support is from MIT Kerberos v5 Release 1.2.1.
• Various buffer overflow vulnerabilities in Kerberos 4 have been fixed.
• The in-memory Kerberos Credentials Cache implementation is brand new. Fleavius is now obsolete. In-memory credentials cache is now implemented via a LRPC (local remote procedure call) mechanism. The tickets live in the krbcc32s process (which is automatically started). On Windows NT/2000, There is at most one such process per Windows login session.

  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.

To Do

Winsock Xp Fix Free Download

• Improve the documentation.
• The tf_close() in tf_save_cred() is puzzling. Figure out what the spec is supposed to be there (if there is supposed to be one at all) and document the heck out of it. :)
• Make Kerberos 4 and 5 thread-safe.
• Use krb5's com_err instead of the current krb4 mess. Make sure all logging is funneled through one place and provide a way to control where that goes.
• A clean Leash API.

Developer Notes

KClient

• KClient will now try to get tickets for foreign principals if you pass in a service with a non-local realm. It will use the service's realm instead of the default local realm.
• KClient now looks in the ticket file for the realm info before looking for the local default realm.

Winsock 2.2 Download Pc

Below is Jeffrey Altmans's explanation of the problem. The patch he submitted for the first 2 items in his 3-item solution below has been put in.

The design of the KClient interface is so simplified that applications cannot easily get access to necessary information. This has resulted in the need for the Kerberos configuration page in Eudora which includes fields for:

The specification of a Realm here without a 'Principal name' is interesting.

Some information on my system. The local realm is KRB5.COLUMBIA.EDU and the POP server is pop.cc.columbia.edu which is in realm CC.COLUMBIA.EDU. With a ticket manager I retrieve a TGT for CC.COLUMBIA.EDU. Kstatus.exe reports that I am authenticated. Kstatus uses the kclnt32.dll interface just as Eudora does. However, when I ask Eudora to check my mail an interesting thing happens:

GetTicketForService() is called which results in a dialog being displayed

So I enter my password for CC.COLUMBIA.EDU and am told sorry but the password is incorrect.

What happened here?

First, Eudora does not include a field for the principal name to go along with the realm. So it does not call SetUserName() which should have been set to

to match the realm specified in Eudora for the POP host. Eudora needs the realm so it can construct the service ticket name

but without setting the username it has no mechanism to report the desired realm to kclnt32.dll.

GetTicketForService() calls an internal function to verify the TGT. But because no realm has been set and data is not shared between process boundaries this instance of kclnt32.dll has no idea that the ticket manager realm is CC.COLUMBIA.EDU. And instead of attempting to load the Ticket File Realm it calls krb_get_lrealm(). So it tries to verify a TGT

which does not exist. So it destroys the existing tickets and then attempts to get a new TGT for

in the default realm which again is KRB5.COLUMBIA.EDU. But of course kclnt32.dll does not display the realm in the dialog box so the user has no idea that kclnt32.dll is confused.

In order to correct this situation the following needs to be done to kclnt32.dll:

1. all calls to krb_get_lrealm() should be preceded by an attempt to retrieve the realm from the ticket file with krb_get_tf_realm(). Only if krb_get_tf_realm() fails should krb_get_lream() be called.
2. if a realm is specified in the GetTicketForService() request that realm should be used for the verification of the TGT.
3. the dialog box displayed by UserInfo() should append the realm to the szNetID (if it is not already part of the string) when setting the default value for the box. This will indicate to the user which realm s/he is being authenticated against.

Then the author's of Eudora should add a principal name to the configuration for Kerberos and call SetUserName() to set the principal and realm to the values needed to authenticate against the POP server.

Registry and Environment Settings

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.

2. 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.

3. 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.
4. 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.
5. 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.
6. 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.)