![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Although convenient, autoregistration of DECnet Phase V nodes presents a potential security risk because allowing autoregistration into a specific directory adds write access for the world (.*...) to the access control set (ACS) for that directory. Therefore, all users in the network can create child directories, objects, and soft links in that directory.
Note
Once a node has been registered into the directory, its registration can be modified only by the node itself or by an authorized namespace manager. The security risk applies to the directory but not to the node-name objects within the directory.
If you disallow autoregistration in a directory, the namespace is more secure because only authorized users can create entries in that directory. However, node names in that directory must be registered by an authorized namespace manager.
Allowing Autoregistration
To allow node autoregistration for a directory, select Option 11 at the decnet_register_decdns main menu. The following messages appear. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:
Allow DECnet-Plus node autoregistration in a directory.
Press Ctrl-Z when done.
* Directory name:
For help answering the prompt, refer to the following:
Directory Name
Specify the full name for the directory whose access is to be modified. This should not include a node name; for example, .Japan.Osaka.
In this example, autoregistration is enabled. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:
* Directory name: .Japan.Osaka
Modifying world write access to allow node autoregistration in this directory.
* Directory name:
Disallowing Autoregistration
To allow or disallow node autoregistration for a directory, select Option 12 at the decnet_register_decdns main menu. The following messages appear. Press the appropriate control key sequence for your platform to exit. Output is similar to the following example:
Allow or disallow DECnet-Plus node autoregistration in a directory.
Press Ctrl-Z when done.
* Directory name:
On OpenVMS systems, select Option 11 to create an interactive subprocess where you can enter NCL and other commands.
Enter the DCL logout command to terminate the subprocess and return to decnet_register.
This chapter provides information about four methods you can use to modify your network configuration:
This chapter also explains how you can create network server processes and how to delete and disable entities on all DECnet Phase V systems.
The DECnet-Plus software provides a configuration procedure, NET$CONFIGURE.COM, that you use to set up a basic, working node. The procedure produces a set of files called NCL scripts. To modify your network, rerun your configuration procedure, make the appropriate changes, and reboot the system. This modifies the configuration scripts and makes the changes permanent.
Note
Digital recommends that you use the configuration procedure to modify your node.
To customize your system beyond what the configuration procedure provides, you must edit the NCL scripts produced by the configuration procedure (see Section 6.2.2).
NCL is a command-based tool that lets you set up, modify, and display information about any DECnet-Plus entity. You may, at times, want to manage an attribute of an entity, such as a buffer size. To perform this task, you need to use NCL to make the change interactively or you need to edit the NCL scripts produced by the configuration procedure.
You should manage your DECnet-Plus system this way only if:
NCL supports an optional initialization file and an optional key definition file:
For more information, refer to the DECnet-Plus Network Control Language Reference guide.
Interactive NCL is useful only for temporary changes to a configuration. When you make changes to the running node using NCL interactively, the changes become effective immediately, but last only until the system is rebooted. For example, you might want to monitor a set of counters for a particular entity or you might want to temporarily disable a link.
The following steps briefly explain how to use interactive NCL:
ncl> set ncl default entity node node-id
An NCL script is an ASCII file of NCL commands that sets up the network management entities. These commands reflect the configuration you specified in the configuration procedure. You can edit the script files with a text editor to make permanent changes to your configuration. You can also edit the NCL script to add features that are not covered by the configuration procedure.
The following example shows a typical example (Routing module) of a script file produced by a configuration procedure.
create node 0 routing type endnode
set node 0 routing phaseiv address = 19.5
enable node 0 routing
create node 0 routing circuit csmacd-0 type = csma-cd
set node 0 routing circuit csmacd-0 data link entity = -
csma-cd station csmacd-0
enable node 0 routing circuit csmacd-0
The configuration procedure produces a script file for each module that it can configure. However, the configuration procedure creates more than one script file for some tasks. Therefore, manually making some changes to your configuration might require you to edit more than one NCL script. Script files have names that indicate what modules they implement.
Some common NCL scripts are:
The Installation and Configuration guides for your system provide full information about the configuration procedure and NCL scripts generated.
The following steps briefly explain how to edit NCL scripts:
ncl> do ncl_script_file
ncl> do sys$manager:net$nsp_transport_startup.ncl
You may also need to alter DECdns or DECdts modules and entities. Refer to DECnet-Plus DECdns Management, DECnet-Plus DECdts Management, and the installation and configuration guides for your system for this information.
If you wish to have site-specific NCL commands in scripts, create files called NET$APPLICATION_LOCAL.NCL, NET$EVENT_LOCAL.NCL, and NET$MOP_CLIENT_LOCAL.NCL in the SYS$MANAGER directory. If these files exist, the network startup procedure executes these scripts immediately after the NET$APPLICATION_STARTUP.NCL, NET$EVENT_STARTUP.NCL, and NET$MOP_CLIENT_STARTUP.NCL scripts supplied by Digital are executed.
If you do not need to modify the Digital-supplied scripts, place your site-specific NCL commands in these user-defined NCL scripts. These user-defined scripts will not be overwritten or deleted by NET$CONFIGURE.COM because they are maintained by the user.
Prior to starting the network with NET$STARTUP.COM, you can modify components of the network by using the following system logical names:
$ define/system net$routing_startup - _$ sys$sysroot:[sysmgr.network_scripts]net$routing_startup.ncl
If you want the operating system to define these logicals before starting the network, place these system logical definitions in the SYS$MANAGER:NET$LOGICALS.COM file. (If you do not have the SYS$MANAGER:NET$LOGICALS.COM file on your system, you can create one using SYS$MANAGER:NET$LOGICALS.TEMPLATE.)
On the OpenVMS operating system, all DECnet Phase V applications run as processes. Unless a currently running process has declared itself to be a numbered network application or a named network application (with number 0), the network ancillary control program (NET$ACP) must invoke a process to receive the connect request.
When the logical link request comes in, a standard procedure called NET$SERVER.COM runs, which in turn causes NET$SERVER.EXE to be executed. This program works in concert with NET$ACP to invoke the proper program for the requested application. Then, when the logical link is disconnected, the application program (such as file access listener (FAL)) terminates, but the process is not deleted. Instead, control returns to the NET$SERVER.EXE program, which asks NET$ACP for another incoming logical link request to process. This cycle continues until NET$SERVER is deleted after a specified time limit. The default is 5 minutes. To use a different default time limit, define the system logical name NETSERVER$TIMEOUT in SYS$MANAGER:NET$LOGICALS.COM, using an equivalence string in the standard OpenVMS delta time format:
For example, to set the time limit to 30 minutes, use the following command:
$ define/system netserver$timeout "0 0:30:0"
The effect of NET$SERVER is to reuse network server processes for more than one logical link request, eliminating the overhead of process creation for an often-used node. The network ancillary control program (NET$ACP) reuses a NET$SERVER process only if the access control on the connect request matches that used to start the process originally.
When NET$ACP creates a process to receive the connect request, the process runs like a batch job. The sequence is as follows:
Because NET$SERVER.LOG files are not required for network server processes, you can explicitly inhibit all log files in your default nonprivileged DECnet-Plus account by setting the default directory for the account to a nonexistent directory. The effect of this action is to suppress all log files, while allowing network jobs to run.
This section explains how to delete and disable network entities, and what you must do prior to recreating a previously deleted entity. In general, the procedures are the same for most entities.
To delete an entity, you must usually disable that entity first. Disabling an entity means you are putting the entity into the off state. You must also delete entities in order. That is, you must delete a child entity before you can delete the parent entity. After deleting the child entity, you can delete the parent. Then the entity is completely deleted. In some cases, the DECnet-Plus software automatically deletes entities. The DECnet-Plus Network Control Language Reference indicates which commands support the various entities.
The following example disables and deletes routing for end systems using csma-cd links. Remember that the procedure applies to disabling and deleting most DECnet Phase V entities.
ncl> disable routing circuit csmacd-0 reachable address reachable-address (1)
ncl> delete routing circuit csmacd-0 reachable address reachable-address (2)
ncl> disable routing circuit csmacd-0 (3)
ncl> delete routing circuit csmacd-0 (4)
ncl> disable routing (5)
ncl> delete routing (6)
DECnet-Plus regulates access to the network on various levels, including the following:
The following sections describe these levels of control for DECnet-Plus.
To perform any kind of network activity, all network users must have TMPMBX and NETMBX privileges and certain rights identifiers enabled. You can define a user's rights and privileges with the OpenVMS Authorize utility (see Section 7.3.4). For more information about using this utility, refer to the OpenVMS System Management Utilities Reference Manual.
Identifiers are created in the rights database during installation. Table 7-1 lists the rights identifiers that you and network users need.
| Rights Identifier | Description |
|---|---|
| NET$DECLAREOBJECT | Declares an application |
| NET$DECNETACCESS | Gives $IPC users access to the network in the absence of the NETMBX privilege |
| NET$DIAGNOSE | Permits use of network diagnostics |
| NET$EXAMINE | Permits display of the attributes of an entity |
| NET$MANAGE | Permits display, creation, or modification of an entity |
| NET$POSTEVENT | Permits posting of events |
| NET$REGISTERDNSOBJECT | Permits registration or deregistration of a DECdns object |
| NET$SECURITY | Permits setting a user name for session control or session control application |
| NET$TRACEALL | Permits tracing of entire messages on a local node |
| NET$TRACEALLREMOTE | Permits tracing of entire messages on a remote node |
| NET$TRACEHEADERS | Permits tracing of message headers on a local node |
| NET$TRACEHEADERSREMOTE | Permits tracing of message headers on a remote node |
DECnet-Plus for OpenVMS uses OpenVMS rights identifiers to perform access checks on all manageable entities. This differs from the Phase IV software, which used OpenVMS privileges for access to the permanent database and for write access. Read access to the volatile database in Phase IV was unprotected.
In DECnet-Plus for OpenVMS, the rights identifier NET$EXAMINE grants a user read access to the network configuration data. The NET$MANAGE rights identifier grants read and write access to the network configuration data, and NET$SECURITY grants the ability to set default accounts. These new rights allow the network manager to restrict access to network parameters. Access is granted to an individual user by means of the Authorize utility on OpenVMS. The following command examples grant access.
Examples
UAF> grant/id net$examine Joe ! Grant user Joe read access to local network dataUAF> grant/id net$manage Joe ! Grant user Joe read/write access to local network dataUAF> grant/id net$security Joe ! Grant user Joe ability to set default accounts
In lieu of NET$MANAGE rights, the BYPASS privilege will grant read and write access.
When issuing NCL commands to the local node (for example, ncl show all or ncl show node 0 all), the rights of the executing process determine whether access is granted.
When issuing NCL commands to the remote node (for example, ncl show node remote-node-name all or ncl set ncl default entity node remote-node-name), a connection is established to the Common Management Information Protocol (CMIP) Management Listener (CML) application on the remote node. Access checks performed on the remote node depend on the account the remote CML application is running in (on an OpenVMS node). When the connection comes into an OpenVMS machine, a process is created to run the CML application. Which account is used is determined in the following order:
If the account that runs the CML application does not have the NET$EXAMINE for read access, or NET$MANAGE identifier for read and write access, then the access is denied by the management agent.
The manager of the remote node must take explicit action to allow an individual user access to the network configuration information. For example:
The last option is one of the selections offered by NET$CONFIGURE when configuring the application database. If you select to have a default account for the CML application, NET$CONFIGURE will grant the NET$EXAMINE right to that account by default.
Whenever a DECnet node attempts to connect to a remote DECnet-Plus node, it sends access control information to the session control entity on the remote node. Access control allows you to control connections between nodes. Access control information can come from a number of sources. The following list shows the hierarchy of access control from highest to lowest priority:
PROFILE_VMS_006.HTML OSSG Documentation 2-DEC-1996 12:34:55.62
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.