Document revision date: 19 July 1999

In Example 12-1, the security administrator at the node WALNUT wants to create a general access account called GENACCESS. At the same time the administrator wants to take steps to allow proxy logins by three users from the node BIRCH: KMahogany, PSumac, and WPine, as well as two users from the node WILLOW: RDogwood and WCherry. No network proxy authorization file currently exists.

Example 12-1 Sample Proxy Account

$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD GENACCESS /PASSWORD=WHYNADGUM/UIC=[236,043] - _UAF> /DEVICE=STAFFDEV/DIRECTORY=[GENACCESS] - _UAF> /OWNER="Security Mgmt"/ACCOUNT=SEC - _UAF> /FLAGS=(DISWELCOME,DISNEWMAIL,GENPWD,DISMAIL) - _UAF> /NOBATCH/NOINTERACTIVE/MAXDETACH=8 - _UAF> /LGICMD=LOGIN/MAXACCTJOBS=10 %UAF-I-ADDMSG, user record successfully added %UAF-I-RDBADDMSGU, identifier GENACCESS value [000236,000043] added to rights database %UAF-I-RDBADDMSGU, identifier SEC value [000236,177777] added to rights database UAF> CREATE/PROXY UAF> ADD/PROXY BIRCH::KMAHOGANY GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::KMAHOGANY to GENACCESS added UAF> ADD/PROXY BIRCH::PSUMAC GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::PSUMAC to GENACCESS added UAF> ADD/PROXY BIRCH::WPINE GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::WPINE to GENACCESS added UAF> ADD/PROXY WILLOW::RDOGWOOD GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.WILLOW::RDOGWOOD to GENACCESS added UAF> ADD/PROXY WILLOW::WCHERRY GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.WILLOW::WCHERRY to GENACCESS added UAF> SHOW/PROXY *::* Default proxies are flagged with a (D) OMNI:.BOSTON.BIRCH::KMAHOGANY GENACCESS (D) OMNI:.BOSTON.BIRCH ::PSUMAC GENACCESS (D) OMNI:.BOSTON.BIRCH ::WPINE GENACCESS (D) OMNI:.BOSTON.WILLOW ::RDOGWOOD GENACCESS (D) OMNI:.BOSTON.WILLOW ::WCHERRY GENACCESS (D) UAF> EXIT {messages} $ DIRECTORY/SECURITY SYS$STAFF:[000000]GENACCESS.DIR . . . $ DIRECTORY/SECURITY SYS$STAFF:[GENACCESS]LOGIN.COM . . .

12.4 Using DECnet Application (Object) Accounts

Network objects are system programs and user-written applications that permit communication among nodes in a DECnet network. You need to identify the set of network objects allowed access to your system, and set up the appropriate access controls for each object. The following mechanisms are available:

• DECnet object accounts These are individual accounts for specific network objects (for example, MAIL) automatically configured on your system. These provide more accountability of remote access to an object than the default DECnet account provides. (For example, an object can have a captive account with a login command procedure that grants or denies access to the object based on the remote node name or user name.)
• Default DECnet account This type of account allows all network objects general access to the system. It is appropriate for systems with low security requirements (for example, a local area network of systems located within a site with no outside connections or dialup lines). The default DECnet user name lets users perform certain network operations, such as the exchange of electronic mail between users on different nodes, without having to supply a user name and password. The default DECnet user name is also used for file operations when access control information is not supplied. For example, it lets remote users access local files on which the file protection has been set to allow world access. If you do not want remote users accessing your node, do not create a default DECnet user name. See Section 12.4.3 for information about removing default DECnet accounts.

You should understand the function of the network objects supplied with the OpenVMS operating system before you determine the access control to apply to them. This section provides a description of the most common network objects.

FAL

The file access listener (FAL) is the remote file access facility. FAL is an image that receives and processes remote file access requests for files at the local node.

Use of general FAL access is strongly discouraged. Open access allows general network access to any files marked world-accessible. It also allows remote users to create files in any directory with world write access.

Sites with high security requirements, or sites where it is difficult to recognize all the intended users, should not create a FAL account. To control which users gain access, these sites may establish one or more proxy accounts for specific purposes (see Section 12.3).

MAIL

MAIL is an image that provides personal mail services for OpenVMS systems. In most cases, allow the MAIL object general access to the system.

MIRROR

MIRROR is an image used for particular forms of loopback testing. For example, MIRROR is run during the DECnet phase of the UETP test package.

MOM

