HomeStreek ResourcesClient AppsDeveloper ResourcesTalksHowTo Docs
 

Configuring Windows to use a Kerberos KDC

Audience

Developers who wish to use run a test (a.k.a. dev or development) application server that must authenticate itself to UC Berkeley's Kerberos KDC.

Purpose

To enable a test (dev / development) server to authenticate itself to UC Berkeley's Kerberos KDC. This is a necessary step in preparing a robust J2EE development environment, in which a programmer can write, unit-test, deploy, and regression-test J2EE applications that utilize UCB's centrally supported Kerberos authentication framework.

Prerequisites

  • Windows OS (these instructions are written for Windows 2000)
  • A Kerberos service principal (in a keytab file) for your Windows box. Note that the principal must be created for your machine, as it is registered in Berkeley's DNS (i.e., the name returned by nslookup for your IP address); a "borrowed" keytab file will not work.

Configuring Windows to use a Kerberos KDC

Place Kerberos configuration file in system directory

A configuration file for Kerberos named krb5.ini (analogous to krb5.conf on UNIX systems) must be placed into the system root directory. The system root directory of your machine is held in the environment variable SystemRoot.

The contents of this file are as follows, substituting the placeholders ("__secure-path-on-your-machine__") with the path to a secure directory for your machine (i.e., one inaccessible to any user other than the developer and the machine's administrator):

        
# 
        #pragma ident "@(#)krb5.conf 1.2 99/07/20 SMI"
        # Copyright (c) 1999, by Sun Microsystems, Inc.
        # All rights reserved.
        #
        
        # krb5.conf template
        # In order to complete this configuration file
        # you will need to replace the placeholders
        # with appropriate values for your network.
        #
        [libdefaults]
         default_realm = BERKELEY.EDU
         default_tgs_enctypes = des-cbc-crc
         default_tkt_enctypes = des-cbc-crc
        
        
        [realms]
         BERKELEY.EDU = {
         kdc = kerberos.berkeley.edu:88
         kdc = kerberos-1.berkeley.edu:88
         admin_server = kerberos.berkeley.edu
         default_domain = berkeley.edu
         v4_instance_convert = {
         }
         }
        
        
        [domain_realm]
         .Berkeley.Edu = BERKELEY.EDU
         .Net.Berkeley.EDU = BERKELEY.EDU
         .net.berkeley.edu = BERKELEY.EDU
         .HIP.Berkeley.EDU = BERKELEY.EDU
        
        [logging]
         default = FILE:__secure-path-on-your-machine__/kdc.log
         kdc = FILE:__secure-path-on-your-machine__/kdc.log
         kdc_rotate = {
        
        # How often to rotate kdc.log. Logs will get rotated no more
        # often than the period, and less often if the KDC is not used
        # frequently.
        
         period = 1d
        
        # how many versions of kdc.log to keep around (kdc.log.0,
          kdc.log.1, ...)
        
         versions = 10
         }
        
        [appdefaults]
         kinit = {
         renewable = true
         forwardable= true
         }
      

Place Kerberos principal (*.keytab) in a secure directory

Your Kerberos principal, or keytab file, must be generated by Berkeley's Kerberos server administrator, specifically for your machine. See Prerequisistes, above.

Strictly speaking, the keytab file can be placed anywhere on your filesystem. Practically, however, since this file authenticates any machine it resides on as your machine to the Kerberos server, it should be placed in a directory to which access is as restrictive as possible (e.g., restricted to the developer who will be using it, and the machine's administrator).

For purposes of this HowTo, the directory in which the keytab is placed will be assumed to be: c:\krbkey\

JGSS setup

In order to run certain Streek JUnit tests (those for which a login context is required), you must properly configure Java's encapsulation of General Security Services API (JGSS). The example in this HowTo section is specific to Streek, but analogous JGSS setup will be necessary for similar testing outside Streek.

A JGSS configuration file exists in the Streek source tree in src/tests/jaas/jgss-krb-test.conf. This file should be configured to refer to your machine name and your keytab file (substituting where and as indicated):

        
/** Login Configuration for the JGSS Service Principal **/
        
        JgssService {
         com.sun.security.auth.module.Krb5LoginModule required
         useKeyTab=true
         storeKey=true
         clearPass=true
         principal="__Your_Principal_Name_Here__"
         keyTab="__Fully_Qualified_Path_And_Filename_for_Your_Keytab_File_Here__"
         debug=true
         ;
        };
        
        /** Login Configuration for JGSS Client **/
        
        JgssClient {
         com.sun.security.auth.module.Krb5LoginModule required
         storeKey=true
         clearPass=true
         debug=true
         ;
        };
      

For example, your principal name might be j2ee/machine.berkeley.edu; and your keytab file (with path) might be c:\krbkey\machine.keytab.

Test Drive

This test-drive example assumes you are running a JUnit test from within Eclipse.

Note

Because arguments must be passed to JUnit, you must use Eclipse's Run : Run menu choice rather than Run As : JUnit Test.

Run a JUnit test that attempts a variety of Kerberos logins, some expected to succeed and others to fail, such as those in edu.berkeley.ist.streek.security.auth.KrbServerSubjectTest:

  • Open KrbServerSubjectTest.java in Eclipse
  • Navigate to Run : Run from the Eclipse menu.
  • Add the following argument in the Arguments pane of the Run dialog, which points the JVM in which the JUnit test will run to the JGSS configuration file described in a prior step of this HowTo:
    -Djava.security.auth.login.config=d:/workspace/streek/src/tests/jaas/jgss-krb-test.conf
  • Click the Run button. If the JUnit tests all pass (green-bar) you're good to go!

In the event that Kerberos isn't running properly, additional debug information can be obtained by adding an additional argument to the one specified above (space separated; no newline): -Dsun.security.krb5.debug=true.