DCE-VMS DCEVAXE01_B013 DCE V1.3B for OpenVMS VAX 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 VAX
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: DCEVAXE01_B013
ECO Kits Superseded by This Kit: None
ECO Kit Approximate Size: 3654 Blocks
Kit Applies To: Distributed Computing Environment V1.3B
OpenVMS VAX V5.5-2 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 VAX V5.5-2 or higher.
Problems addressed in the DCEVAXE01_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:
dcevaxe01_b013.README
dcevaxe01_b013.CHKSUM
dcevaxe01_b013.CVRLET_TXT
dcevaxe01_b013.a-dcx_vaxexe
|
