SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
.
} what's new
.
} contract access
.
} browse patch tree
.
} search patches
.
} join mailing list
.
} feedback
.
patches by topic
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
DCE-VMS DCEALPE01_B013 DCE V1.3B for OpenVMS Alpha ECO Summary

NOTE: An OpenVMS saveset or PCSI installation file is stored on the Internet in a self-expanding compressed file. The name of the compressed file will be kit_name-dcx_vaxexe for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha. Once the file is copied to your system, it can be expanded by typing RUN compressed_file. The resultant file will be the OpenVMS saveset or PCSI installation file which can be used to install the ECO. Copyright (c) Digital Equipment Corporation, 1996. All rights reserved. PRODUCT: Distributed Computing Environment For OpenVMS (DCE) COMPONENTS: [SYSEXE]DCE$CDSADV.EXE [SYSEXE]DCE$CDSD.EXE [SYSEXE]DCE$SECD.EXE [SYSLIB]DCE$SOCKSHR_DNET_OSI.EXE [SYSLIB]DCE$SOCKSHR_IP.EXE [SYSMGR]DCE$SETUP.COM [SYSMGR]DCE$SETUP_MULTINET.COM OP/SYS: OpenVMS Alpha SOURCE: Digital Equipment Corporation ECO INFORMATION: ECO Kit Name: DCEALPE01_B013 ECO Kits Superseded by This Kit: None ECO Kit Approximate Size: 6084 Blocks Kit Applies To: Distributed Computing Environment V1.3B OpenVMS Alpha V1.5 or higher NOTE: This ECO must only be installed on a system which is running DCE V1.3 MUPB. System Reboot Necessary: No ECO KIT SUMMARY: An ECO kit exists for Distributed Computing Environment V3.1B on OpenVMS Alpha V1.5 or higher. Problems addressed in the DCEALPE01_B013 kit: o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, CDS imposes incorrect limits for the length of cell names. This limit could cause problems when configuring an OpenVMS system into a non-OpenVMS cell. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, configured as a CDS client in a cell where the CDS Server is not within broadcast range, the configuration and/or startup of DCE can fail when trying to define a cached server. The output from the DCE configuration and/or startup procedure may look like this: Starting CDS Name Service Advertiser daemon (DCE$CDSADV) . . . %RUN-S-PROC_ID, identification of created process is 3020013D **************************** ERROR ************************* *** An error occurred while attempting to establish a CDS cached *** server on this system. Command: *** $ Dce$Cdscp Define Cached Server "name" - *** tower "ncadg_ip_udp:xx.xx.xx.xx" This problem is intermittent and may cause a failure in configuration and/or startup only some of the time. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB with TGV's Multinet, there can be a problem configuring DCE if the file MULTINET:HOSTS.LOCAL contains SERVICE statements for services other than DCE. If the problem exists, the log file, SYS$MANAGER:DCE$SETUP.LOG, will contain the following information: $ Append "'SvcCmd'" to file Multinet:Hosts.Local ********************* WARNING ******************* *** An error occurred attempting to establish the *** TCP/IP service port number needed for CDS Client *** and Clerk communication. *** *** Could not open the output file from the command: *** $ SERVICE : TCP : 1236 : cdsDiag : *** %RMS-E-FNF, file not found CONFIGURE: *** Operation completed *** o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, configured as DCE Security Servers, the DCE$SECD process can hang during startup and cause all security related operations to fail. The output from the DCE startup procedure may look like this: Starting Security Service Server daemon (DCE$SECD) . . . %RUN-S-PROC_ID, identification of created process is 40A0202E Logging in to DCE using principal "cell_admin" . . . **************************** ERROR **************************** *** An error occurred attempting to log in to DCE with principal *** name "cell_admin" Sorry. User Identification Failure. - Registry server unavailable (dce / sec) This problem is most prevalent on multi-processor systems and systems running TGV's Multinet TCP/IP software but it does not occur 100% of the time. It is possible to have DCE$SECD hang on one attempt to start DCE and have it work successfully on the next attempt. o The security of DCE services and DCE-based applications may be compromised; impersonation of legitimate users and administrators is possible. DCE uses randomly-generated encryption keys as a part of the protocols it uses to authenticate and protect communications between various parties (such as hosts, application services and DCE components). A potential security vulnerability in the way that the DCE Security Service generates such keys may allow an attacker to compromise DCE security. Such an attack would require that the attacker have direct access to the network hosting a DCE cell. A replacement for the DCE Security Server (DCE$SECD.EXE) removes this potential security vulnerability. Cell administrators should obtain and install the replacement image. The cell administrators then must also perform the following additional procedures to ensure that all potentially vulnerable keys generated by the original DCE$SECD program are replaced: - All randomly-generated keys in all keytabs (server keys) in the cell need to be changed. Each machine in the cell may have one default keytab file and a number of additional application-specific keytab files. Application-specific keytab files may be created anywhere in the filesystem. Administrators should check with application developers to determine whether their applications create such files. To view the principals whose keys are stored in keytab files on a machine perform the following: a) Log in to a privileged account and then perform a dce_login to acquire administrative DCE credentials (cell_admin is the default DCE administrative account). b) Run rgy_edit and issue the command: ktlist -- to display the contents of the default keytable For every application specific keytab file on the machine issue the command: ktlist -f -- to display the contents of application keytab These commands should be performed on every machine in the cell, to construct a list of which principal keys appear in which keytab files on which machines. It is possible that the same principal key appears in multiple keytab files. If this is the case then either that principal's key is password-derived (in which case the key was not generated by the weak random number generator and does not therefore need to be replaced¹), or an application-specific key synchronization mechanism must be in use. In the latter case, the application writer should be contacted for information on how to change the key. ¹ The use of password-derived server keys should be strongly discouraged, as server keys are used to protect traffic on the network, and password-derived keys may be less resistant to discovery than machine-generated keys. o For each principal whose key appears in only a single keytab file: a) Log in to a privileged account on the machine that hosts the keytab file, and then perform a dce_login to acquire administrative DCE credentials (cell_admin is the default DCE administrative account). b) If 's key is in the default keytab file, issue the following rgy_edit command: kta -p -r -a If 's key is in an application-specific keytab file , issue the rgy_edit command: kta -p -r -a -f These commands change the principal's key in the DCE Registry, and also update the value stored in the appropriate keytab file. o One possible result of this potential security vulnerability is that a successful exploitation would allow an attacker to impersonate users, possibly including administrative users. After any such potential security vulnerability is discovered and fixed, the cell administrator should verify that the DCE Registry contents have not been tampered with. After replacing DCE$SECD, the cell administrator should manually inspect the registry database, checking that no new privileged accounts have been added, that no existing accounts have acquired additional group memberships, and that ACLs within the registry have not been altered. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, an extraneous rpccp profile entry with " /.:/sec" is created when configuring a CDS Server. To see if your configuration contains this entry use the following command: $ rpccp show profile /.:/cell-profile If your configuration has two entries with " secidmap", then you have the problem: 0d7c1e50-113a-11ca-b71f-08001e01dc6c,1.0 /.:/sec 0 secidmap 0d7c1e50-113a-11ca-b71f-08001e01dc6c,1.0 /.:/sec-v1 0 secidmap The entry with " /.:/sec" is extraneous and should be deleted. However, the entry with " /.:/sec-v1" is correct. Please do not delete. You can remove this entry by performing a DCE_LOGIN as a privileged DCE principal and issuing the command: $ rpccp remove element /.:/cell-profile - -i 0d7c1e50-113a-11ca-b71f-08001e01dc6c,1.0 - -m /.:/sec -a secidmap o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, an error may be reported by DCE$DTSD during DCE startup. The error indicates that DTS may not operate properly yet all DTS functions seem to work. This problem is most prevalent on multi-processor systems but it does not occur 100% of the time. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, an error may be reported by CDS during the configuration of a DCE client system. The error indicates that a cached server could not be defined. This problem is most prevalent on multi-processor systems but it doesn't occur 100% of the time. The terminal output may look like this if you have the problem: **************************** ERROR **************************** *** An error occurred while attempting to establish a CDS cached *** server on this system. Command: *** $ Dce$Cdscp Define Cached Server "mynode" - *** tower "ncacn_ip_udp:11.22.33.44" o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, the DCE configuration command procedure may not be able to determine the DECnet ALIAS address on a system running DECnet/OSI and configured with a Cluster Alias. The result is that the Alias address may be used by DCE servers which may prevent DCE clients from contacting the servers. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, the DCE configuration command procedure uses incorrect values to limit the maximum length of cell names. On systems configured as CDS servers the limit should be 29 characters but is currently set to 30 characters. On systems configured as CDS clients the limit should be 128 characters but is also currently set to 30 characters. The result could be DCE systems that can't be configured properly. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPB and DECnet/OSI, the DCE$CDSADV process can terminate prematurely and cause a DCE configuration or startup to fail. This problem only happens on systems which are configured with a DECnet/OSI NSAP that is 17 bytes or longer. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, the DCE$RPCD process can terminate prematurely and cause all DCE operations to fail. The output from the DCE startup procedure may look like this: The DCE daemons on this system are now being started . . . Starting Remote Procedure Call Services daemon (DCE$RPCD) . . . %RUN-S-PROC_ID, identification of created process is 40A0289C Starting Security Service Server daemon (DCE$SECD) . . . %RUN-S-PROC_ID, identification of created process is 40A0489D ************************* ERROR ************************ *** Error - Process DCE$SECD is not running *** DCE System Management Procedure Complete *** The contents of DCE$LOCAL:[VAR.RPC.ADM]DCE$RPCD.OUT will look like this: (socket) >1 select in UCX TL *** FATAL ERROR at RPC$SOCKSHR_UCX.C;1\2118 *** %SYSTEM-F-IVCHAN, invalid I/O channel This problem is most prevalent on multi-processor systems but it does not occur 100% of the time. It is possible to have DCE$RPCD terminate on one attempt to start DCE and have it work successfully on the next attempt. o On OpenVMS VAX and Alpha systems running OpenVMS DCE V1.3 MUPA or V1.3 MUPB, user written DCE applications may experience a problem with an increasing number of unused, UCX, BG devices being allocated to a process. DCE client and server applications communicate with each other over TCP/IP via BG devices which are dynamically created and deleted as needed. In some cases the BG devices are not deleted, eventually causing the process to run out of resources. You can examine the BG devices allocated to a process using the DCL command: $ show process For each BG device allocated to the process you should be able to execute the UCX command: UCX> show dev BGxxxx and see the socket information for that BG device. For DCE server processes there will be one BG device for which UCX will return the error: %UCX-W-NODEVSOCK, Device_socket not found This is a normal occurrence and is not a problem. If a DCE process has numerous BG devices for which UCX returns this error then you may be experiencing this problem. NOTE: This kit does not include the 1996 leap year correction, as this was only necessary for a narrow window of time in effect on February 29, 1996. INSTALLATION NOTES: The system/cluster does not need to be rebooted after this kit is installed. However, before installing the kit you must stop DCE by issuing the following command: $ DCE_SETUP STOP NOCONF After the kit is installed you must restart DCE by issuing the following command: $ DCE_SETUP START NOCONF NOTE: This kit must only be installed on a system which is running DCE V1.3 MUPB. You can identify such a system by searching for the file SYS$LIBRARY:DCE$LIB_SHR.EXE and verifying that it has a link date of 25-OCT-1995 or 29-FEB-1996. The kit installation procedure will perform this check. If it finds that the SYS$LIBRARY:DCE$LIB_SHR.EXE image was not linked on one of the listed dates, the installation will abort.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

dcealpe01_b013.README
dcealpe01_b013.CHKSUM
dcealpe01_b013.CVRLET_TXT
dcealpe01_b013.a-dcx_axpexe

privacy and legal statement