![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Finally, if none of these sources supply valid access control information, the connection fails.
Note
In DECnet-Plus, nonprivileged means having NET$DECNETACCESS rights and TMPMBX and NETMBX privileges. These are the minimal rights and privileges necessary for any network activity. Privileged means any rights and privileges in addition to NET$DECNETACCESS rights and TMPMBX and NETMBX privileges.In Phase IV, nonprivileged means NETMBX and TMPMBX privileges only. NETMBX and TMPMBX are the minimal requirement for any network activity. Privileged means any privileges in addition to NETMBX and TMPMBX.
You can check if there is a default nonprivileged user name for session control by issuing the following command:
ncl> show session control non privileged user
You can check if there is a default nonprivileged account for applications by issuing the following command:
ncl> show session control application fal user name
You can request the configuration command procedure, NET$CONFIGURE.COM, to establish the default nonprivileged DECnet account and directory for you automatically. If you want to add a default nonprivileged DECnet account manually, see Section 7.3.4.
You must establish access control information for applications in the application database.
Note
You do not need to use access control information when a connection to a program has declared an application name and has started independently of DECnet.Instead, you need NET$DECLAREOBJECT rights to declare that you want to accept incoming connections.
If you want to execute an NCL command on a remote node, you can do so by supplying explicit access control information. The access control information contains a user name and password and provides access to a specific account on the remote system. To supply explicit access control information, you can use either a standard OpenVMS node specification (node"username password") or you can use the NCL prepositional phrase by with a user name and password. For more information about a standard OpenVMS node specification, refer to the OpenVMS DCL Dictionary.
In the following example, you can display all characteristics information about the application statistics on the remote node toronto by specifying a user name and password with the prepositional phrase by.
ncl> show node toronto session control application - _ncl> statistics all characteristics, by user a_johnston, - _ncl> password general
Proxy login enables a user logged in at a remote node to be logged in automatically to a specific account at the local node, without having to supply any access control information. Note that proxy login is not the same as interactive login. Proxy login means that specific network access operations can be executed. By contrast, interactive login requires a user to supply a user name and password before the user can perform any interactive operations.
To establish proxy login on the local node (without specifying any access control information), the remote user must have a default proxy account on the local node that maps to a local user name. The remote user assumes the same file access, same rights, and same privileges as the local user name. You can use the proxy login capability to increase security, because it minimizes the need to specify explicit access control information in node specifications passed over the network or stored in command procedures.
If you are going to have access to more than one proxy account from the same node and login name, indicate which proxy account should be the default.
Note that network applications can also be assigned proxy login access.
If a remote user's connection request does not contain access control information, the following conditions must be met for proxy to be approved:
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
Note
You must include a proxy entry for each type of node name the remote user may use. For example, a user might specify the DECdns namespace name or the local namespace as part of the node name. Include a separate entry for each case. The following example sets up three proxy entries mapping user martin at a remote node to user allen at the local node: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.
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
Note
NCL ignores any use of the by proxy=false clause.
For examples of setting up session control application, refer to Appendix F.
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.
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.
Note
NET$CONFIGURE.COM sets incoming and outgoing proxy to false for the MAIL application. If you already have a previous version of DECnet running, the proxy may be set to true. If you want to change the setting to false, you must either run NET$CONFIGURE and select Option 1 to recreate the Session Control Application startup script, or edit SYS$MANAGER:NET$APPLICATION_STARTUP.NCL to change the settings of these attributes to false.
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]
For information on using the Authorize utility, refer to the OpenVMS System Management Utilities Reference Manual.
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)
Appendix F provides an example of setting up a routing initialization password.
Note
If a remote node has more than one id (a DECnet Phase V address and a Phase IV address), you must specify all of the ids in the permitted neighbor entity. For example: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:
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:
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
Use the methods for manually modifying your configuration only when your customization needs exceed what is provided by the configuration procedures. Use the configuration procedure to modify your node's network configuration whenever possible.
Note that you can also define logical names to modify network startup, as explained in Chapter 6.
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.
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:
These changes can affect the following or some combination of the following:
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.
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.
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.
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.
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:
Use the following steps to change the node name of a DECnet Phase V system:
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.
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.
You can configure the device and modem control entities using WANDD$STARTUP on OpenVMS systems (X25$CONFIGURE and NET$CONFIGURE automatically invokes WANDD$STARTUP if needed). For more information on running wansetup, refer to the X.25 documentation.
On OpenVMS systems, you can load microcode into the DSB, DSF, DSV, and DSW communications devices and dump microcode from these devices back to the host system by using the device entity. If you use the WANDD$STARTUP.COM procedure, the information discussed in this section is set up automatically.
PROFILE_VMS_007.HTML OSSG Documentation 2-DEC-1996 12:34:57.41
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.