Document revision date: 5 July 2000

DCE does not support VMScluster connection forwarding. DCE requires, instead, that all connection requests be made directly to a specific node in the VMScluster instead of to a VMScluster alias.

For example, if you start a DCE application server named whammy on VMScluster node HENDRX in a VMScluster named GUITAR (VMScluster alias name), binding information includes node HENDRX addressing information; it does not include VMScluster alias GUITAR addressing information. In turn, when a client wants to communicate with server whammy, it must retrieve binding information about the server. This binding information must contain address information for physical node HENDRX, not for the VMScluster alias GUITAR.

DCE makes use of VMScluster technology in the following ways:

• You can install DCE from a single kit installation for all nodes in the VMScluster environment. You can store all of the executables, libraries, message files, and other resources in the common VMScluster file system.
• You can use a single, shared account to execute the DCE daemon processes.

Although DCE installation and daemon processes are handled in a standard VMScluster manner, you must configure each VMScluster node individually to run DCE services. Some DCE services require node-specific information to be stored in the nonshared file system.

3.3.4 DCE and VMScluster Configuration Issues

Although DCE cells and VMScluster environments include exclusive lists of hosts (nodes), the boundaries of the two environments do not need to match each other. In a VMScluster environment, each node can be a member of only one extended cluster system. The same applies to DCE: each host is a member of only one cell. However, when you configure DCE and use it with VMScluster environments, the boundaries of a cell and the boundaries of a VMScluster do not need to be the same.

For security reasons, you should not have some members of a VMScluster belong to one cell and other members of a VMScluster belong to another cell. However, members of multiple VMScluster environments can be members of one DCE cell.

The following sections describe information you need to know when using Compaq DCE for OpenVMS VAX and OpenVMS Alpha with DECnet software.

Compaq DCE for OpenVMS VAX and OpenVMS Alpha supports DECnet Phase IV networking. It also supports DECnet/OSI (DECnet Phase V).

4.1 DECnet and DCE Startup and Shutdown Sequences

Before you start or stop DECnet, you should first stop the DCE services. Then, after you start DECnet, restart the DCE services. Follow these steps to shut down DECnet and DCE on a system running DCE applications:

1. Stop any DCE applications that are running.
2. Stop the DCE services.
   If you are performing a system shutdown, DCE services are stopped with the following command, placed before the network transport shutdown commands in the site-specific shutdown procedure SYS$MANAGER:SYSHUTDWN.COM:

   $ @SYS$STARTUP:DCE$SHUTDOWN

   
   This ensures that both DCE services and DECnet shut down in the correct order.
   If, however, you must shut down DECnet but are not performing a system shutdown, first stop the DCE services with this command:

   $ @SYS$MANAGER:DCE$SETUP clean

3. Then, if you are not performing a system shutdown, you can also stop DECnet interactively with one of the following commands:
   To shut down DECnet Phase IV, use the following command:

   $ MCR NCP SET EXECUTOR STATE SHUT

   
   To shut down DECnet/OSI, use the following command:

   $ @SYS$MANAGER:NET$SHUTDOWN

Here is the sequence to follow when you start DECnet on a system that is also running DCE applications:

1. Start DECnet Phase IV with the following command (usually executed from system startup procedures):

   $ @SYS$MANAGER:STARTNET.COM

   
   Start DECnet/OSI with the following command:

   $ @SYS$STARTUP:NET$STARTUP.COM

2. Make sure the DCE services are started.
   Check to see that the DCE startup command procedure is invoked by the site-specific startup procedure. In SYS$MANAGER:SYSTARTUP_VMS.COM, make sure the following line was placed after the network transport startup commands:

   $ @SYS$STARTUP:DCE$STARTUP.COM

   
   DCE startup can occur only after successful completion of the DECnet startup procedure.
   If you need to start the DCE services, but are not performing a system reboot, you can start DCE with this command:

   $ @SYS$MANAGER:DCE$SETUP start

3. After the DCE services are started, you can restart your DCE applications.

Users running server applications that support DECnet need to consider the following:

• The requirements needed on accounts running servers
• The restrictions on naming DECnet endpoints

A DCE server application listening for client requests using the ncacn_dnet_nsp protocol sequence must be able to create a DECnet server endpoint (known as a named object in DECnet). To create the endpoint, the server application must run from an account that has either the rights identifier NET$DECLAREOBJECT or the privilege SYSNAM enabled.

If the NET$DECLAREOBJECT rights identifier does not already exist on your system, installation of Compaq DCE for OpenVMS VAX or OpenVMS Alpha creates it for you.