MOM is the Maintenance Operations Module. The MOM image downline loads unattended systems, transferring a copy of an operating system file image from an OpenVMS node to a target node. The MOM object is established during a system installation.

NML

NML is the network management listener. Remote users with access to NML can use NCP TELL commands to gather and report network information from your DECnet databases.

PHONE

PHONE is an image that allows online conversations with users on remote OpenVMS systems. Note that if you allow default DECnet access to PHONE, anyone in the network can get a list of users currently logged in to the local system and attempt a login using the list of user names.

TASK

Through the default DECnet account, the TASK object allows arbitrary command procedures (including those that might be used in intrusions) to be executed on your system.

Note that if you do not allow default DECnet access on your system or if you disable default DECnet access to the TASK object, you can allow remote user-written command procedures (tasks) to run on your system through the use of access control strings or proxy access.

VPM

VPM is the Virtual Performance Monitor Server. Access to VPM is required to use the cluster monitoring features of the Monitor utility (MONITOR).

12.4.2 Configuring Network Objects Manually

The command procedure NETCONFIG.COM configures the network objects on your system automatically, and the command procedure NETCONFIG_UPDATE.COM updates the network objects automatically.

If you choose not to use the command procedures, you can perform the following steps to allow network access to specific objects:

1. Create a top-level directory for each network object, and specify a unique owner UIC and group UIC. For example, the following command sequence creates a top-level directory for the MAIL object on the system disk:

   $ SET DEFAULT SYS$SPECIFIC:[000000] $ CREATE/DIRECTORY [MAIL$SERVER]/OWNER_UIC=[376,374]

   
   Table 12-2 lists the directory names, user names, and UICs used by the NETCONFIG.COM and NETCONFIG_UPDATE.COM command procedures to create accounts for specific network accounts. For consistency, you should specify the same information when manually creating network object accounts.
   Note that the MOM object is created by the operating system during installation.

2. Using AUTHORIZE, create an account for the object, and use a generated password. (Note that the user name and password that you specify must match the password defined for the object in the network database [described in step 3].)
   For example, the following command sequence sets up an account for the MAIL object:

   $ RUN SYS$SYSTEM:AUTHORIZE UAF> ADD MAIL$SERVER/OWNER=MAIL$SERVER DEFAULT - _UAF> /PASSWORD=MDU1294B/UIC=[376,374]/ACCOUNT=DECNET - _UAF> /DEVICE=SYS$SPECIFIC: /DIRECTORY=[MAIL$SERVER] - _UAF> /PRIVILEGE=(TMPMBX,NETMBX) /DEFPRIVILEGE=(TMPMBX,NETMBX) - _UAF> /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE) /LGICMD=NL: - _UAF> /NOBATCH /NOINTERACTIVE

   
   The AUTHORIZE command SHOW MAIL$SERVER displays the network account set up for the MAIL object, as shown in Example 12-2.

3. Use the NCP DEFINE command to associate the user name and password of the account with the specified object in the network database, as follows:

   $ RUN SYS$SYSTEM:NCP NCP> DEFINE OBJECT MAIL USER MAIL$SERVER PASSWORD MDU1294B NCP> EXIT

4. Repeat steps 1 through 3 for each network object.
5. When finished, remove default DECnet access from the executor database, and remove the default DECnet account from the SYSUAF (see Section 12.4.3).
6. Finally, reboot the system to copy changes made to the permanent executor and object databases to the running system.

Table 12-2 lists the network object defaults.

Table 12-2 Network Object Defaults

Object Name	Directory and User (Account) Name	UIC
FAL	FAL$SERVER	[376,373]
MAIL	MAIL$SERVER	[376,374]
MIRROR	MIRRO$SERVER+	[376,367]
$MOM	VMS$COMMON:[MOM$SYSTEM]++	[376,375]
NML	NML$SERVER	[376,371]
PHONE	PHONE$SERVER	[376,372]
VPM	VPM$SERVER	[376,370]

Example 12-2 UAF Record for MAIL$SERVER Account

Username: MAIL$SERVER Owner: MAIL$SERVER Account: MAIL$SERVER DEFAULT UIC: [376,374] ([DECNET,MAIL$SERVER]) CLI: DCL Tables: Default: SYS$SPECIFIC:[MAIL$SERVER] LGICMD: Login Flags: Restricted Primary days: Mon Tue Wed Thu Fri Sat Sun Secondary days: Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ##### Full access ###### ##### Full access ###### Batch: ----- No access ------ ----- No access ------ Local: ----- No access ------ ----- No access ------ Dialup: ----- No access ------ ----- No access ------ Remote: ----- No access ------ ----- No access ------ Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: (none) Pwdchange: (none) Last Login: (none) (interactive), (none) (non-interactive) Maxjobs: 0 Fillm: 16 Bytlm: 12480 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 12 JTquota: 1024 Prclm: 0 DIOlm: 6 WSdef: 180 Prio: 4 ASTlm: 16 WSquo: 200 Queprio: 0 TQElm: 10 WSextent: 0 CPU: (none) Enqlm: 20 Pgflquo: 25600 Authorized Privileges: TMPMBX NETMBX Default Privileges: TMPMBX NETMBX

