Kerberos for HP OpenVMS
Version 3.2
Release Notes

April 2011

Contents:

  1.  Kerberos Version 3.2 Contains Limited IPv6 Support
  2.  Default Startup Order Required for OpenVMS and Kerberos 
      ACME Agents
  3.  Run KDESTROY Before Reconfiguring Kerberos 
  4.  Reconfigure Kerberos After Reconfiguring HP TCP/IP 
      Services Database
  5.  Example Program Build Problems Using GMAKE  
  6.  Kerberos is Not Cluster-Aware
  7.  Kerberos Command Lines Entered are Changed to Upper Case
  8.  Kerberos KDC Propagation Daemon on OpenVMS Fails on 
      Worker KDC Systems on OpenVMS
  9.  Building a Kerberos Application
  10. Remove Kerberos Version 1.0 Layered Product PCSI Kit 
      Before Upgrading to Version 3.2
  11. UNIX to OpenVMS File Naming Differences
  12. Production-Ready Kerberos ACME agent
  
-------------------------------------------------------------

This document contains release notes for Kerberos Version 3.2 for 
OpenVMS. 

For the latest documentation on the current version of Kerberos for 
OpenVMS, see the Kerberos for HP OpenVMS website:

http://h71000.www7.hp.com/openvms/products/kerberos/


Release Notes
-------------------------------------------------------------

  
  1.  Kerberos Version 3.2 Contains Limited IPv6 Support
  -------------------------------------------------------------

Kerberos Version 3.2 for OpenVMS (included in OpenVMS Version 8.3-1H1) 
contains support for IPv6 at the same level as MIT's Kerberos V5 1.4.1 
sources. The IPv6 functionality allows for Kerberos authentication to 
happen over IPv6, however, administrator functions still have to 
function over IPv4 for this release.

IPv6, or Internet Protocol Version 6, is the next generation protocol 
designed by IETF (Internet Engineering Task Force) to replace the 
current IPv4. IPv6 corrects a number of problems in IPv4, such as the 
limited number of available IPv4 addresses. It also adds many 
improvements to IPv4 in areas such as routing and network 
autoconfiguration. IPv6 is expected to gradually replace IPv4, with 
the two coexisting for a number of years during a transition period. 


  2.  Default Startup Order Required for OpenVMS and Kerberos ACME
      Agents
  -------------------------------------------------------------

The default settings for starting the OpenVMS ACME agents allow logins 
to function normally. If the default order of startup for the OpenVMS 
and Kerberos ACME agents is changed so that the Kerberos ACME is 
started first, accounts that are not in the Kerberos realm may not be 
able to log in. Changing the default order of startup is not 
supported in this release of OpenVMS.

If the startup order is changed, you can change it back to the default 
order by performing the following procedure:

Edit SYS$MANAGER:ACME$START.COM to search for the section (near the 
end of the command procedure) where you can specify the desired agent 
ordering. Change the last line (beginning with $ AGENT_LIST) so that 
it appears as follows:

$! A specific agent ordering can be specified in AGENT_LIST.
$!
$! If the list is empty, the agents will be enabled in the order that 
$! they were configured. Some agent startup procedures may alter 
$! the agent order. You can override that ordering here. Consult the 
$! agent documentation you are using to ensure that the ordering you 
$! specify is supported by that agent.
$!
$! For example
$!
$!      AGENT_LIST = "VMS,MSV1_0"
$!
$! will enable the VMS and MSV1_0 agents (and only those agents) in 
$! that order.
$!
$ AGENT_LIST = "VMS,ACME_KRB_DOI"


  3.  Run KDESTROY Before Reconfiguring Kerberos 
  -------------------------------------------------------------

If you are reconfiguring Kerberos on a system on which Kerberos was 
previously configured, you must enter the kdestroy command before you 
run the configuration command procedure YS$STARTUP:KRB$CONFIGURE.COM.  
The kdestroy command removes all of the tickets for a principal, and 
is defined in KRB$SYMBOLS.COM.


  4.  Reconfigure Kerberos After Reconfiguring HP TCP/IP 
      Services Database
  -------------------------------------------------------------

Before configuring or starting Kerberos, check the HP TCP/IP Local 
Host Database to determine whether your hostname definition is the 
short name (for example, node1) or the Fully Qualified Domain Name 
(FQDN) (for example, node1.hp.com).  

If your hostname definition is the short name, you must run 
TCPIP$CONFIG to change the definition to the fully qualified name.  

For more information on configuring Kerberos, see the Kerberos for OpenVMS
Installation and Configuration Guide.
   
  
  5.  Example Program Build Problems Using GMAKE
  -------------------------------------------------------------
  