Use the OpenVMS Authorize utility (AUTHORIZE) to display the rights identifier, as follows:

$ RUN SYS$SYSTEM:AUTHORIZE

UAF> SHOW /IDENTIFIER NET$DECLAREOBJECT

Name Value Attributes NET$DECLAREOBJECT %X91F50005 DYNAMIC

If a server application must run from an account without the SYSNAM privilege, and the rights identifier does not exist, you must use AUTHORIZE to grant the rights identifier to the account. For example:

$ RUN SYS$SYSTEM:AUTHORIZE UAF> GRANT/IDENTIFIER NET$DECLAREOBJECT uic/account-specification

If the server account does not have the rights identifier NET$DECLAREOBJECT or the SYSNAM privilege, the RPC use-protocol-sequence API routines such as rpc_server_use_all_protseqs() and rpc_server_use_protseq() return the status code rpc_s_cant_listen_socket for the ncacn_dnet_nsp (DECnet) protocol sequence.

4.2.2 DECnet Endpoint Naming

To prevent RPC interoperability problems between DECnet-VAX and DECnet-UNIX hosts, Compaq recommends that you specify all well-known server endpoints completely in uppercase characters, using a maximum of 15 characters.

The following example shows an IDL file using an uppercase endpoint:

[uuid(43D2681B-A000-0000-0D00-00C663000000), version(1), endpoint("ncadg_ip_udp:[2001]", "ncacn_ip_tcp:[2001]", "ncacn_dnet_nsp:[APP_SERVER]") ] interface my_app

When a server calls the RPC use-protocol-sequence API routines such as rpc_server_use_all_protseqs_ep() and rpc_server_use_protseq_if(), DECnet on OpenVMS creates ncacn_dnet_nsp endpoints in uppercase characters, regardless of how the endpoint was specified. DECnet on OpenVMS also converts to uppercase the endpoints in all incoming and outgoing RPC requests.

DECnet-UNIX, however, does no conversions on ncacn_dnet_nsp endpoints. These differences can prevent client requests from reaching a server.

For example, an UNIX DCE server listening for client requests over the ncacn_dnet_nsp protocol sequence with the endpoint app_server is not able to receive requests from an OpenVMS DCE client. Even though the OpenVMS client uses the endpoint app_server to create a binding handle (by using a string binding or from an import), DECnet on OpenVMS converts the endpoint in the outgoing RPC request to uppercase APP_SERVER. Because the UNIX DCE server application is listening on the lowercase app_server endpoint, the client request is rejected.

4.3 DECnet String Binding Formats Supported in This Release

To support the use of string bindings in this release, Compaq has added the following DECnet value to the list of supported protocol sequences:

ncacn_dnet_nsp

Unlike TCP/IP and UDP/IP, DECnet allows a named endpoint. An example of a DECnet protocol sequence named endpoint is TESTNAME. Compaq recommends that you use uppercase names with no more than 15 characters.

An example of an object number is #17. The # (number sign) character must precede an object number.

At present, there are no DECnet Phase IV options.

Beginning with OpenVMS Alpha Version 7.2, RPC provides WINNT as an additional authentication service. WINNT, which is based on Microsoft's NTLM authentication protocol, allows you to build RPC client or server applications using WINNT authentication. These applications will allow secure communications in a Microsoft security environment.

5.1 Using WINNT Authentication with RPC Server Applications

To accept requests that use WINNT authentication, the RPC server application must do the following:

1. The server application must call rpc_server_register_auth_info() to tell the server RPC runtime that it supports WINNT authentication.
2. When the server application is run, it uses all WINNT security information from the current address space. If the process that deploys the server application has not acquired WINNT security information for its address space, then the RPC server's call to rpc_server_register_auth_info() will fail. To obtain WINNT security information, the NTA$LOGON utility must be run.

For an RPC server application to impersonate the requesting client, you must complete the following:

1. The first input parameter to each RPC server manager routine is a binding handle that represents the requesting client. If the RPC server application wants to impersonate the client represented by the binding handle, then the RPC server manager routine must call rpc_impersonate_client() with the binding handle as input. This allows the RPC server to use the WINNT and OpenVMS security information of the client instead of the WINNT and OpenVMS security information of the server.
2. When the RPC server application wants to run with its original WINNT and OpenVMS security information, it must call either rpc_revert_to_self() or rpc_revert_to_self_ex().
   Running with WINNT security information means that the RPC application accesses a resource on the system that has WINNT access control lists. The operting system checks the RPC application's WINNT security information to determine if access is allowed. If the application accesses a resource with OpenVMS ACLs, it is checked against the OpenVMS security information of the application.