12.4.3 Removing Default DECnet Access to the System

The default DECnet account is appropriate for systems with low security requirements (see Section 12.4). If your site has moderate or high security requirements, you should remove default DECnet access to the system once you have set up accounts for individual network objects.

To do this, remove access to the DECNET account in the network configuration database, and delete the DECNET account from the SYSUAF.

Removing Default DECnet Access

Execute the following NCP commands to remove the default DECnet access from the network executor database:

NCP> DEFINE EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET NCP> PURGE EXECUTOR NONPRIVILEGED PASSWORD

The DEFAULT_DECNET user specified in the first command is a nonexistent user account that is specified for auditing purposes only. (A network login failure message is written to the security audit log file each time access to your system is attempted through the [nonexistent] DEFAULT_DECNET account.)

Deleting the DECNET Account

Using AUTHORIZE, remove the DECNET account from SYSUAF, as follows:

$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> REMOVE DECNET UAF> EXIT

Delete any files in the [DECNET] directory structure.

Modifying the Volatile Configuration Database

To have the change take effect immediately, modify the volatile database with the following NCP commands:

NCP> SET EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET NCP> CLEAR EXECUTOR NONPRIVILEGED PASSWORD

12.4.4 Setting Privilege Requirements for Remote Object Connections

You can select specific privileges to control the use of DECnet objects that are specified during network configuration. In such instances, it becomes a privileged operation to connect to a privileged DECnet object or use an outgoing DECnet object.

For example, the following command establishes the requirement that users initiating a DECnet connection to the remote object MAIL must possess the OPER and SYSNAM privileges:

NCP> DEFINE OBJECT MAIL OUTGOING CONNECT PRIVILEGES OPER,SYSNAM

This mechanism is a useful way of limiting access to certain DECnet applications to privileged users or programs. However, in order to be effective, the privilege requirement must be imposed consistently on all nodes in the network.

12.5 Specifying Routing Initialization Passwords

Point-to-point connections are connections over synchronous and asynchronous lines. 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 network address, node name, and password of the requesting node has to match the local system's routing authorization data.

12.5.1 Establishing a Dynamic Asynchronous Connection

A dynamic asynchronous DECnet connection is a temporary connection between two nodes, normally over a telephone line through the use of modems. The line at each end of the connection can be switched from a terminal line to a dynamic asynchronous DECnet line. Configuration of dynamic asynchronous lines is performed automatically by DECnet during establishment of a dynamic connection. A dynamic asynchronous connection is normally maintained only for the duration of a telephone call.

On an OpenVMS node, you have the option of performing steps 1 and 2 of the dynamic asynchronous connection process before you turn on the network at your node (step 3). The later steps of the process (starting with step 4) must occur when the line is being switched to DECnet.

Follow the steps outlined below to establish a dynamic asynchronous DECnet connection. This procedure assumes the local OpenVMS node is originating the connection and switching the terminal line on for DECnet use. The connection must be to an OpenVMS node on which you have an account with NETMBX privilege. The steps also indicate the actions that the system manager at the remote OpenVMS node must perform in order for the dynamic asynchronous DECnet link to be established successfully.

1. Log in to the SYSTEM account and enter the following commands interactively (or include them in the SYS$MANAGER:SYSTARTUP_VMS.COM command procedure before you boot the system). These commands load the asynchronous driver NODRIVER (NOA0) and install DYNSWITCH software on your system.

   $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT NOA0/NOADAPTER SYSGEN> EXIT $ INSTALL:=$SYS$SYSTEM:INSTALL $ INSTALL/COMMAND INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE - _ /PROTECT/HEADER/OPEN INSTALL> EXIT

   
   The system manager of the remote OpenVMS node must also enter these commands.
   Additionally, the system manager at the remote OpenVMS node must enter the commands given below. These commands enable the use of virtual terminals for the terminal line that is to be switched, and set the DISCONNECT characteristic for the terminal line. (The virtual terminal capability permits the process to continue running if the physical terminal you are using becomes disconnected.)

   $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER SYSGEN> EXIT $ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP - _$ /DISCONNECT device-name:

   
   Device-name is the name of the terminal port to which the dynamic asynchronous connection is made.

