Jump to page titleUNITED STATES
hp.com home products and services support and drivers solutions how to buy
» contact hp


more options
 
hp.com home
End of Jump to page title
HP Services Software Patches
Jump to content


» software & drivers
» ask Compaq
» reference library
» forums & communities
» support tools
» warranty information
» contact support
» parts
» give us feedback

patches by topic
» DOS
» OpenVMS
» Security
» Tru64 Unix
» Ultrix 32
» Windows
» Windows NT

associated links
» what's new
» contract access
» browse patch tree
» search patch tree
» join mailing list

connection tools
» nameserver lookup
» traceroute
» ping


Find Support Information and Customer Communities for Presario.
Content starts here
HP Services Software Patches - dcealpe01_b013
 
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.
Files on this server are as follows:
»dcealpe01_b013.README
»dcealpe01_b013.CHKSUM
»dcealpe01_b013.CVRLET_TXT
»dcealpe01_b013.a-dcx_axpexe
privacy statement using this site means you accept its terms