skip book previous and next navigation links
go up to top of book: HP OpenVMS Guide to System Security HP OpenVMS Guide to System Security
go to beginning of part: Security for the System Administrator Security for the System Administrator
go to beginning of chapter: Security in a Network Environment Security in a Network Environment
go to previous page: Hierarchy of Access Controls Hierarchy of Access Controls
go to next page: Using DECnet Application (Object) AccountsUsing DECnet Application (Object) Accounts
end of book navigation links

Proxy Access Control  



Using Proxy Logins defines the concept of proxy logins. You can authorize proxy access when you encounter situations where users either on different nodes or in different groups want to share files on your system and you are reluctant to give out passwords or to set the directory and file protection to W:RWE. With proxy logins, there is no need to embed passwords in commands to copy a file across the network. There is also no need to allow world read access to a file for file transfers. The user enters the following form of the DCL command COPY to a default proxy account: COPY remotenode::file-spec file-spec

To copy a file over the network using proxy access from an account other than the default, the user includes the name of the proxy account in the access control string of the DCL command, as follows: COPY remotenode"proxyacct"::file-spec file-spec

Special Security Measures with Proxy Access  

Proxy access is a selective merging of the authorization databases of the affected systems. Therefore, the security is only as good as the security of the least secure node.

Although proxy access eliminates passwords going over the network, it is possible for a personal computer to bypass the proxy login mechanism by impersonating one of the authorized nodes. For this reason, implement the following procedures:

Setting Up a Proxy Database  

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

You can control the use of proxy logins at the local node. Use AUTHORIZE to create and modify the permanent proxy database.

The default network proxy authorization file is NET$PROXY.DAT. However, AUTHORIZE maintains the file NETPROXY.DAT for compatibility, for support of many layered products, and for translation of DECnet for OpenVMS (Phase IV) node names.

Each network proxy entry can map a single remote user to multiple proxy user names on the local node (one default proxy user name and up to fifteen additional proxy user names). 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. The proxy database entry identifies the user in the form of nodename::username or nodename::[group,member].

For example, to create a proxy 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
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. AUTHORIZE Commands for Managing Network Proxy Access summarizes AUTHORIZE commands used to manage the proxy database.

Table 1   AUTHORIZE Commands for Managing Network Proxy Access
Command Argument Description
ADD/PROXY
node::remoteuser localuser[,...]
Adds proxy access for the specified user.
CREATE/PROXY

Creates a network proxy authorization file.
LIST/PROXY

Creates a listing file of all proxy accounts and all remote users with proxy access to the accounts.
MODIFY/PROXY
node::remoteuser
Modifies proxy access for the specified user.
REMOVE/PROXY

Deletes proxy access for the specified user.
SHOW/PROXY
* node::remoteuser
Displays proxy access allowed for the specified user.

Enabling and Disabling Incoming Proxy Access  

You can control proxy access to your node and to particular applications.

Controlling Proxy Access to a Node

To accept proxy connections to your node, set the incoming proxy attribute in the executor database in the following way:

NCP>SET EXECUTOR INCOMING PROXY ENABLE
To deny proxy connections to your node, set the outgoing proxy attribute in the following way:
NCP>SET EXECUTOR INCOMING PROXY DISABLE
If proxy access to the node is disabled, the system ignores any proxy connection request.

A comparable set of steps is necessary on the originating node so that proxy data is transmitted in the connect request message. Set proxy attributes for both the node and for all applications that expect to use proxy, for example:

NCP>SET EXECUTOR OUTGOING PROXY ENABLE
NCP>SET OBJECT MAIL PROXY BOTH
NCP>SET OBJECT MAIL PROXY INCOMING
NCP>SET OBJECT MAIL PROXY OUTGOING
In general, enabling outgoing proxy is a good idea, even if the target node does not enable proxy for the object, because enabling outgoing proxy puts the originating user name in the connect message. Thus the user name is available for accounting and audit logs on the target node. Be aware that a small number of DECnet applications depend on the nonproxy form of the connect message (for example, some use the connect message space for application information rather than user names) and do not function if outgoing proxy is enabled.

Controlling Proxy Access to an Application

To allow proxy access to a particular application, you must enable the proxy access for both the node and the application. In addition, specify the name of the application in the SET OBJECT command. For example, the following enables proxy access to the application NML:

NCP>SET EXECUTOR INCOMING PROXY ENABLE
NCP>SET OBJECT NML INCOMING PROXY ENABLE
To disable proxy access to an application, identify the application in the SET OBJECT command, and set the incoming proxy attribute to disable. For example, the following disables proxy access to the application FAL:
NCP>SET OBJECT FAL INCOMING PROXY DISABLE
If incoming proxy is enabled for the application but the proxy access for the node is disabled, the system in effect ignores any proxy access request to the application.

Removing Proxy Access  

Remove proxy access to the system when it is no longer needed. Invoke AUTHORIZE, and enter the following command to remove proxy access:

UAF> REMOVE/PROXY BOSTON::MARTIN

Procedure for Creating a Proxy Account  

When you want to set up a proxy account on your node for use by one or more users at other nodes, you must perform the following steps. Refer to the security guidelines listed in Special Security Measures with Proxy Access as you create the account.

  1. Define the purpose of the account, its name, and which network users will be admitted.
  2. Create the local account, if necessary, with AUTHORIZE; if the account already exists, make sure it is restricted and defined as /NOINTERACTIVE, /NOBATCH, /NETWORK.
  3. Review the privileges on the account. Generally avoid granting privileges to proxy login accounts.
  4. Create the network proxy authorization file, if necessary, with the AUTHORIZE command CREATE/PROXY. (The system usually creates it automatically.)
  5. Allow as many remote users as necessary access to the proxy account with the AUTHORIZE command ADD/PROXY.
  6. Check the default protection on the directory, and customize it as necessary.
  7. Examine any login command procedure specified by the /LGICMD qualifier to the ADD command. In captive accounts, make certain that the login command procedure follows the recommendations in Guidelines for Captive Command Procedures. It should reside in a well-protected directory owned by a user other than the owner of the proxy account. It should prohibit write access for those who use the account.
  8. Notify the security administrator at the remote node about which users from that node have been authorized for access to your node.

Example of a Proxy Account  

In Sample Proxy Account, 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 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
lower/ vellip
$ DIRECTORY/SECURITY SYS$STAFF:[GENACCESS]LOGIN.COM
lower/ vellip



go to previous page: Hierarchy of Access Controls Hierarchy of Access Controls
go to next page: Using DECnet Application (Object) AccountsUsing DECnet Application (Object) Accounts