2. You must establish the required transmit password at the originating end of the dynamic asynchronous dialup link. The transmit password is the password sent to the remote node during connection startup. Use NCP to enter a command to define the transmit password for the remote node. The password can contain one to eight alphanumeric characters and should not contain any spaces. Specify the following commands:

   $ RUN SYS$SYSTEM:NCP NCP> DEFINE NODE node-id TRANSMIT PASSWORD password NCP> EXIT

   
   Node-id is the name of the remote node with which your node is forming a connection.
   In the following example, the node name of your local node is LOCALA, the transmit password is PASSA, and the remote node with which you are creating a dynamic asynchronous dialup link is REMOTC:

   $ RUN SYS$SYSTEM:NCP NCP> DEFINE NODE REMOTC TRANSMIT PASSWORD PASSA NCP> EXIT

   
   For each remote node with which you will create a dynamic asynchronous DECnet dialup link, you must define a transmit password in a separate command.
   The system manager for the node at the other end of the connection must define that same password as a receive password for your node (the password expected to be received from your node). The remote system manager should also specify the parameter INBOUND ROUTER or INBOUND ENDNODE, to indicate the type of node (router or end node) that is expected to initiate the dynamic connection. These are the commands the remote manager should enter:

   $ RUN SYS$SYSTEM:NCP NCP> DEFINE NODE node-id - _ RECEIVE PASSWORD password INBOUND node-type NCP> EXIT

   
   For example, if your node LOCALA is an end node and your transmit password is PASSA, the manager at REMOTC should issue the following command:

   $ RUN SYS$SYSTEM:NCP NCP> DEFINE NODE LOCALA RECEIVE PASSWORD PASSA INBOUND ENDNODE NCP> EXIT

3. DECnet must be running on both nodes for the remaining steps. If you have not already done so, turn on the network by entering the following command (and request that the remote system manager also do so):

   $ @SYS$MANAGER:STARTNET

   
   If the network was already running before you began the dynamic asynchronous connection procedure, enter these commands to cause the permanent database entry to be entered in the volatile database:

   $ RUN SYS$SYSTEM:NCP NCP> SET NODE node-id ALL NCP> EXIT

4. The remaining steps can be performed by any OpenVMS user with NETMBX privilege. Log in to your local OpenVMS system, and enter the following DCL command on your terminal to cause your process to function as a terminal emulator (which makes the remote terminal appear to be a local terminal connection):

   SET HOST/DTE device-name:

   
   Device-name is the name of your local terminal port that is connected to the modem. If both systems use modems ) with autodial capabilities, you can optionally include the /DIAL qualifier on the SET HOST/DTE command to cause automatic dialing of the modem on the remote node, as follows:

   SET HOST/DTE/DIAL=number device-name:

5. If you are not using automatic dialing, dial in to the remote node manually.
6. Once the dialup connection is made and you receive the remote OpenVMS system welcome message, log in to your account on the remote node.
7. While logged in to your account on the remote node, enter the following command to cause the line to be switched to a DECnet line automatically:

   $ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET

   
   The following message indicates that the DECnet link is being established:

   %REM-S-END - control returned to local-nodename:: $

   
   To check whether the communications link has come up, specify the following command on the local system:

   $ RUN SYS$SYSTEM:NCP NCP> SHOW KNOWN CIRCUITS NCP> EXIT

   
   The resulting display should list a circuit identified by the mnemonic TT or TX, depending on the asynchronous device installed on the line, and indicate that it is in the ON state.
   When the DCL prompt appears on your terminal screen, you can begin to communicate with the remote node over the asynchronous DECnet connection.

8. As an alternative to switching the terminal line to a DECnet line automatically (as described in previous step 7), you can switch the line manually. If you originate a dynamic connection to an OpenVMS node from a node that is not running OpenVMS software, manual switching is required; from an OpenVMS system, it is optional. If you are originating the connection from a node that is not running OpenVMS software, follow system-specific procedures to log in to the remote OpenVMS node by means of terminal emulation.
   Once you are logged in to the remote node, two steps are required to perform manual switching:
   1. Using your account on the remote OpenVMS node, specify the SET TERMINAL command described in step 7, but add the /MANUAL qualifier:

      ---

      Previous

      Next

      Contents

      Index

      	privacy and legal statement
      6346PRO_028.HTML