The Kerberos example programs found in 
SYS$COMMON:[SYSHLP.EXAMPLES.KERBEROS...] are divided between those 
examples that use DCL to build and those that use GMAKE to build. The 
GMAKE examples are divided between VMS and MIT examples.

The example programs in the 
SYS$COMMON:[SYSHLP.EXAMPLES.KERBEROS.GMAKE.MIT] directory do not build 
properly. These examples require a file, COM_ERR.C, which was 
modified in an earlier release of MIT Kerberos. This modification
left dangling references that require additional modules that are not 
included in the kit. 

The example programs build properly in the 
SYS$COMMON:[SYSHLP.EXAMPLES.KERBEROS.GMAKE.VMS] and 
SYS$COMMON:[SYSHLP.EXAMPLES.KERBEROS.DCL] subdirectories.


  6.  Kerberos is Not Cluster-Aware
  -------------------------------------------------------------

Kerberos for OpenVMS is not cluster-aware. Kerberos tickets are 
encoded with the originating node name as a security feature. A 
ticket-granting ticket (TGT), obtained from one node in a cluster, is 
valid only on the node from which the request was made. Further 
requests for tickets must originate from the same node where the 
ticket-granting-ticket request originated.

Although the ticket cache is visible from other nodes in the cluster, 
the Kerberos KDC does not allow nodes other than the node encoded in 
the ticket to use the TGT.


  7.  Kerberos Command Lines Entered are Changed to Upper Case
  -------------------------------------------------------------

When you enter commands at the Kerberos prompt, the commands you enter 
are changed to uppercase unless they are enclosed in quotation marks. 
For portions of the command that contain lowercase letters like 
principal names and passwords, be sure to use quotation marks. This 
does not apply to password prompting.

In the following example, smith was changed to uppercase because it 
was not enclosed in quotation marks.

Kerberos> modify password smith /password="oldpassword"
Password for "SMITH@REALM" changed.
Kerberos> modify password smith

Enter password for principal "SMITH": newpasswd Re-enter password for 
principal "SMITH":  newpasswd
change_password: password for "SMITH@REALM" changed.
Kerberos> exit


  8.  Kerberos KDC Propagation Daemon on OpenVMS Fails on Worker 
      KDC Systems on OpenVMS
  -------------------------------------------------------------

The Kerberos KDC Propagation Daemon on OpenVMS fails on 
worker KDC systems on OpenVMS, causing scheduled KDC propagation to 
not update the worker's KDC database.

Workaround: Set up the propagation daemon as a TCP/IP service. As a 
TCP/IP service, the daemon will run only when an update request is 
made to the worker KDC system from the master. The daemon will execute 
and then exit. To set up the service, manually enter the following 
commands or save and execute the commands in a .COM file. 
Note: Run this setup procedure only once.

$!
$! Sets up Kerberos5 propagation daemon as TCP/IP service $!
$ TCPIP SET SERVICE KRB5_PROP -
        /FILE=KRB$ROOT:[BIN]KRB$KPROPD.COM -
        /PORT=754 -
        /USER=SYSTEM -
        /PROCESS_NAME=KRB$KPROP -
        /LOG_OPTIONS=(FILE=SYS$MANAGER:KRB$KPROP.LOG,ALL)
$!
$ TCPIP ENABLE SERVICE KRB5_PROP
$!
$ TCPIP SHOW SERVICE/FULL KRB5_PROP
$!
$ EXIT


  9.  Building a Kerberos Application
  -------------------------------------------------------------

To build a Kerberos application using 64-bit pointers, you must 
compile your C application with a compile option of 
/POINTER_SIZE=LONG, and link against KRB$RTL.EXE and GSS$RTL.EXE.

To build an application using 32-bit pointers, omit the 
/POINTER_SIZE=LONG qualifier from your compilation command, and link 
against KRB$RTL32.EXE and GSS$RTL32.EXE.

The example programs in SYS$COMMON:[SYSHLP.EXAMPLES.KERBEROS.GMAKE]
show you how to build a Kerberos application on OpenVMS.


  10.  Remove Kerberos Version 1.0 Layered Product PCSI Kit Before 
       Upgrading to Version 3.2
  -------------------------------------------------------------

If you have installed the PCSI (layered product) kit of Kerberos 
Version 1.0 for OpenVMS, you must use the PCSI utility to remove it 
before you upgrade to Kerberos V3.2.

To remove the Kerberos Version 1.0 PCSI kit from OpenVMS Version 7.3-2 
or 7.3, enter the PCSI command PRODUCT REMOVE KERBEROS. During the 
removal, you are asked if you want to remove the data and directories. 
(Data refers to the configuration data files along with the principal 
database, if one was created.) If you want to save this information 
for use later, respond "No" to the question.