For an RPC client application to send requests that will use WINNT authentication, you must complete the following:

1. The client application must call rpc_binding_set_auth_info() to set WINNT authentication information on the binding.
2. The client application must pass security credential information to rpc_binding_set_auth_info(). Use the rpc_binding_set_auth_info() auth_ident parameter value to pass WINNT security information. The auth_ident parameter can have one of the following two values:
   • The auth_ident parameter supplied to rpc_binding_set_auth_info() is NULL. If this is the case, then the client application will use all WINNT security information from the current address space. If the process that deploys the client RPC application has not acquired WINNT security information for it's address space, then the RPC client's call to rpc_binding_set_auth_info() will fail. To obtain WINNT security information, the NTA$LOGON utility must be run.
   • Supply a valid rpc_auth_identity_handle_t obtained from a call to rpc_winnt_set_auth_idenity(). This option allows the client to use WINNT security information other than that of the current address space.

The following routines have been created or enhanced to support the WINNT authentication service:

rpc_binding_set_auth_info() rpc_server_register_auth_info() rpc_binding_inq_auth_info() rpc_binding_inq_auth_client() rpc_mgmt_inq_dflt_authn_level() rpc_mgmt_inq_server_princ_name() rpc_winnt_set_auth_identity() rpc_winnt_free_auth_identity() rpc_impersonate_client() rpc_revert_to_self() rpc_revert_to_self_ex()

For more information on the RPC security APIs, see the Compaq DCE for OpenVMS VAX and OpenVMS AXP Reference Guide.

5.3 Using the NTA$LOGON Utility

The NTA$LOGON utility allows client and server applications to obtain WINNT security information. This section provides NTLOGON syntax and usage examples. For more information on the NTA$LOGON utility, see the OpenVMS Connectivity Guide.

NAME

NTLOGON --- Invokes the NTA$LOGON utility

SYNOPSIS

