HP OpenVMS Systems Documentation

If a remote user's connection request does not contain access control information, the following conditions must be met for proxy to be approved:

• The proxy database on the target node must contain a source node's node synonym and source user name combination that matches the remote source node's node synonym and source user name.
• The target node's system authorization file must contain a source user name that matches the proxy database entry's target source user name.
• The session control characteristic incoming proxy must be enabled for the target node.
• The session control application characteristic incoming proxy must be enabled for the target application.

You can control the use of proxy login at the local node. Use the Authorize utility to create and modify the permanent proxy database, NETPROXY.DAT (or NET$PROXY.DAT), at your node. Each proxy database entry can map a single remote user to multiple proxy user names on the local node (one default proxy user name and up to 15 additional proxy user names). The proxy database entry identifies the user by a six-character node synonym in the form of nodename::username or nodename::[group,member]. (For information on using the Authorize utility, refer to the OpenVMS System Management Utilities Reference Manual.)

For example, to create a proxy database file at a local node and add a default proxy entry mapping user martin on remote node boston to user allen at the local node, enter the following commands:

$ set default sys$system
$ run authorize

uaf> create/proxy
uaf> add/proxy boston::martin allen/default
uaf> exit

uaf> create/proxy
uaf> add/proxy boston::martin allen/default
uaf> add/proxy acme:.boston.martin allen/default
uaf> add/proxy LOCAL:.boston.martin allen/default
uaf> exit

Similarly, the system manager at a remote node can create and maintain a proxy database of network users having proxy access to specific accounts on that node.

Refer to the security guide for your system and the OpenVMS System Management Utilities Reference Manual for more information on establishing proxy accounts.

7.3.2.2 Enabling or Disabling Incoming Proxy

The session control entity attribute incoming proxy allows you to control proxy access to your node. The session control application attribute incoming proxy allows you to control proxy access to a particular application.

If proxy access is disabled, the system treats the request as if proxy access were not requested. To disable proxy access on a systemwide basis, set the session control attribute incoming proxy to false. The following example shows the command you need to disable proxy access for a system:

ncl> set session control incoming proxy false

For proxy access to a particular application, you must enable proxy access to both the node and the application. For example, to enable proxy access for particular applications, set the session control attribute incoming proxy to true and set the session control application attribute incoming proxy to true for those applications to which you want to allow proxy access.

The following example shows the commands you need to enable proxy access for the application cml and to disable proxy access for the application fal:

ncl> set session control incoming proxy true
ncl> set session control application cml incoming proxy true
ncl> set session control application fal incoming proxy false

For examples of setting up session control application, refer to Appendix F.

7.3.2.3 Removing Proxy Access

You should remove proxy access to the system when it is no longer needed. Invoke the Authorize utility and enter the following command to remove proxy access:

uaf> remove/proxy boston::martin

For information on using the Authorize utility, refer to the OpenVMS System Management Utilities Reference Manual.

7.3.3 Specifying Default Access Control Information for Applications

Another form of access control specific to network applications is default account information used by inbound connects from remote nodes that send no access control information. Because the remote node supplies no access control information, the local node uses the default information you specify for the application to make the connection.

You can use the following command to store default access control information about the application in the session control application entity. To execute this command you need NET$SECURITY rights.

ncl> set session control application fal user name jill

You can use the NET$CONFIGURE.COM procedure to create DECnet accounts for the fal, mail, mirror, and cml network applications.

You can also use NET$CONFIGURE.COM to configure your node and request nonprivileged DECnet accounts. The following example shows how to set up nonprivileged DECnet accounts yourself:

$ set default sys$system
$ run authorize

uaf> add netnonpriv/password=nonpriv/device=device-name: - (1)
_ /directory=[netuser]/uic=[200,200] -
_ /flags=(restricted,nodisuser)/nobatch/nointeractive/lgicmd=nl:
uaf> exit

$ grant/identifier net$decnetaccess netnonpriv (2)
$ create/directory device-name:[netuser]/owner_uic=[200,200]

1. device-name is the name of the device on which you have your directory.
2. Grants the NET$DECNETACCESS right that allows access to the network.

For information on using the Authorize utility, refer to the OpenVMS System Management Utilities Reference Manual.

7.3.5 Deleting a Default Nonprivileged DECnet Account

