Kerberizer Readme (9/2003)

  1. What is Kerberizer?
  2. Installing the Binaries
  3. Uninstalling the Binaries
  4. Configuring Windows 2000/XP's Built-in Kerberos
  5. How Does Kerberizer Work?
  6. Debugging and Troubleshooting
  7. Using Kerberizer with NAT
  8. Extra Requirements for Windows 9X and NT
  9. List of Tested Clients
Kerberizer was written by Steven Michaud (smichaud at

I) What is Kerberizer?

Kerberizer is a Windows Sockets service provider (basically, an extension of the Microsoft Windows TCP/IP stack) that adds GSSAPI-based Kerberos 5 authentication to "insecure" POP, IMAP and FTP Windows clients (ones that (normally) send account names and passwords across the net in plain text). It can also encrypt the traffic between the client and the server. (For FTP it encrypts the control channel and (optionally) the data channel. For POP and IMAP it can be set to encrypt all traffic -- though this currently isn't terribly useful.)

Kerberizer has been tested with a small number of clients (see the list below), but in principle it should work with any Windows POP, IMAP or FTP client. It works with current versions of all the major free GSSAPI-Kerberos-5 servers -- UW IMAP, Cyrus IMAP, the FTP daemons from MIT Kerberos and Heimdal Kerberos, and ProFTPD with the addition of mod_gss ( It does not work with non-GSSAPI Kerberos 5 servers, such as Qualcomm's Qpopper.

Kerberizer works with any version of 32-bit Windows. But it can only be as secure as the underlying OS, and Windows 9X (Windows 95 through Windows Me) is not very secure. Nor are Windows NT, 2000 and XP sufficiently secure unless the partition where you install Kerberizer uses the NTFS file system. For this reason I don't recommend using Kerberizer on Windows 9X, or on Windows NT/2000/XP without the NTFS file system, unless no-one else has physical access to your computer (or at least only people you can trust have access). See How Does Kerberizer Work? below for more information. (Note: Windows 9X and NT users will need to download and install some extra operating system components. See Extra Requirements for Windows 9X and NT below.)

Kerberizer is not itself a Kerberos package. You can install the MIT Kerberos for Windows package (or one of its relatives), and Kerberizer will use that. Or on a suitably configured Windows 2000 or Windows XP computer, Kerberizer can use the operating system's built-in Kerberos 5 support via the Windows SSPI. (Though there may be problems doing FTP if you use the Windows SSPI. See below under Configuring Windows 2000/XP's Built-in Kerberos.)

Kerberos is an authentication protocol developed at MIT, designed for use on a network that is assumed to be insecure. (For example, it never sends passwords over the net, even encrypted, and the authentication tokens it does send expire after a few hours.) As long as the Kerberos servers (where the KDC and kadmin daemons run) remain secure, it is very unlikely that compromises to the network or to other computers will result in a compromise to the authentication system as a whole. In this respect Kerberos is significantly better than password-over-SSL (as used by SSL POP or SSL IMAP), which sends accounts and passwords over an encrypted pipe -- if someone compromises a single busy server and installs a hacked service daemon, in a few hours they can harvest most of the users' accounts and passwords. The MIT and Heimdal Kerberos implementations make it easy to isolate the KDC and kadmin daemons from other services, which in turn makes it easier to secure the computers on which these daemons are run. If you want to know more, the best place to start is Ken Hornstein's Kerberos FAQ, posted periodically to the comp.protocols.kerberos newsgroup and also available at

For all its technical excellence, Kerberos still isn't very widely used, especially on non-Unix platforms like Windows. Setting up a Kerberos authentication system is only slightly more complex than doing password-based authentication over an encrypted pipe. But many fewer clients are available with Kerberos support than with some kind of support for encrypted pipes. And Microsoft has further muddied the waters by choosing to go its own way with Kerberos: Microsoft's KDC is emphatically not isolatable from other services. And though some Kerberos support is available in Internet Explorer and Outlook, it's not possible to use it except with Microsoft's servers. (For example, to use the Kerberos support in Outlook to access your email, you must use an Exchange server and your computer must belong to a Windows domain.)

Kerberizer is intended to tackle both of these problems. It adds Kerberos support to whole categories of Windows clients that didn't have it before. It adds more flexible Kerberos support to Outlook and Outlook Express, making it possible for them to use Kerberos authentication against non-Microsoft servers. And, on Windows 2000 and Windows XP, it can use these operating systems' built-in Kerberos support (via Microsoft's SSPI) to authenticate against non-Microsoft servers.

Kerberizer's starting point was a "Layered Service Provider" sample program originally distributed by Microsoft. Kerberizer makes substantial corrections and additions to that code. For an interesting article on writing a Windows Sockets service provider, see "Unraveling the Mysteries of Writing a Winsock 2 Layered Service Provider", Wei Hua, Jim Ohlund, Barry Butterklee, Microsoft Systems Journal, May, 1999 (this article is currently available at

II) Installing the Binaries

  1. Install and configure Kerberos client software, or (if you have Windows 2000 or Windows XP) configure the Kerberos support built into your operating system.

    Kerberizer is known to work with MIT's Kerberos for Windows. It should also work with many of the Kerberos 5 client packages distributed by universities in the US and Canada -- so long as these packages expose the GSSAPI and KRB5 APIs, and so long as Kerberizer can find the DLLs containing those APIs (usually called gssapi32.dll and krb5_32.dll). You will need either to ensure that the directory containing those DLLs is the first in your PATH, or that Kerberizer's DllPath and Krb5DllPath settings are set appropriately. (See Settings.txt for full information on Kerberizer's settings. Kerberizer must of course be installed before you can view or change its settings.)

    If you are running Windows 2000 or Windows XP and wish to use its built-in Kerberos support, see "Configuring Windows 2000/XP's Built-in Kerberos" below. (But note that, because Windows' SSPI doesn't support "channel bindings", you may need to patch your MIT or Heimdal FTP server. See Patches.txt for more information.)

  2. If you are upgrading from a previous version of Kerberizer, first unregister that version and restart your computer. (See Uninstalling the Binaries below.)
  3. Choose a permanent location for Kerberizer's binary files (those in the Binaries subdirectory of the Kerberizer distribution). On Windows NT, 2000 and XP this should be a directory on an NTFS partition to which ordinary users (Everyone, Guest and members of Guests and Users) don't have Write or Modify access. (Windows 9X and non-NTFS partitions on Windows NT/2000/XP lack file and directory level security, which is one of the reasons I don't recommend using Kerberizer on any version of Windows 9X, or from a non-NTFS partition, unless no-one else has physical access to your computer.) On Windows 2000 and Windows XP it should be safe to install Kerberizer to a subdirectory of the Program Files directory (if you haven't changed the default security on either directory). On Windows NT you will always need to tighten the security of the directory where you install the Kerberizer binaries. Even on Windows 2000 and XP, you may wish to deny Write or Modify permissions to everyone but Administrators, SYSTEM and CREATOR OWNER -- in other words, it may be wise to remove these permissions even from the Power Users group, which has them by default.

    Run Register.bat from where you've installed it. This registers both Kerberizer (Kerberizer.dll) and Kerberizer Settings (KerbSettings.dll) with the operating system. Then go through the following steps to create a shortcut to the Kerberizer Settings program:

    1. Click on the "Start" button and choose "Run".
    2. Type "mmc" in the "Open" box, then click on OK.
    3. Choose "Add/Remove Snap-in" from the "Console" menu.
    4. Make sure the "Standalone" tab is selected, then choose "Add".
    5. Scroll down to "Kerberizer Settings" and double-click on it. (If you don't see "Kerberizer Settings", KerbSettings.dll didn't get registered by Register.bat.)
    6. Click on the "Close" button in the "Add Standalone Snap- in" panel.
    7. Click on the OK button in the "Add/Remove Snap-in" panel.
    8. Choose "Save As" and change the name of the file to "Kerberizer Settings" (or if you don't hide known file extensions, "Kerberizer Settings.msc"). Now you will be able to run Kerberizer Settings by choosing "Programs : Administrative Tools : Kerberizer Settings" (or "Kerberizer Settings.msc").
  4. If you're using Windows 2000 or Windows XP's built-in Kerberos support, tell Kerberizer to use SSPI by setting "UseWindowsSSPI" to "TRUE" (in Kerberizer Settings under "Settings : GSSAPI").
  5. Set up your favorite IMAP, POP or FTP client to connect to a GSSAPI-Kerberos-5 server. You will need to choose a fake password (I usually use "password"). For convenience, you should probably also tell your client to save this fake password. Kerberizer will intercept the password and do a true Kerberos authentication. Even the fake password won't get sent out on the net.

III) Uninstalling the Binaries

WARNING: Do not delete or rename Kerberizer.dll without first unregistering it. Doing so may make your computer unresponsive and unbootable.
  1. First unregister Kerberizer's binaries by running Unregister.bat.

    As you can see by looking at Unregister.bat, the command to unregister just one of the binaries is "regsvr32 /u Kerberizer" or "regsvr32 /u KerbSettings". The command to (re)register just one of them is "regsvr32 Kerberizer" or "regsvr32 KerbSettings". These commands must be run from the directory where Kerberizer.dll and KerbSettings.dll are located. There is no harm in unregistering either program multiple times, or in registering either multiple times -- each program refuses to register itself more than once, or to unregister itself more than once.

  2. Promptly restart your computer.

    If you delay restarting for too long after having unregistered Kerberizer.dll, system DLLs that use the network stack may start to behave strangely. This only happens on Windows 2000/XP, and as far as I can tell is due to problems with the Winsock SPI on those platforms.

  3. After your computer has restarted, you can delete any or all of Kerberizer's files.

IV) Configuring Windows 2000/XP's Built-in Kerberos

Note that, because Windows' SSPI doesn't support "channel bindings", you may need to patch your MIT or Heimdal FTP server in order to do Kerberized FTP. See Patches.txt for more information.

If your computer runs Windows 2000/XP and belongs to a Windows domain whose domain controllers are Windows 2000 or Windows XP based, you shouldn't need to do any further configuration. You will be able to use Kerberizer to authenticate against Unix-based GSSAPI-Kerberos-5 POP, IMAP and FTP services (though the FTP services may need patching). Unless you've configured your Windows domain's KDC to trust an MIT or Heimdal KDC (via an external trust relationship), these POP, IMAP and FTP services will need to use your Windows KDC for authentication.

Otherwise you should remove your Windows 2000/XP computer from whatever Windows domain it may belong to and perform the following steps. They will make your computer authenticate to an MIT or Heimdal KDC, and will map one or more of its accounts to "principals" in the Unix-based Kerberos realm.

  1. If you haven't done so already, install the Support Tools which are available in the SUPPORT\TOOLS directory of the Windows CD. (Run SETUP.EXE.)
  2. Ask the administrator of your Kerberos realm to create a host principal for your Windows 2000/XP computer. The following command is an example of how this might be done. You need to know and remember the password, because you will use it below.

    ank -pw password host/

  3. Log in to your Windows computer as Administrator and enter commands like the following at a command prompt. (Your Kerberos realm is assumed to be MYREALM.EDU. Its KDC is assumed to be running on The password is the one from step b.)
    C:\> ksetup /setdomain MYREALM.EDU
    C:\> ksetup /addkdc MYREALM.EDU
    C:\> ksetup /setmachpassword password
  4. Reboot your Windows computer and log in again as Administrator.
  5. Create user accounts on your Windows computer and use a command like the following to map each one to a principal in your Kerberos realm. It will be most convenient to make each account name the same as the Kerberos principal, but this isn't necessary.

    C:\> ksetup /mapuser user@MYREALM.EDU user

    Alternatively you can use the following command to map all of your local user accounts to Kerberos principals at the same time, if both sets of accounts use the same namespace:

    C:\> ksetup /mapuser * *

V) How Does Kerberizer Work?

