Document revision date: 5 July 2000
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

Compaq DCE for OpenVMS VAX and OpenVMS Alpha
Product Guide


Previous Contents Index

3.3.3 Limitations on Using DCE in a VMScluster System

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:

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.


Chapter 4
Using Compaq DCE with DECnet

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.

4.2 Running DCE Server Applications Using DECnet

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

4.2.1 Server Account Requirements

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.


Chapter 5
Using Compaq DCE with Microsoft's NT LAN Manager (NTLM)

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:

Note

Be careful when passing in the auth_ident parameter to perform authentication. If multiple invalid authentications occur, OpenVMS generates an intrusion record. Any subsequent valid authentications will fail. If this occurs, contact your system manager to delete the intrusion record.

5.2 RPC APIs Created or Enhanced to Support WINNT Authentication

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.


Chapter 6
Directory Names, Filenames, and Locations Across DCE Platforms

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


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6532_DCE_PG_PRO_002.HTML