Default nonprivileged DECnet accounts provide unrestricted, open access to DIGITAL systems. The following command example shows how to enhance the security of a system or the network by deleting these accounts:

$ set default sys$system
$ run authorize

uaf> remove netnonpriv
uaf> exit

For point-to-point connections, especially over dialup lines, you can use routing initialization passwords to verify that the initiating node is authorized to form a connection with your node. Each end of a point-to-point circuit can establish a verifier to transmit to the other node, and specify a verifier expected from the other node. Before the link is established, each node verifies that it received the expected verifier from the other node.

Passwords are usually optional for point-to-point connections but are required for dynamic asynchronous connections. To provide for increased security when a remote node requests a dynamic asynchronous connection (which is normally maintained only for the duration of a telephone call), the node requesting the dynamic connection supplies a password, but the node receiving the login request is prevented from revealing a password to the requesting node.

The following command example shows how to set up a routing initialization password:

ncl> create routing type endnode
ncl> enable routing
ncl> create routing circuit hdlc-0 -
_ncl> type hdlc (1)

ncl> set routing circuit hdlc-0 -
_ncl> transmit verifier hex-string (2)
ncl> set routing circuit hdlc-0 -
_ncl> explicit receive verification false (3)

ncl> set routing circuit hdlc-0 -
_ncl> receive verifier hex-string (4)
ncl> enable routing circuit hdlc-0

ncl> create routing permitted neighbor -
_ncl> neighbor-name id node-id (5)
ncl> set routing permitted neighbor -
_ncl> neighbor-name verifier hex-string (6)

1. The circuit type can be one of the following:
   • ddcmp
   • hdlc
   • x25 static outgoing
2. If you need to send a routing layer password to the remote node, set this attribute to the value you want to transmit. If the remote node requires a verifier and this attribute has not been set, the circuit does not come up.
3. This specifies the type of verification performed on received verifiers. If you set this attribute to true, the received verifier is checked against the value of the characteristic receive verifier for this circuit. If set to false, the received verifier is checked against the set of verifiers specified in the permitted neighbors entity. That is, the node id of the remote system is used as a search key into the permitted neighbor database to locate the verifier (password). The password is then checked against the verification data exchanged during the circuit initialization sequence.
4. This specifies the value against which the verifier transmitted by a neighbor node is checked, if explicit receive verification is set to true. If no verifier is specified, no verification is performed.
5. During connection initialization, the node id of the remote system is used to select a specific permitted neighbor. The verifier from the remote system is then compared against the verifier in the permitted neighbor. If there is a match, or the verifier in the permitted neighbor is null, then the point-to-point connection is accepted.
6. The verifier is a read-only attribute. Routing does not display it.

Appendix F provides an example of setting up a routing initialization password.

ncl> create routing permitted neighbor -
_ncl> nashua_decnet-osi id 08-00-2b-12-34-56

ncl> set routing permitted neighbor -
_ncl> nashua_decnet-osi verifier %x1234

ncl> create routing permitted neighbor -
_ncl> nashua_phase_iv id aa-00-04-00-12-34

ncl> set routing permitted neighbor -
_ncl> nashua_phase_iv verifier %x1234

This chapter explains common management tasks necessary to customize DECnet Phase V communications for your DECnet-Plus system:

• Managing a node, including how to reconfigure, start up, and shut down DECnet-Plus software on your system, and how to manage remote DECnet Phase IV nodes ( Section 8.1)
• Managing Physical layer devices and modem connect lines ( Section 8.2)
• Managing data links ( Section 8.3)
• Configuring routing ( Section 8.4)
• Managing NSP and OSI transport services ( Section 8.5)
• Managing session control ( Section 8.6)
• Managing the Open System Application Kernel (OSAK) ( Section 8.7)
• Configuring X.25 services ( Section 8.8)

This chapter assumes that you have configured your system and created a basic working DECnet-Plus configuration. This chapter provides the information you need to manually modify your network's configuration. You can manually modify the configuration in the following ways:

• Editing NCL script files to make permanent changes
• Issuing interactive NCL commands to make temporary changes

Use the DECnet-Plus for OpenVMS configuration procedure (NET$CONFIGURE) to make permanent changes automatically. For information on using the DECnet-Plus configuration procedure, see the DECnet-Plus for OpenVMS Installation and Basic Configuration and DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration. For more information about the manual configuration methods, see Chapter 6.