After the upgrade, the new Kerberos directories are located under 
SYSCOMMON in KERBEROS.DIR. New Kerberos data is either created during 
configuration or copied from the old Kerberos directories. If you 
removed a previously installed Kerberos PCSI kit and saved the data 
and directories, the data will be copied into the new directories 
automatically when Kerberos starts for the first time.

To optionally save the log files, enter the following:

$ RENAME/LOG SYS$COMMON:[SYSEXE.LOG]*.* KRB$ROOT:[LOG]*.*;


  11.  UNIX to OpenVMS File Naming Differences
  -------------------------------------------------------------

The MIT Kerberos documentation is written for a UNIX audience. When 
reading the Kerberos documentation, note the following differences 
between UNIX and OpenVMS:

  o File specification format

The following example shows the differences in the file specification 
format of a lock file. In this example, the UNIX file specification
/usr/local/var/krb5kdc/principal.kadm5.lock is equivalent to
KRB$ROOT:[KRB5KDC]PRINCIPAL_KADM5_LOCK.;1 on OpenVMS.

  o Configuration file format

The following examples show the differences in format of two 
configurarion files, krb5.conf and kdc.conf.

The krb5.conf file on a UNIX system is as follows:

[libdefaults]
    ticket_lifetime = 600
    default_realm = ATHENA.MIT.EDU

default_tkt_enctypes = des-cbc-crc
    default_tgs_enctypes = des-cbc-crc

[realms]
    ATHENA.MIT.EDU = {
        kdc = kerberos.mit.edu:88
        kdc = kerberos-1.mit.edu:88
        kdc = kerberos-2.mit.edu:88
        admin_server = kerberos.mit.edu:749
        default_domain = mit.edu
    }

[domain_realm]
    .mit.edu = ATHENA.MIT.EDU
    mit.edu = ATHENA.MIT.EDU

[logging]
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmin.log
    default = FILE:/var/log/krb
5lib.log

The krb5.conf file on an OpenVMS system is as follows:

[libdefaults]
        default_realm = NODE32.DEC.COM
        default_tgs_enctypes = des-cbc-crc
        default_tkt_enctypes = des-cbc-crc

[realms]
        NODE32.DEC.COM = {
                kdc = node32.zko.dec.com:88
                admin_server = node32.zko.dec.com:749
                default_domain = zko.dec.com
        }

[domain_realm]
        .zko.dec.com = NODE32.DEC.COM
        zko.dec.com = NODE32.DEC.COM

[logging]
         kdc = FILE=krb$root:[log]krb$krb5kdc.log
         admin_server = FILE=krb$root:[log]krb$kadmind.log
         default = FILE=krb$root:[log]krb5lib.log

The kdc.conf file on a UNIX system is as follows:=20

[kdcdefaults]
    kdc_ports = 88,750

[realms]
    ATHENA.MIT.EDU = {
        database_name = /usr/local/var/krb5kdc/principal
        admin_keytab = /usr/local/var/krb5kdc/kadm5.keytab
        acl_file = /usr/local/var/krb5kdc/kadm5.acl
        dict_file = /usr/local/var/krb5kdc/kadm5.dict

       key_stash_file = /usr/local/var/krb5kdc/.k5.ATHENA.MIT.EDU
        kadmind_port = 749
        max_life = 10h 0m 0s
        max_renewable_life = 7d 0h 0m 0s
        master_key_type = des-cbc-crc
        supported_enctypes = des-cbc-crc:normal
    }

The krb5.conf file on an OpenVMS system is as follows:

[kdcdefaults]
        kdc_ports = 750,88
        clockskew = 5000

[realms]
        NODE32.DEC.COM = {
          database_name = krb$root:[krb5kdc]principal
          admin_keytab = krb$root:[krb5kdc]kadm5.keytab
          acl_file = krb$root:[krb5kdc]kadm5.acl
          key_stash_file = krb$root:[krb5kdc]_k5_NODE32_DEC_COM
          kdc_ports = 750,88
          max_life = 10h 0m 0s
          max_renewable_life = 7d 0h 0m 0s
          master_key_type = des-cbc-crc
          supported_enctypes = des-cbc-crc:normal des:normal
                               des:v4 des:norealm des:onlyrealm
des:afs3
        }


-------------------------------------------------------------

12. Production-Ready Kerberos ACME agent
  ----------------------------------------

Kerberos V3.2 includes production images for the Kerberos ACME agent. The 
Kerberos ACME agent is an addition to the existing Kerberos authentication
provided by the Kerberos utilities. The Kerberos ACME provides functionality
similar to the pam_krb5 utility on UNIX systems using Kerberos.