Kerberizer is a Windows Sockets service provider. It uses the Windows Sockets Service Provider Interface (Winsock SPI) to "chain" itself to the network protocols underlying the Windows Sockets Application Programming Interface (Winsock API). Thus it sits between your computer's network protocol stack(s) and the programs that use the Winsock API to do networking. A Windows Sockets service provider can in principle see (and alter) any of the traffic going into or out of the Winsock API (using any of the "high level" protocols, such as TCP, UDP, NetBIOS and AppleTalk). More than one Windows Sockets service provider can be installed at the same time, in "chains" up to eight levels deep. The service provider at the bottom of a chain (closest to a protocol stack, such as the TCP or UDP stack) is the first to see incoming traffic, and the last to see outgoing traffic.

Kerberizer is interested only in TCP and UDP traffic. With its default settings, it monitors outbound connections to the standard ports for IMAP, POP and FTP traffic. (You can add or substitute non-standard ports.) If it sees a password-based authentication to any one of these services, it intervenes to alter it into a GSSAPI-Kerberos-5 based authentication. Neither the client nor the server are aware that anything unusual is going on. For the server it's an ordinary GSSAPI-Kerberos-5- based authentication. The client still thinks it's doing clear- text-password authentication. So at the appropriate time it still tries to send a password. But Kerberizer doesn't allow the password out onto the net (usually the password message is replaced with some kind of noop message). Since GSSAPI-Kerberos- 5 authentication is challenge-response, it usually generates more traffic between client and server than password-based authentication. Kerberizer handles this by calling directly to the next provider in the chain (usually the "base provider", which is the actual protocol stack). The Winsock API client never sees the extra traffic.

