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.