The type of system access a user holds largely depends on
his or her need for system resources and your site's security requirements.
This section describes the types of user accounts that are available
on OpenVMS systems and explains why one type of account may be preferable
to another. For a step-by-step description of adding user accounts,
refer to the HP OpenVMS System Manager's Manual
.
Types of System Accounts There are two major types of accounts:
Interactive accounts have
access to system software. Usually, such an account is considered
an individual account.
Limited-access accounts provide
controlled login to the system and, in some cases, controlled access
to user software. Limited-access accounts ensure that the system
and process login command procedures, as well as any command procedures
they call, are executed. There are two types of limited accounts: captive and restricted.
Guest, proxy, and automatic login accounts are forms of captive
and restricted accounts. DECwindows software does not currently support captive or
restricted logins in the traditional sense. Once a user is logged
in and creates a DECterm window, however, the traditional environment
of a captive or restricted account applies.
Both interactive and limited-access accounts can be privileged
accounts, and can be externally authenticated, as
Privileged Accounts describes.
The following table shows the kind of account to create based
on the task a user performs:
If Users Need to...
Create This Type of Account...
Perform work
of a general nature, such as program development or text editing
Run applications
programs with confidential information
Captive
Use network
applications like MAIL
Restricted
Access resources
on your system from a remote system (in a limited manner)
Captive or restricted
Use network
proxy accounts
Restricted
Use authentication
systems like smart cards
Restricted
Use accounts
created as part of a layered product installation
Restricted
Perform privileged
operations
Interactive, restricted,
or captive
Access resources
from a remote system without a password
Captive
Automatically
log in to an application terminal
Captive or restricted
Log in at the OpenVMS login
prompt using their external user IDs and passwords
Externally authenticated
You may develop one or more templates that work for many of
your users. However, do not oversimplify the process of account
creation to the point that you simply apply a template. The danger
in relying solely on templates is that you might overlook special
considerations that apply to individual users, thereby forfeiting important
controls that only you can exercise.
Examine templates regularly to be sure they are valid and
reflect the way you want your operations to proceed. Templates become
obsolete rapidly.
Interactive Account Example Creating a Typical Interactive User Account shows
how to create an interactive user account with moderate restrictions,
typical of an account at a commercial site where security is a concern
and the average user has limited access.
Example 1 Creating a Typical
Interactive User Account
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD RDOWGOOD /PASSWORD=TRALAYAM/UIC=[231,010] -[1]
_UAF> /DEVICE-BOTANYDEV/DIRECTORY=[RDOGWOOD] -
_UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT -
_UAF> /FLAGS=(GENPWD) /PWDMINIMUM=6 -[2]
_UAF> /EXPIRATION=15-JUNE-2003/PWDLIFETIME=90 -[3]
_UAF> /PRIMEDAYS=(MON,TUES,WED,THURS,FRI,SAT,NOSUN) -[4]
_UAF> /NOACCESS=(PRIMARY,23-6,SECONDARY)/NODIALUP[5]
identifier for value:[000231,000010] added to RIGHTSLIST.DAT
UAF>
Notice the following:
Only one password is required.
The password has a minimum length of 6 characters.
The user is allowed access during the week and on
Saturdays.
During those six days, the user has access during
a 15-hour period.
Limited-Account Example Creating a Limited-Access Account shows
how to create an applications production account where the user
is highly restricted. This account is designed to perform two functions:
list the grades at State University, and produce mailings to each student's
home.
In the example, any value not specified defaults to the value
provided by the default record in SYSUAF.DAT.
Example 2 Creating a Limited-Access Account
$SET DEFAULT SYS$SYSTEM$RUN AUTHORIZEUAF>ADD REPGRADES /DEVICE=ADMINDEV/DIRECTORY=[REPGRADES] -_UAF> /FLAGS=(CAPTIVE,DISWELCOME,DISNEWMAIL,DISMAIL,DEFCLI) -[1]_UAF> /PASSWORD=GROBWACH/UIC=[777,031] -[2]
_UAF> /OWNER="Campus Admin"/ACCOUNT=ADMIN -_UAF> /LOCAL=(PRIMARY,8-17)/PRIMEDAYS=(MON,TUES,WED,THU, -[3]_UAF> FRI,NOSAT,NOSUN) -_UAF> /NONETWORK/NOREMOTE/NODIALUP -[4]
_UAF> /LGICMD=GRADES /CLITABLES=GRADES_TABLES -[5]
UAF>
user record successfully addedidentifier for value:[000777,000031] added to RIGHTSLIST.DAT
Notice the following:
Account users do not see the normal
system welcome message. The account may not receive mail. It is restricted
to running under control of its login command procedure and the
default command interpreter (DCL).
The user who initiates the login must specify the
password, GROBWACH. (Most likely only the security administrator
will change the password.)
When the job is run through a local login, it is
restricted to the hours of 8 a.m. through 5:59 p.m., Monday through
Friday. (Notice that only batch and local logins are allowed, and
batch mode does not have time restrictions.)
The job may not be run over dialup lines or as a
remote job. The account also denies network access.
The process runs under the control of a special
login command procedure (GRADES.COM), which presumably provides
the operator with a menu of functions.
The process is restricted to the commands defined
in the CLI table GRADES_TABLES.
Privileged Accounts Privileges determine the functions users are authorized to
perform on the system. Any account with privileges beyond TMPMBX
and NETMBX is considered privileged. Such an account can be interactive, restricted,
or captive.
Because abuse of privileged accounts can result in serious
losses, consider imposing special controls on accounts with the
most powerful privileges as follows:
Limit access to the account. For example,
you can prohibit dialup or network access with the /NODIALUP or
/NONETWORK qualifier to discourage outsiders from attempting break-ins
from remote locations.
Impose security alarms to detect use of the privileges
pertaining to file protection: BYPASS, SYSPRV, READALL, and GRPPRV.
For information about setting up and monitoring security alarms,
see
Security Auditing.
For all but the SYSTEM account, also add the following restrictions:
Use the /PRIMEDAYS and /NOACCESS qualifiers
to restrict the time of day or days of the week that logins can
be performed. Select periods of time that can be monitored for appropriate
use.
Disable the account when not in use with the AUTHORIZE
qualifier /FLAGS=DISUSER.
Use a captive login command procedure for additional
validation. Captive login command procedures are described in
Captive Accounts.
Naturally, you need to set controls on the SYSTEM account.
The most secure practice is to disable it for all but batch access
and perform system management through individual privileged user
accounts, which provide accountability.
Because the safety of a captive account depends on the integrity
of its command procedures, it is unadvisable to set up privileged
captive accounts for untrusted users. However, there are some situations
that require privilege, and it is safer to perform specific sensitive
functions through captive privileged accounts than through general
purpose privileged accounts. For example, users who perform backup
operations require the READALL privilege. By making the account
that performs backups captive, you can ensure that the procedures
are carried out according to your system's backup policy.
See
Captive Accounts for guidelines for setting up captive accounts.
Interactive Accounts Interactive accounts are very common in environments with
low to moderate security requirements. They are well suited to work
of a general nature, such as program development or text editing.
The HP OpenVMS System Manager's Manual
explains
the procedure for setting up this type of account.
Interactive Account Example provides an example.
Captive Accounts A captive account limits the activities of the user and, when
properly administered, denies the user access to the DCL command
level. You can set up the account to limit the user to running under
the complete control of a specific program or the captive login
command procedure.
The primary feature of the captive account is its login command
procedure. This type of account ensures that the system login command
procedure (SYLOGIN.COM) and the process login command procedure
(specified by the /LGICMD qualifier in SYSUAF.DAT), as well as any
command procedures they call, are executed. A user cannot specify
any of the qualifiers shown in
Login Qualifiers Not Allowed by Captive Accounts to modify the captive command procedures when logging in.
Once logged in to a captive account, a user cannot escape
to the DCL command level through the Ctrl/Y sequence, the SPAWN
command, or the INQUIRE command. Because the DISCTLY flag in the
UAF record is turned on, any use of Ctrl/Y fails. If unhandled errors
or attempted interrupts occur, a system error message is generated,
and the session is logged out. Unless the SPAWN command carries
the /TRUSTED qualifier, it is ineffective within a captive account.
SPAWN is also disabled from MAIL and the DEC Text Processing Utility (DECTPU)
(as a built-in procedure). The INQUIRE command is also disabled
to prevent the possible execution of user-specified lexical functions.
Table 2 Login Qualifiers Not Allowed by Captive Accounts
Qualifier
Description
/CLI
Specifies the name of an
alternate command language interpreter
/COMMAND
Overrides the default login
command procedure
/NOCOMMAND
Disables execution of the
default login command procedure
/DISK
Requests an alternate default
disk
/TABLES
Specifies the name of an alternate CLI
table
Setting Up Captive Accounts You define a captive account with AUTHORIZE by including the
following qualifier when creating the account: /FLAGS=(CAPTIVE)
Table 3 Qualifiers Required to Define Captive Accounts
Qualifier
Action
/LGICMD
Identifies the captive account
login command procedure and overrides the default login command
procedure (LOGIN.COM in the user's default directory).
/UIC
Assigns a unique UIC group.
Use the following form of the AUTHORIZE command SHOW to verify the
uniqueness of the UIC group: SHOW [groupuic,*]By
keeping the account in a separate group, you can ensure that the
captive account users can access only world-accessible files and
files owned by the captive account. It ensures that the account
is not a member of the system group (that is, has a group value
less than or equal to 108, unless modified by
the system parameter MAXSYSGROUP).
/NOPASSWORD
or /FLAGS=LOCKPWD
Sets up the password. With
a captive account, either require no password, or lock the password
so that only the security administrator can change it.
Locked
passwords are generally preferable to open captive accounts (those with
no password). If you assign a locked password, give that password
to all users of the captive account.
/PRCLM
Sets the subprocess limit to 0, thus
preventing the user from spawning out of the account. (Verify that
the system parameter PQL_MPRCLM---the minimum subprocess limit---is
set to 0.)
In addition to the required settings, you may want to specify
additional characteristics for the account:
You may want to disable the welcome
announcement and electronic mail for the captive account. This is done
by setting the DISWELCOME, DISMAIL, and DISNEWMAIL login flags.
You may want to allow only interactive use of the
account from a local terminal. Include the qualifiers /NODIALUP,
/NOREMOTE, /NOBATCH, and /NONETWORK when establishing the account.
Your application may have special requirements.
You may need to impose additional AUTHORIZE qualifiers on the account,
such as /NODIALUP, to restrict modes of operation. Consider imposing restrictions
for the periods of the day and days of the week when the process
can run.
You can define a special set of DCL tables by using
the /CLITABLES qualifier, or you can emulate DCL through the use
of a DCL command procedure. It is more efficient to define DCL tables
than to resort to a DCL command procedure to emulate DCL. See the
description of the Command Definition utility (CDU) in the HP
OpenVMS System Management Utilities Reference Manual: A-L
for
help when defining the DCL tables. Be aware that the DCL tables
defined by the /CLITABLES qualifier are not used in network jobs,
such as those using the TASK object.
You can grant privileges, although you rarely need
to grant any privilege other than TMPMBX to a captive account.
You can limit the disk quota for the captive account
to the amount needed.
Guidelines for Captive Command Procedures When writing captive command procedures for your site, be
sure to observe the following guidelines:
Use the DCL command READ/PROMPT in
command procedures. For example, to request the user to enter the
date, enter the following command in the command procedure:
READ/PROMPT="Enter date: " SYS$COMMAND DATE
Avoid use of the INQUIRE command in a captive command
procedure. It produces an error that, if unhandled by a previous
ON declaration, results in deletion of the process.
When user input is required, never execute it directly.
First compare it to what is expected, and screen for illegal characters
such as apostrophe ('), at sign (@), dollar sign ($), quotation
mark ("), ampersand (&), or hyphen (-).
Avoid any use of the construction "x, where x contains
a string entered by the user. Never permit a restricted command
procedure to attempt an evaluation of a symbol that the user enters.
Use of lexical functions could break the command procedure.
Avoid executing a line in a captive command procedure
that contains the characters @TT:.
Put Audit ACEs on the captive command procedure
and its home directory to detect any modification of the file. See
Attaching a Security-Auditing ACE for more information
on Audit ACEs.
If the captive account user is allowed to create
or perform other operations on files, make certain that write access
to the login command procedure and its directory is denied. (The
user does need execute access.) If the function of the command procedure requires text preparation,
you may need to give users access to a text editor. Use caution,
however. Editors such as TECO or DECTPU can be dangerous because
users can manipulate files and exit from the editor to the DCL interface.
When designing this environment, remember that most text editors
are capable of reading and writing files (within the access rights
of the account). Provide an editor that gives users the tools they
require but does not allow them to escape from the captive environment.
Example 3 Sample Captive Procedure for Privileged Accounts
$ if f$mode() .nes. "INTERACTIVE" then $logout
$ term = f$logical("SYS$COMMAND")
$ if f$locate("_T", term) .eq. 0 then $goto allow
$ if f$locate("_OP",term) .ne. 0 then $logout
$allow:
$ set control=(y,t)
Example 4 Sample Captive Command Procedure for Unprivileged
Accounts
$ deassign sys$input
$ previous_sysinput == f$logical("SYS$INPUT")
$ on error then goto next_command
$ on control_y then goto next_command
$ set control=(y,t)
$
$next_command:
$ on error then goto next_command
$ on control_y then goto next_command
$
$ if previous_sysinput .nes. f$logical("SYS$INPUT") then deassign sys$input
$ read/end=next_command/prompt="$ " sys$command command
$ command == f$edit(command,"UPCASE,TRIM,COMPRESS")
$ if f$length(command) .eq. 0 then goto next_command
$
$ delete = "delete"$ delete/symbol/local/all
$ if f$locate("@",command) .ne. f$length(command) then goto illegal_command
$ if f$locate("=",command) .ne. f$length(command) then goto illegal_command
$ if f$locate("F$",command) .ne. f$length(command) then goto illegal_command
$ verb = f$element(0," ",command)
$
$ if verb .eqs. "LOGOUT" then goto do_logout
$ if verb .eqs. "HELP" then goto do_help
$
$ write sys$output "%CAPTIVE-W-IVVERB, unrecognized command \",verb,"\"
$ goto next_command
$
$illegal_command:
$ write sys$output "%CAPTIVE-W-ILLEGAL, bad characters in command line"
$ goto next_command
$
$do_logout:
$ logout
$ goto next_command
$
$do_help:
$ define sys$input sys$command
$ help
$ goto next_command
Restricted Accounts Certain limited-access accounts require a less restrictive
environment than captive accounts. Accounts under which network
objects run, for example, require temporary access to DCL. Such
accounts must be set up as restricted accounts, not captive accounts.
Restricted accounts are indistinguishable from regular accounts once
the login sequence finishes. The purpose behind restricted accounts
is to ensure a trusted login wherein SYLOGIN, LOGIN, and their descendants
execute completely.
Define a restricted account with the Authorize utility by
including the following qualifier when creating the account: /FLAGS=(RESTRICTED)
This flag ensures that the account is noted as restricted.
A restricted account provides the same features as those listed
for a captive account in
Captive Accounts except that restricted accounts allow the user
access to the DCL command level following the execution of the system
and process login command procedures.
Sometimes it is appropriate
to allow the user to enter the Ctrl/Y key sequence after the command
procedure starts. For example:
You may want to provide users with
a Ctrl/Y feature at points during the execution of the restricted
login command procedure. Include ON CONTROL_Y commands in the procedure
where you want to test for the Ctrl/Y features, as shown in
Sample Captive Command Procedure for Unprivileged Accounts.
You may have a restricted command procedure that
ultimately turns control over to the user. For example, consider
a SYLOGIN.COM command procedure that performs additional security
validation; its execution should be guaranteed to ensure its effectiveness.
However, once SYLOGIN.COM has done its job, control can be passed
to the user. To do this, mark the account as restricted, and enter
the DCL command SET CONTROL=Y when you are ready to release control
to the user.
Automatic Login Accounts To force individuals at specific terminals to log in to an
application program, create a separate captive account for the application.
Then set up automatic logins to the new account for the desired
users using the System Management utility (SYSMAN).
Once you set up a terminal for automatic login, it can be
used only for the designated account. This is most useful for applications
terminals used by people who may be unfamiliar with computers.
The automatic login feature suppresses the user name prompt.
All other login features (system password, primary and secondary
passwords, and messages) function normally, if enabled.
Passwords are optional. If you want the account to be open
to all users where the terminals are located, eliminate the password.
When no password is required, the user has no data to enter at login.
The operating system logs the terminal in automatically in response
to the Break key or the Return key and immediately enters the application
if the account is under the control of a captive login command procedure.
The automatic login file (ALF) lists the terminals and the
users who are authorized to access the application account. However,
automatic login accounts are potentially accessible from terminals
and sources other than the terminals listed in the ALF file and,
therefore, require protection, especially if they have no password. Use
the following precautions:
Restrict network and dialup access,
as appropriate, with the AUTHORIZE qualifiers /NODIALUP, /NONETWORK,
and /NOREMOTE.
Set the AUTOLOGIN flag in the account's UAF record.
This flag makes the account available
only by autologin, batch, and network proxy.
Guest
Accounts Guest accounts are forms of captive or restricted accounts
that allow multiple remote users access to resources on your system
through a common account. For example, users across the network
may need access to your system to report problems or to read corporate
memos.
HP does not recommend the practice of setting up guest accounts.
Guest accounts, however unprivileged, offer malicious users a chance
to compromise your system security. Most needs for a guest account
can be handled by special proxy login accounts, which should also
be limited-access accounts.
If you still need a guest account, take the following steps
to make the account secure:
Use an obscure password for the guest
account. Change the password frequently. Never use easily guessed
account name and password combinations such as GUEST/GUEST or USER/USER.
Maintain a list of people allowed to use the account.
(Changing the password regularly helps you keep this list current.)
Set up the guest account in a separate UIC group.
Make sure that the account is not a member of the system group.
Place the default login command procedure in the
directory SYS$MANAGER by using the AUTHORIZE command MODIFY, as
follows: MODIFY guest-account/LGICMD=SYS$MANAGER:filename.COM
Make the guest account restricted or captive by
setting the AUTHORIZE qualifiers /FLAGS=RESTRICTED or /FLAGS=CAPTIVE,
respectively.
If the guest account is set up as a restricted account,
limit the number of subprocesses that the account can create to
0 using the AUTHORIZE qualifier /PRCLM=0. (Ensure that the system
parameter PQL_MPRCLM is also set to 0.)
Assign the guest account only TMPMBX privilege.
To handle error conditions, include the following
commands in the default login command procedure:
SET ON
SET NOCONTROLY
ON ERROR THEN LOGOUT/BRIEF
If the system has LOGOUT defined as a global symbol
and points to a command procedure (enter the DCL command SHOW SYMBOL
LOGOUT to confirm this), include the following DCL command in the default
login command procedure for the account:
DELETE/SYMBOL LOGOUT/GLOBAL
This command eliminates the possibility that the user could
break the restricted account at logout time by pressing Ctrl/Y.
To prevent outsiders from misusing your system resources
through the submission of batch jobs under the guest account, include
the AUTHORIZE qualifier /NOBATCH when you create the account.
Limit the disk quota for the guest account UIC to
the amount needed.
Do not allow the DCL command INQUIRE to appear in
any of the command procedures.
Proxy
Accounts Generally, proxy login accounts should be set up as restricted
accounts. Proxy login accounts permit remote users to access a local
account without specifying a password.
Example of a Proxy Account describes proxy login accounts. Note that many
recommendations are the same as those for restricted accounts.
Externally Authenticated Accounts Externally authenticated accounts are those that are marked
with the EXTAUTH flag in the user's SYSUAF record. This enables
these users to log in at the OpenVMS login prompt using their external
user IDs and passwords. See
Enabling External Authentication for more information on external authentication.
HP OpenVMS Guide to System Security
Security for the System Administrator