ntlogon username password
Note that all character strings will be converted to uppercase unless they are enclosed in double quotations ("""").

QUALIFIERS

/LOG
Displays the result of a transaction.
/LIST
Lists the NT credentials for the current process. This is the natural persona.
/DELETE
Deletes the NT credentials for the current process.
/DOMAIN = domain
Specifies a different domain.

EXAMPLES

The following example shows how to use the NTA$LOGON utility:

$ ntlogon/list [Persona #1 NT extension: Account= "TESTACCNT" Domain= "OPENVMS_ARPC" ] $ ntlogon/delete $ ntlogon/list ERROR: NtOpenProcessToken() failure: -1073741700 0xc000007c %SYSTEM-E-NOSUCHEXT, no such extension found $ ntlogon TESTSACCNT examplepassword $ ntlogon/list [Persona #1 NT extension: Account= "TESTACCNT" Domain= "OPENVMS_ARPC" ] $ ntlogon/log/domain=openvms_dcom "okelley" "password" [Deleting existing NT extension] [Persona #1 NT extension: Account= "okelley" Domain= "OPENVMS_DCOM" ]

For more information on setting up your OpenVMS environment to use WINNT authentication, see the OpenVMS Connectivity Developer's Guide.

This chapter provides the names and locations of important DCE directories and files as they are installed and used with Compaq DCE for OpenVMS VAX and OpenVMS Alpha systems. Tables show the correlation between Compaq DCE directories and files and their counterparts on other DCE kits.

6.1 DCE Directories

DCE installation and configuration creates a number of directories that are required for proper DCE execution. On Compaq DCE for OpenVMS VAX and OpenVMS Alpha, you can access the top-level DCE directory by using the logical name DCE$LOCAL. This is the top-level DCE directory named DCE$LOCAL:[000000]. On a Tru64 UNIX system, the corresponding DCE local directory is created in /opt/dcelocal. The DCE services database, named dce_services.db, and the DCE configuration database, named dce_cf.db, reside in this top-level DCE local directory.

On Compaq DCE for OpenVMS VAX and OpenVMS Alpha systems, the DCE databases, which are created when the dced daemon starts, are located in the directory DCE$LOCAL:[VAR.DCED]. On a Tru64 UNIX system, these databases are located in the directory /opt/dcelocal/var/dced.

Table 6-1 lists the names of the DCE directories on Compaq DCE for OpenVMS VAX and OpenVMS Alpha and the corresponding directory names on Compaq DCE for Tru64 UNIX systems.

Table 6-1 DCE Directories for OpenVMS and Tru64 UNIX

OpenVMS DCE Directory Name	Tru64 UNIX Equivalent
DCE$LOCAL:[000000]	/opt/dcelocal
DCE$LOCAL:[VAR]	/opt/dcelocal/var
DCE$LOCAL:[VAR.DIRECTORY]	/opt/dcelocal/var/directory
DCE$LOCAL:[VAR.DCED]	/opt/dcelocal/var/dced

6.2 Setup Utilities

DCE installation also provides procedures and utilities to help you configure your DCE environment. On Compaq DCE for OpenVMS VAX and OpenVMS Alpha, these procedures are placed in the SYS$MANAGER and SYS$STARTUP directories, with the exception of the DCE$DEFINE_OPTIONAL_COMMANDS.COM procedure, which is in the SYS$COMMON:[DCE$LIBRARY] directory. On a Tru64 UNIX system, equivalent utilities reside in /usr/sbin.

Table 6-2 lists the names of the Compaq DCE for OpenVMS setup command procedures and their equivalent Tru64 UNIX utilities.

Table 6-2 DCE Setup Utilities for OpenVMS and Tru64 UNIX

OpenVMS Filename	Tru64 UNIX Equivalent
DCE$DEFINE_OPTIONAL_COMMANDS.COM	NONE
DCE$DEFINE_REQUIRED_COMMANDS.COM	NONE
DCE$SETUP.COM	dcesetup
DCE$SHUTDOWN.COM	NONE
DCE$STARTUP.COM	NONE

6.3 Executable Images

Following installation on an OpenVMS VAX or OpenVMS Alpha system, all DCE executable images reside in the SYS$SYSTEM directory. On a Tru64 UNIX system, these images reside in /usr/bin.

Table 6-3 lists the names of the executable images on an OpenVMS system and the names of the equivalent images on a Tru64 UNIX system.

Table 6-3 Executable Images for OpenVMS and Tru64 UNIX

OpenVMS Filename	Tru64 UNIX Equivalent
DCE$ACL_EDIT.EXE	acl_edit
DCE$ADD_ID.EXE	NONE
DCE$AUDITD.EXE	auditd
DCE$CADUMP.EXE	cadump
DCE$CDSADV.EXE	cdsadv
DCE$CDSBROWSER.EXE	cdsbrowser
DCE$CDSCLERK.EXE	cdsclerk
DCE$CDSCP.EXE	cdscp
DCE$CDSD.EXE	cdsd
DCE$CHECK.EXE	dcecheck
DCE$CHPASS.EXE	NONE
DCE$CSRC	csrc
DCE$DCECP.EXE	dcecp
DCE$DCED.EXE	dced
DCE$DCE_LOGIN.EXE	dce_login
DCE$DCESX.EXE	dcesx
DCE$DTSCP.EXE	dtscp
DCE$DTSD.EXE	dtsd
DCE$DTS_NTP_PROVIDER	dts_ntp_provider
DCE$DTS_NULL_PROVIDER	dts_null_provider
DCE$EXPORT.EXE	NONE
DCE$GDAD.EXE	gdad
DCE$GETCELLS.EXE	getcells
DCE$IDL.EXE	idl
DCE$IMPORT.EXE	NONE
DCE$KCFG.EXE	kcfg
DCE$KDESTROY.EXE	kdestroy
DCE$KINIT.EXE	kinit
DCE$KLIST.EXE	klist
DCE$LDAP_ADDCELL.EXE	ldap_addcell
DCE$LDAPDELETE.EXE	NONE
DCE$LDAPMODIFY.EXE	NONE
DCE$LDAPMODRDN.EXE	NONE
DCE$LDAPSEARCH.EXE	NONE
DCE$NSEDIT.EXE	NONE
DCE$NSID.EXE	nsid
DCE$RGY_EDIT.EXE	rgy_edit
DCE$RPCCP.EXE	rpccp
DCE$RPCLM.EXE	rpclm
DCE$SEC_ADMIN.EXE	sec_admin
DCE$SEC_CREATE_DB.EXE	sec_create_db
DCE$SECD.EXE	secd
DCE$SEC_SALVAGE_DB.EXE	sec_salvage_db
DCE$SEC_SETUP.EXE	NONE
DCE$SVCDUMPLOG.EXE	svcdumplog
DCE$TCL.EXE	NONE
DCE$UAF.EXE	NONE
DCE$UUIDGEN.EXE	uuidgen
DCE$X500_ADDCELL.EXE	x500_addcell

	privacy and legal statement
6532_DCE_PG_PRO_002.HTML