HP OpenVMS System Manager's Manual, Volume 1:... |
Managing User Accounts |
|
|
| |
| Task | Section |
|---|---|
|
Setting up
an automatic login account with SYSMAN
|
Setting Up an Automatic Login Account with SYSMAN
|
|
Setting up
a project account with ACL identifiers
|
Setting Up a Project Account with ACL Identifiers
|
|
Creating network
proxy authorization files
|
Creating Network Proxy Authorization Files
|
|
Adding proxy
accounts
|
Adding Proxy Accounts
|
|
Removing proxy
accounts
|
Removing Proxy Accounts
|
|
Displaying
proxy accounts
|
Displaying Proxy Accounts
|
|
Controlling proxy logins
|
Controlling Proxy Logins
|
Understanding Network Proxy Accounts explains what network proxy accounts are.
Setting Up an Automatic Login Account with
SYSMAN ![]()
The System Management
utility (SYSMAN) includes the functions of the automatic login facility
(ALF). Using SYSMAN ALF commands, you can set up a terminal that
automatically logs in a user to a certain user name. For example,
a terminal might be set up for the account INVENTORY, which automatically
logs in a user to a captive account when the user presses the Return
key.
First, you must follow the steps described in the previous sections to create the top-level default directory and to add the account. Then you can associate the account with a particular terminal or port using the following format:ALF ADD device user [/TERMINAL] [/PORT] [/PROXY] [/LOG]
where:
|
device
|
is the terminal or port
name that you want to assign to a user name. Note that device must
be a terminal name if you do not specify qualifiers on the command
line.
|
|
user
|
is the account user name
that you want to assign to a particular terminal or port.
|
|
/TERMINAL
|
causes SYSMAN to treat device as
a terminal name. This is the default behavior.
|
|
/PORT
|
causes SYSMAN to treat device as
a port name. If the port name contains a special character such
as a slash ( / ) or if it contains lowercase letters that you want
to preserve, you must enclose the port name within quotation marks.
Be aware that anything within quotation marks is written literally
to the ALF database file. For example, if the actual port name contains
uppercase letters as well as special characters, be sure to specify
uppercase letters within the quotation marks. Otherwise, a mismatch
will occur between the actual port name and what is specified in
the SYSALF.DAT file.
|
|
/PROXY
|
causes SYSMAN to check that device is
in the NODE::USERNAME format, which can be up to 63 characters in
length.
|
|
/LOG
|
causes SYSMAN to display a message that
the device and user have
been added to the ALF database.
|
To protect automatic login accounts, set the AUTOLOGIN flag in the account's UAF record. This flag makes the account available only by autologin, batch, and network proxy.
The following example shows how to invoke SYSMAN and assign terminal TTA0 to the INVENTORY25 account:
When you create ALF records for proxy accounts, the device parameter can be as long as 63 characters. For example:$RUN SYS$SYSTEM:SYSMANSYSMAN>ALF ADD TTA0 INVENTORY25
In this command, VMS:.ZKO.VMSORG.SYSMAN.CLIENT1::SYSTEM is the value of the device parameter.SYSMAN>ALF ADD VMS:.ZKO.VMSORG.SYSMAN.CLIENT1::SYSTEM FOOBAR
For more information about autologin accounts and the SYSMAN ALF commands, see the HP OpenVMS System Management Utilities Reference Manual and the HP OpenVMS Guide to System Security .
Setting Up a Project Account with ACL Identifiers ![]()
This section describes how to set up a project account that
uses access control lists (ACLs) to control access to files shared
by members of a project group. See the HP OpenVMS Guide to System Security for complete details
on setting up accounts with ACLs.
You must first add an identifier to the rights database for the project account. Use the AUTHORIZE command ADD/IDENTIFIER to add identifiers to the rights database and then associate users as holders of existing ACL identifiers with the AUTHORIZE command GRANT/IDENTIFIER. All users who hold the project's identifier can use the disk space of the project account.
You can set up the project account so that disk space is charged to the project, rather than to individual users, by assigning the resource attribute to the project identifier.
The following example summarizes the steps for setting up a project account:
$RUN SYS$SYSTEM:AUTHORIZEUAF>ADD/IDENTIFIER KITE_FLYING/ATTRIBUTES=RESOURCE{message}UAF>GRANT/IDENTIFIER KITE_FLYING GEORGE/ATTRIBUTES=RESOURCE{message}UAF>GRANT/IDENTIFIER KITE_FLYING LINDORF/ATTRIBUTES=RESOURCE{message}UAF>EXIT
$RUN SYS$SYSTEM:SYSMANSYSMAN>DISKQUOTA ADD KITE_FLYING/PERMQUOTA=2000/OVERDRAFT=200SYSMAN>EXIT
$CREATE/DIRECTORY [KITE_FLYING]/OWNER=[KITE_FLYING]
$SET SECURITY [000000]KITE_FLYING.DIR;1 -_$/ACL=((DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) -_$(IDENTIFIER=KITE_FLYING, ACCESS=READ+WRITE+EXECUTE), -_$(IDENTIFIER=KITE_FLYING,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE))
Access must be granted through ACL entries, because the owner identifier of the directory and the files (KITE_FLYING) does not match the UIC of any of the project members; thus, only world access is available through the UIC-based protection mask. The first ACE of the specified ACL gives all project members read, write, and execute access to the directory; the second ACE gives them read, write, and execute access for all files created in the directory.
Note that project members are not allowed to delete (or control) files created by others. However, the members each have complete access to files that they have created in the directory, because the file system supplies an additional default ACL entry that grants to the creator control access plus the access specified in the OWNER field of the UIC-based protection mask. This ACE appears only when the owner of the created file does not match the UIC of the creator.
Thus, when LINDORF creates the file [KITE_FLYING]THURSDAY.TXT, the file receives the following access control list by default:
(IDENTIFIER=LINDORF,OPTIONS=NOPROPAGATE, ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=KITE_FLYING,ACCESS=READ+WRITE+EXECUTE)You can use the Creator ACE command in the ACL editor to add an extra ACE to the ACL for a file created within the directory to which you assign the Creator ACE. The Creator ACE applies only when the following conditions exist:
See the HP OpenVMS System Management Utilities Reference Manual and the HP OpenVMS Guide to System Security for more information about the Creator ACE.
Understanding Network Proxy Accounts ![]()
A network
proxy account allows users on a remote node in a network
to access data by way of a local account on your system. Proxy accounts
are useful when you want to grant one or more users on a remote node
access to specific files, but you do not want to give them a private
account on your system. Very often, system managers set up proxy
accounts as restricted. You establish and control proxy accounts
with the Authorize utility (AUTHORIZE).
With proxy accounts, you can authorize one or more users on a remote node to enter DCL commands that access data from a particular account on your system. Proxy accounts allow remote users to access specific local data (for example, type and print files) without having to log in to your system or use an access control string. Remote users assume the same file access rights as the local account and also receive the default privileges of the local account. The following sections explain the procedures for setting up proxy accounts.
For more information about proxy accounts, see the HP OpenVMS Guide to System Security.
Creating Network Proxy Authorization Files ![]()
| his section contains information for network proxies on DECnet Phase IV and DECnet-Plus. For information about proxies and user authentication when using TCP/IP Services, see HP TCP/IP Services for OpenVMS Management. |
On OpenVMS systems, the following information is stored in two proxy authorization files, NETPROXY.DAT and NET$PROXY.DAT:
| NET$PROXY.DAT contains proxy information stored using DECnet-Plus full names. |
| NETPROXY.DAT contains proxy information stored using DECnet-Plus node synonyms. |
| Deleting either NETPROXY.DAT or NET$PROXY.DAT will result in incorrect functioning of proxy access on systems running DECnet for OpenVMS Phase IV. Also, many applications such as ALL-IN-1 rely on NETPROXY.DAT. |
The SYSUAF.DAT file, on your local system, must associate proxy accounts with user accounts. You will probably want to create a "standard access" account in the UAF for proxy accounts. For example, you could create an account named REMOTE_MKT with limited privileges, which allows access to certain data files on your local system.
Suppose you have a group of users on your local system who prepare marketing reports and who rely on input from users on other systems. You would assign the REMOTE_MKT account in SYSUAF.DAT the same group number and default privileges you assign to the local marketing group. In this way, the remote contributors could access any data files that are "owned" by users in your marketing group and that are not protected from group access.
Use the AUTHORIZE command CREATE/PROXY to create and initialize network proxy authorization files:
UAF>CREATE/PROXY
Adding Proxy Accounts ![]()
Create a proxy account by adding entries to the network proxy
authorization file; these entries equate one or more users on a
remote node to users on your home node.
The command syntax for adding a proxy account is as follows:ADD/PROXY node::remote-user local-user/DEFAULT [,...]
You can allow remote users access to up to 16 total local accounts: 1 default proxy account and 15 alternate proxy accounts. Use the /DEFAULT qualifier to specify the default proxy account.
Assume that you have created three accounts named REMOTE_MKT, PROXY2, and PROXY3 on your home node. The entry in this example permits the user WALTER on remote node HAL to access data by way of the REMOTE_MKT account on your home node. WALTER can access any data from his node that REMOTE_MKT can access locally. To access data through either PROXY2 or PROXY3, WALTER must specify the desired proxy account in the access control string of the DCL command used to perform network file operations.UAF>ADD/PROXY HAL::WALTER REMOTE_MKT/DEFAULT,PROXY2,PROXY3
| Because the remote user receives the same privileges as the local user, do not set up proxy accounts associated with local accounts that have special privilege. Granting remote users such access powers poses a threat to the security of your system. |
UAF>ADD/PROXY RSTS32::[360,54] GENERIC/DEFAULT
This command authorizes any user on the remote node HAL to access any account with the same user name on your system.UAF>ADD/PROXY HAL::* */DEFAULT
UAF>ADD/PROXY HAL::BARBARA */DEFAULT
This example adds proxy access from RUBY::DELAPORT to the local accounts DELAPORT (the default) and SYSTEM.UAF>ADD/PROXY RUBY::DELAPORT DELAPORT/DEFAULT,SYSTEM%UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to DELAPORT added%UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to SYSTEM added
Removing Proxy Accounts ![]()
To remove proxy accounts, use the AUTHORIZE command REMOVE/PROXY;
for example:
This command removes proxy access from RUBY::DELAPORT to the local SYSTEM account.UAF>REMOVE/PROXY RUBY::DELAPORT SYSTEM
Displaying Proxy Accounts ![]()
To display proxy accounts, use the AUTHORIZE command SHOW/PROXY.
This command displays only the first 255 characters of the node
name, although the command can handle a maximum of 1024 characters.
The following examples assume that proxy access from RUBY::DELAPORT to the local account DELAPORT has been added to the network proxy authorization file as the default. (The second example shows the DECnet-Plus equivalent of RUBY::DELAPORT.)
UAF>SHOW/PROXY *::*
RUBY::DELAPORT
DELAPORT (D)(D) indicates that DELAPORT is the default proxy.UAF>SHOW/PROXY *::*
OMNI:.US.RUBY::DELAPORT
DELAPORT (D)(D) indicates that DELAPORT is the default proxy. UAF>SHOW/PROXY/OLD *::*
Controlling Proxy Logins ![]()
Whenever a proxy login request occurs, the system verifies
that proxy access on the participating nodes is enabled. (By default,
both incoming and outgoing proxy access is enabled for each node.)
On systems running DECnet for OpenVMS, you can change proxy access or disable it totally by using the Network Control Program (NCP). The DECnet for OpenVMS Networking Manual describes how to use NCP to control proxy access.
On systems running DECnet-Plus software, you can change proxy access by using the Network Control Language utility (NCL). The manual describes how to use NCL.
| For information about proxies and user authentication when using TCP/IP Services, see the HP TCP/IP Services for OpenVMS Management. |
|
|