Note that you can also define logical names to modify network startup, as explained in Chapter 6.

8.1 Managing a Node

Generally, your DECnet-Plus software starts at system boot time. However, in some situations, you may need to start and stop DECnet-Plus on your system, such as for testing. In some situations, you may need to reconfigure DECnet-Plus, such as after changing the hardware configuration or network management parameters. The following sections describe the tools suitable for these tasks.

8.1.1 Reconfiguring DECnet-Plus

DECnet-Plus provides configuration procedures that enable you to reconfigure your node. The procedures create new startup scripts for DECnet-Plus entities, and sometimes save any original procedures that you might have customized. Whenever possible, use the configuration procedure to reconfigure, especially if you want to significantly modify your network. Significant changes might include:

• New communications hardware
• A new network address
• A change in the node name
• Creating a new OSI transport template

These changes can affect the following or some combination of the following:

• Namespace name
• Node object name
• Directory path in which the node object is located

For information about using the configuration procedure, refer to your installation and configuration guides. The procedures for configuring DECnet-Plus create NCL scripts that create and enable certain entities (as necessary and appropriate) and set appropriate network management attributes. In general, you can permanently customize an entity by including changes in the correct NCL script.

8.1.2 Starting Up DECnet-Plus

On OpenVMS systems, DECnet-Plus starts automatically. If you should need to restart DECnet-Plus for any reason (for example, after shutting down the network by executing SYS$STARTUP:NET$SHUTDOWN.COM), then you can restart the network using the following command:

@SYS$STARTUP:NET$STARTUP

The directory SYS$MANAGER contains the NCL scripts. Prior to starting the network, you can modify components of the network by using system logical names, as explained in Section 6.3.

8.1.3 Shutting Down DECnet-Plus

Use the SYS$MANAGER:NET$SHUTDOWN.COM shutdown procedure to disable and delete the various network entities on the local node.

The shutdown procedure stops all logical links and OSI components (Open System Application Kernel (OSAK), Virtual Terminal (VT), and File Transfer Access Module (FTAM)), as well as X.25 Access software (formerly known as VAX P.S.I.), if they are running. CSMA-CD stops unless the local area transport (LAT) is running. The procedure disables and deletes most DECnet Phase V entities.

8.1.4 Enabling a Node

To manually enable the node entity on an OpenVMS system, issue the following command:

ncl> enable node 0 function address watcher

This enables the address watcher, changing the system's state from OFF to ON.

8.1.5 Renaming a Node

To rename a node in a DECdns or local namespace, use decnet_register to register the new name and then run the DECnet-Plus configuration procedure to specify the full node name. The full name includes the namespace name and the names of all its directories, starting from the root. Elements within a full name are separated by periods and are known as simple names.

Some reasons for changing node names include:

• The namespace name has changed (for example, XYZ_CORP:.boston.artist to ABC_CORP:.boston.artist).
• The directory path has changed (for example, XYZ_CORP:.boston.artist to XYZ_CORP:.portland.artist).
• The node object name has changed (for example, XYZ_CORP:.boston.artist to XYZ_CORP:.boston.poet).

Use the following steps to change the node name of a DECnet Phase V system:

• Choose a new node name.
• Use decnet_register to remove the original name from the local or DECdns namespace. See Chapter 5 for a discussion of decnet_register.
• For a name to be registered in the local or DECdns namespace, use the decnet_register tool to register the new system name.
• Rerun the configuration procedure, specifying the new node name (and the new synonym, if appropriate). If any other configuration parameters (such as addressing information) need to be changed, change them at this time.

The DECnet-Plus configuration procedure verifies that the new node name is properly registered, and attempts to update the addressing information associated with the node object name. The configuration procedure also updates the various entities that might be affected by the name change, including the DNS clerk and the Session Control modules.

8.1.6 Managing a Phase IV Node

From a DECnet-Plus for OpenVMS node, you can manage a remote Phase IV node by invoking the Network Control Program (NCP) Emulator and entering NCP commands. You must specify the remote Phase IV node using the tell or set executor node commands. For example:

$ run sys$system:ncp
NCP> set executor node remnod"account password"
NCP> zero exec counters

For more information about using the NCP Emulator for network management of remote DECnet Phase IV nodes, see Section 2.3.