After having done GSSAPI-Kerberos-5 authentication on a POP or IMAP connection, Kerberizer (by default) passes through all subsequent traffic unchanged. But for FTP connections it encrypts/decrypts traffic on the control channel, and optionally also on the data channel. (Kerberizer can also be set to encrypt/decrypt POP and IMAP traffic, though this currently isn't very useful.) For various reasons encryption and decryption requires buffering of the data sent by the server to the client, so that there isn't necessarily a one-to-one correspondence between client calls to the Winsock API "read" function and actual attempts to read data from the server. Once again this is entirely transparent to both the client and the server. Kerberizer will also do client-to-server buffering when needed (which isn't normally the case).

Kerberizer is careful not to interfere with clients that are already Kerberized, or to secure traffic that should not be secured (for example an anonymous FTP connection, which it can identify by the account name that's used -- i.e. "anonymous" or "guest", or whatever else you add to Kerberizer's AnonymousAccounts setting). To be more efficient, Kerberizer monitors as little traffic as possible, and decides early in any connection whether or not it's interested in the traffic.

Many of you will have noticed that Kerberizer has the same structure as a "man in the middle" exploit. Of course Kerberizer wears a white hat, not a black one. But it'd be possible to alter it to do nasty things (such as adding virus-infected attachments to your email). So when you install Kerberizer on a computer, you want to make sure that no-one can replace it with something sinister. On Windows NT, 2000 and XP, you must use an account with Administrator privileges to register Kerberizer as a Windows Sockets service provider. And as long as you install Kerberizer's binaries to a directory on an NTFS partition whose permissions are sufficiently restricted, only trusted users will be able to delete or alter the binaries after they've been installed. But on Windows 9X (Windows 95 through Windows Me) anyone can register a Winsock service provider, and anyone (even on Windows NT/2000/XP) can change or delete files (and directories) on a non-NTFS partition. For this reason I don t recommend using Kerberizer on Windows 9X, or from a non-NTFS partition on any version of Windows, unless you're quite sure that no-one else with physical access to your computer is going to replace it with a hacked copy.

VI) Debugging and Troubleshooting

If you set "TracingOn" to TRUE, Kerberizer will log network traffic to files in the user-level or system-level TEMP directories. (On Windows 2000 and XP, the user-level TEMP directory is usually [USERPROFILE]\Local Settings\Temp, and the system-level TEMP directory is usually [SystemRoot]\Temp.) Each program that uses Kerberizer (via the Winsock API) gets its own log file, whose name is the program's executable plus ".log" (so the log for Outlook Express will be called "msimn.exe.log"). All Winsock calls get at least minimal entries in the logs. "Interesting" traffic is logged in full. What counts as "interesting" is all traffic going to or coming from ports that Kerberizer considers IMAP, POP or FTP ports, plus any additional ports listed under "TracedPorts".

To be able to interpret these logs, you will need to understand the appropriate protocol. The ultimate resources are the RFCs (the Kerberizer distribution includes recent copies of all the relevant ones). But you can also learn a lot by comparing logs of sessions you are trying to secure with logs of insecure sessions made using the same protocol. Even if you don't have any trouble with Kerberizer, I think you'll find it interesting to log brief sessions in all the supported protocols (IMAP, POP and FTP), then look at the logs.

Don't leave "TracingOn" on continuously. Its log files can grow large very quickly, and it will slow your network access down considerably.

NOTE: The debugging technique described in the next three paragraphs (changing the Winsock service provider order) has been temporarily disabled, because it has not yet had sufficient testing.

A second debugging technique is only useful if you are using Kerberizer together with another Windows Sockets service provider. Windows Sockets service providers are quite rare, so it's very unlikely that you're currently using another one. (In fact, I haven't been able to find one to test Kerberizer with.) But if you are, it's important to know that Windows Sockets service providers are installed in chains, and that each provider's position in the chain determines the order in which it sees network traffic (service providers at the "bottom" of each chain see incoming traffic first and outgoing traffic last). So you may be able to solve problems by changing the order of the service providers in each chain.

Kerberizer installs itself at the top of each TCP and UDP chain. If you have another Windows Sockets service provider, you should be able to see the chain order, and to change it, using the Kerberizer Settings program. If the "Advanced" view isn't already on, select it by right-clicking on "Kerberizer Settings", then selecting "View" and "Advanced". If you have more than one Windows Sockets service provider, you should see more than one entry under "Layered Service Provider Order". To change their order, right-click on one of them and choose "Move Up" or "Move Down".

Be aware that other Windows Sockets service providers may not expect you to change their chain order, or to install another service provider on top of them. They should still function correctly after the order is changed. But before uninstalling your first service provider, you should probably change the order back to what it was originally, and possibly also unregister Kerberizer.dll (by running the command "regsvr32 /u Kerberizer" at a command prompt in the directory that contains Kerberizer.dll).

VII) Using Kerberizer with NAT

In recent years there's been increased demand for a way to share a single "real" internet address among multiple computers. (Maybe you don't want to pay your ISP for more than one, or maybe your subnet doesn't have enough IP addresses available.) A popular solution is to have one of your computers be a gateway to the Internet for the others, and run something on it called a Network Address Translation (NAT) server. Your gateway has a "real" ip address, but all your other computers have addresses in one of the "private" ranges (which need not be unique, but which for that reason are illegal on the "public" Internet, e.g. 192.168.X.X). The NAT server keeps a state table of all the connections to the Internet from any of your other computers. It replaces the private ip addresses in outgoing traffic with your one "real" ip address, so that it seems to the outside world like all the traffic is coming from your gateway. For incoming traffic the NAT server "translates" the other way -- using its state table to route traffic to the computer that originated the connection (one of your computers with a private ip address).

If a Kerberos client requests it (and many Kerberos packages make this happen by default), a Kerberized server checks the ip address of the client it's talking to, to make sure the client isn't pretending to be someone else. (The client may request that its ip address be included in the authentication token it gets from the KDC, which the client sends on to the application server. If an ip address is present, the application server checks it against the ip address the client appears to have connected from, and rejects the connection if they don't match.) Problem is, after address "translation" the ip address the client thinks it has will always be different from the ip address the server thinks the client is connecting from.

Kerberos 5 gives clients the option to turn off address checking by letting them use "addressless tickets" (which are authentication tokens that contain no ip addresses). If your Kerberos client software supports addressless tickets, you can turn that support on. If it doesn't (like MIT's Kerberos for Windows 2.1.2), you can work around the problem by turning on the following Kerberizer options -- "UseKinitPopup", "PopupGetAddresslessTGT" and possibly also "PopupForceAddresslessTGT". None of this is necessary if you're using Windows 2000/XP's built-in Kerberos support, which always gets addressless tickets.

Addressless tickets work fine with the UW and Cyrus IMAP and POP servers, ProFTPD-plus-mod_gss, and the most recent version (1.3.1) of MIT's FTP daemon. But Heimdal's FTP daemon, and all versions of MIT's but the most recent, also use another kind of address checking -- this is called "channel bindings" and is part of the GSSAPI protocol. It doesn't get turned off when you use addressless tickets. So if you want to use Kerberizer to do FTP over a NAT server, you may need to patch your FTP server, or convince the server's administrator to do so. Patches for Heimdal's FTP daemon and for the last version of MIT's that still used channel bindings are included with the Kerberizer distribution. These are discussed in Patches.txt.

You may also need these patches if you want to use Windows 2000/XP's built-in Kerberos support to do Kerberized FTP, even if you're not using a NAT server. Windows's SSPI has no support for channel bindings.

VIII) Extra Requirements for Windows 9X and NT

  1. Microsoft Management Console (Windows 9X and NT)

    The Kerberizer Settings program is an "MMC snap-in", but the Microsoft Management Console was first released with Windows 2000. So Windows 9X and NT users will need to download an installer for this component. What appears to be the most recent version is called IMMC.EXE, and is currently available at

    (Note: For reasons that aren't clear, MMC isn't fully functional on Windows NT, and some of the Kerberizer Settings program's menus are missing. The most important of these is one that lets you make all the "Advanced" settings visible. I've worked around this problem by having Kerberizer Settings always show all settings on Windows NT.)

  2. Regsrv32.exe (Windows 9X and NT)

    This is the program that's called by "register.bat" and "unregister.bat" to register or unregister Kerberizer.dll and KerbSettings.dll with the operating system. Windows 9X and NT users can currently download an archive containing this program at Copy the program to either C:\WINDOWS\SYSTEM (on Windows 9X) or C:\WINNT\SYSTEM32 (on Windows NT).

  3. SpOrder.Dll (Windows 9X)

    The code in Kerberizer.dll (called by Regsvr32.exe) that registers and unregisters it with the operating system requires an "SpOrder.Dll". This comes with Windows NT, 2000 and XP, but not with Windows 9X. Unfortunately it isn't available in a convenient download. But it does get installed when you install the "Core SDK" component of the Microsoft Platform SDK. After installing this component, copy SpOrder.Dll from the C:\Program Files\Microsoft SDK\Bin\winnt directory to C:\WINDOWS\SYSTEM. The Platform SDK is currently available at

IX) List of Tested Clients