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, see the HP OpenVMS System Manager's
Types of System Accounts
There are two major types of accounts:
accounts have access to system software. Usually, such
an account is considered an individual account.
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...
work of a general nature, such as program development or text editing
applications programs with confidential information
network applications like MAIL
resources on your system from a remote system (in a limited manner)
Captive or restricted
network proxy accounts
authentication systems like smart cards
accounts created as part of a layered product installation
Interactive, restricted, or captive
resources from a remote system without a password
log in to an application terminal
Captive or restricted
Log in at the
OpenVMS login prompt using their external user IDs and passwords
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 7-1 Creating a Typical Interactive User Account
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD RDOWGOOD /PASSWORD=TRALAYAM/UIC=[231,010] -
_UAF> /DEVICE-BOTANYDEV/DIRECTORY=[RDOGWOOD] -
_UAF> /OWNER="Robert Dogwood"/ACCOUNT=BOTNYDPT -
_UAF> /FLAGS=(GENPWD) /PWDMINIMUM=6 -
_UAF> /EXPIRATION=15-JUNE-2003/PWDLIFETIME=90 -
_UAF> /PRIMEDAYS=(MON,TUES,WED,THURS,FRI,SAT,NOSUN) -
identifier for value:[000231,000010] added to RIGHTSLIST.DAT
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.
“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 7-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) -_UAF>/PASSWORD=GROBWACH/UIC=[777,031] -
_UAF>/OWNER="Campus Admin"/ACCOUNT=ADMIN -_UAF>/LOCAL=(PRIMARY,8-17)/PRIMEDAYS=(MON,TUES,WED,THU, -_UAF>FRI,NOSAT,NOSUN) -_UAF>/NONETWORK/NOREMOTE/NODIALUP -_UAF>/LGICMD=GRADES /CLITABLES=GRADES_TABLES -
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
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.
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
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.
Special-Purpose Privileged Captive Accounts
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
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
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 7-2 Login Qualifiers Not Allowed by Captive Accounts
Specifies the name of
an alternate command language interpreter
Overrides the default
login command procedure
Disables execution of
the default login command procedure
Requests an alternate
Specifies the name of an alternate
Setting Up Captive Accounts
You define a captive account with AUTHORIZE by
including the following qualifier when creating the account:
Table 7-3 Qualifiers Required to Define Captive Accounts
Identifies the captive
account login command procedure and overrides the default login command
procedure (LOGIN.COM in the user's default directory).
Assigns a unique UIC
group. Use the following form of the AUTHORIZE command SHOW to verify
the uniqueness of the UIC group:
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).
Sets up the password. With a captive account, either require no password,
or lock the password so that only the security administrator can change
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.
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
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
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
Example 7-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
$ set control=(y,t)
Example 7-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)
$ 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
$ write sys$output "%CAPTIVE-W-ILLEGAL, bad characters in command line"
$ goto next_command
$ goto next_command
$ define sys$input sys$command
$ goto next_command
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
If the restricted flag is set, it is recommended
that the LOGIN.COM is not user-writable or the user cannot modify
it and bypass the login procedure. It is also expected that the LOGIN.COM
has error checking and error handling in place using the various error
controls such as the $ SET NOON or $ ON ERROR THEN LOGOUT.
NOTE: The purpose of the RESTRICTED flag is to ensure that the user
cannot bypass parts of the login procedures. It is not intended to
invoke a mechanism by which login procedures containing bugs cause
Define a restricted account with the Authorize
utility by including the following qualifier when creating the account:
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
it is appropriate to allow the user to enter the Ctrl/Y key sequence
after the command procedure starts. For example:
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
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
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,
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 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
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
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:
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:
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:
This command eliminates the possibility that the
user could break the restricted account at logout time by pressing
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.
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.