Available methods for controlling access to network information
and the policies used to determine that access depend upon the
operating system(s) involved.
1 – Rights Identifiers (OpenVMS)
HP DECnet-Plus for OpenVMS uses VMS rights identifiers to
perform access checks on all manageable entities. This differs
from the Phase IV software, which used VMS privileges for access to
the permanent database and for write access. Read access to the
volatile database in Phase IV was unprotected.
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 ability to set default accounts. These 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:
UAF> GRANT/ID NET$EXAMINE Joe
! Grant user JOE read access to local network data
UAF> GRANT/ID NET$MANAGE Joe
! Grant user JOE read/write access to local network data
UAF> 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.
2 – Proxies (OpenVMS)
Proxies are managed using the AUTHORIZE facility. Here are
examples of adding proxies to grant access to remote user
SMITH on node LAMCHP to the JONES account on the local node:
UAF> ADD/PROXY DOMAIN:LAMCHP.SCH.DEC.COM::SMITH JONES
UAF> ADD/PROXY DEC:.SCH.LAMCHP::SMITH JONES
UAF> ADD/PROXY LOCAL:.LAMCHP::SMITH JONES
Each proxy record should specify a default account, regardless
of whether a default wildcard proxy exists, to ensure that at
least one valid destination account is specified. For example,
if a default wildcard proxy existed on DEC:.SCH.PRKCHP:
UAF> SHOW/PROXY *
Default proxies are flagged with (D)
DEC:.SCH.LAMCHP::*
* (D)
The SYSTEM user on node LAMCHP would have default proxy access
into the SYSTEM account on PRKCHP.
If the network manager then wished to add ALTERNATE as an
alternate account to be used from the SYSTEM account on LAMCHP,
while still retaining SYSTEM as the default, he would need to
explicitly specify that default in the new proxy record like so:
UAF> ADD/PROXY DEC:.SCH.LAMCHP::SYSTEM SYSTEM/DEFAULT, ALTERNATE
So the proxy database on PRKCHP would now look like this:
UAF> SHOW/PROXY *
Default proxies are flagged with (D)
DEC:.SCH.LAMCHP::*
* (D)
DEC:.SCH.LAMCHP::SYSTEM
SYSTEM (D) ALTERNATE
If he instead did this:
UAF> ADD/PROXY DEC:.SCH.LAMCHP::SYSTEM ALTERNATE
So the proxy database looked like this:
UAF> SHOW/PROXY *
Default proxies are flagged with (D)
DEC:.SCH.LAMCHP::*
* (D)
DEC:.SCH.LAMCHP::SYSTEM
ALTERNATE
then DEC:.SCH.LAMCHP::SYSTEM would no longer have default
access to PRKCHP's SYSTEM account. That is because only one
proxy record is considered for proxy processing; and in this
case, the exact match DEC:.SCH.LAMCHP::SYSTEM is preferred
over the DEC:.SCH.LAMCHP::* match. This
DEC:.SCH.LAMCHP::SYSTEM proxy record does not specify any
default account.
For further information on how proxies are used to grant
access, refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL
OPENVMS_POLICY.
3 – OpenVMS Policy
Access can be established using an explicitly specified
account, a default proxy account, an application-specific
default account, or a nonprivileged default account. The
following steps are used to determine if a remote user
will be granted access. (Note that access control checking
is handled in the same fashion for a local user who specifies
the local node or 0 in a command.)
1. If explicit access control information is provided, this
information is evaluated first.
When an empty access control string is provided, as in:
$ DIR PRKCHP""::
$ DIR 0""::
No proxy checking is performed. Instead, access checking
is continued at Step 3.
When both a username and password are explicitly provided,
as in the following examples:
$ DIR PRKCHP"PRKCHP_USER PASSWD"::
$ DIR 0"PRKCHP_USER PASSWD"::
$ MCR NCL SHOW NODE PRKCHP"PRKCHP_USER PASSWD" ALL
that account must be accessible using that password (even if
a valid proxy exists), in order for access to succeed. If
this fails (say, for example, the password is wrong or the
account does not exist), then no further checking is
performed and access is denied.
When only the username is explicitly provided, as in:
$ DIR PRKCHP"PRKCHP_USER"::
$ DIR 0"PRKCHP_USER"::
$ MCR NCL SHOW NODE PRKCHP"PRKCHP_USER" ALL
the local proxy database is searched for one proxy record
matching source_node::username_on_source. An exactly
matching proxy record is preferred over a wildcard match.
(Refer to HELP NETWORK_MANAGEMENT ACCESS_CONTROL PROXIES
for more information if a wildcard proxy is present.)
If a match is not found, then no further checking is
performed and access is denied.
If a match is found, the selected proxy record is examined
to determine if access should be attempted using this
explicitly specified local username. It does not
matter if this local username is specified in the proxy
record as the default account or not. As long as that
username is included somewhere in that proxy record, then
access will be attempted via that account.
For example, if the following command were issued by SYSTEM
on LAMCHP:
$ DIR PRKCHP"PRKCHP_USER"::
And PRKCHP had one of the following proxy records in its
database:
LAMCHP::SYSTEM
PRKCHP_USER
LAMCHP::SYSTEM
PRKCHP_USER (D)
LAMCHP::SYSTEM
SYSTEM (D) PRKCHP_USER
Then access would be attempted using the explicitly
specified PRKCHP_USER account.
If this access succeeds, the remote user is mapped into the
specified account and granted the rights and default
privileges for that account. If there is a problem (say,
for example, the directory for that account does not have
the correct owner), then no further checking is performed
and access is denied.
2. If no access control information was provided at all (not
even an empty string), as in:
$ DIR PRKCHP::
$ DIR 0::
$ MCR NCL SHOW NODE PRKCHP ALL
The proxy database is scanned for a proxy record matching
source_node::username_on_source. (A default wildcard proxy
may not be sufficient. Refer to HELP NETWORK_MANAGEMENT
ACCESS_CONTROL PROXIES for more information.)
If no matching proxy record is found, then access
control checking proceeds to Step 3.
If a matching proxy record is found, but it does not
specify a default account, then access will NOT be
attempted using that proxy. Instead, access checking
proceeds to Step 3.
If the matching proxy record specifies a default account,
then access is attempted using that account. If this
succeeds, the user is granted the rights and default
privileges of this default account. If this fails (say,
for example, the directory for that account does not
have the proper owner), then no further checking is done
and access is denied.
3. If an application-specific default is present, as
indicated by the session control application user name
attribute, then access will be attempted using that
account. If this access fails (say, for example, the
specified account is non-existent), then no further
checking is performed and access is denied.
If no default was specified for that particular
application, access checking is continued with Step 4.
--- NOTE ---
The CMIP Management Listener (CML) application
uses this method of access to allow remote users to
perform NCL SHOW commands. This is why the session
control application CML user name is usually set to
CML$SERVER, and this account is generally granted
the NET$EXAMINE right. Even if a remote user does
not include explicit access control information in
an NCL command, and even if he does not possess a
default proxy account with NET$EXAMINE or BYPASS,
his NCL SHOW requests will still be permitted via
the CML$SERVER account.
4. If a non privileged default has been established,
as indicated by the session control non privileged
user attribute, then access will be attempted using
that account. If this access fails, or if the
session control non privileged user attribute has
not been set, then access is denied.
4 – Tru64 UNIX Policy
On Tru64 UNIX, access control policy is as follows:
o Any user is allowed to use the show command.
o To execute any command that modifies network data, the user must
have superuser privileges.
o When commands default to the local node (either by not specifying
a node, or using Node 0), NCL communicates with the CML
application by way of pipes, and the priviledges are determined
by the user id (UID) that NCL is running under.
o When commands are issued to a remote node or to the local node by
explicitly including the node name (for example, using
node alpha on the system named alpha), then the access granted
depends on the access control provided; the session control
attributes defined for CML on the target node; and the proxy
accounts set up on the target node.
o The access control used with a command is determined as follows:
-- If any explicit access control is included on the command line,
that is what is used. The information can be provided either
after the node name (for example, node alpha/smith/abc or
through the use of a "by" clause, for example,
by user = smith, password = abc).
-- If no explicit access control is provided, then NCL checks if
any default access has been previously set, and if so, uses
that. Default access is set using the
set ncl default access by user = USER, password = PASSWORD
command. The current state of NCL's default access can be
checked with the show ncl default access command.
-- If neither of the these cases applies, no access information
is used.
o When an NCL command arrives at a target node, the access control
accompanying the command, along with the session control proxy
entries and session control application cml characteristics
determine what will be allowed. By default (as DECnet is initially
installed), all show commands are allowed, and commands that alter
network data are allowed only if the root account and password are
explicitly provided. To modify this behavior, refer to the
appropriate manual entries on session control.