HP OpenVMS System Manager's Manual, Volume 1:... |
Managing User Accounts |
|
|
| |
Restricting the Use of Accounts
The following sections describe how to perform these tasks:
| Task | Section |
|---|---|
|
Setting day
types
|
Setting Day Types
|
|
Restricting
logins to specific times
|
Restricting Logins to Specific Times
|
|
Restricting
CPU time
|
Restricting CPU Time
|
|
Restricting
login functions
|
Restricting Login Functions
|
|
Using login
command procedures for restricted or captive accounts
|
Using Login Command Procedures for Restricted or Captive Accounts
|
|
Setting priorities for user
processes
|
Setting Priorities for User Processes
|
For a detailed description of the qualifiers used to restrict the use of accounts, see the Authorize utility section in the HP OpenVMS System Management Utilities Reference Manual.
Setting Day Types ![]()
You can restrict the use of certain accounts by defining the
days of the week as either PRIMARY or SECONDARY, and then assigning
login restrictions to these day types. For example, if you define
the days Saturday and Sunday as SECONDARY days, then any restrictions
you assign to the SECONDARY day type apply to both.
You can assign two types of login restrictions to either day type:
| Restriction | Description |
|---|---|
|
Time restrictions
|
Limits logins to specific
hours of the day
|
|
Function restrictions
|
Limit types of login
|
The default user record defines the five weekdays (Monday through Friday) as PRIMARY days, and the two weekend days (Saturday and Sunday) as SECONDARY days.
The way you define days and assign restrictions depends on your site. For example, suppose that on weekdays your system supports a large number of interactive users, but on weekends it is used for certain operations that require dedicated system resources. By assigning restrictions to the SECONDARY day type, you can restrict users from accessing the system during the days defined as SECONDARY. You can change these day type definitions for any account using the following AUTHORIZE qualifier:
/PRIMEDAYS=([NO]day[,...])The /PRIMEDAYS qualifier uses a list of day names to define the PRIMARY and SECONDARY days of the week. To define a day as a SECONDARY day, use the prefix NO before the day name. Any days you omit from the list take their default value.
Restricting Logins to Specific Times ![]()
By default, there are no restrictions on login hours. You
can specify login time restrictions using the following AUTHORIZE
qualifiers:
| Qualifier | Meaning |
|---|---|
|
/[NO]ACCESS
|
Specifies access hours for
all modes of logins
|
|
/[NO]DIALUP
|
Specifies access hours for
interactive logins from dialup terminals
|
|
/[NO]INTERACTIVE
|
Specifies access hours for
interactive logins from any terminal
|
|
/[NO]LOCAL
|
Specifies access hours for
interactive logins from local terminals
|
|
/[NO]REMOTE
|
Specifies access hours for interactive
logins from network remote terminals (SET HOST)
|
Interactive users still logged in when the access time has expired receive the following warning message and have 2 minutes to log out before their processes are terminated by the job controller:
JBC-W-RESTRICT, UAF restricts access at this time, please log out immediatelyNote that network connections are treated differently than interactive connections and batch jobs. See the documentation for the network software you are running for information about disconnecting established network connections.
Restricting CPU Time ![]()
OpenVMS Version 7.3
and later enables you to perform class scheduling using the SYSMAN
interface.
You can limit the amount of CPU time that a user receives on the system by placing the user into a scheduling class. Each scheduling class is assigned a percentage of the overall CPU time on the system. As the system runs, the set of users in each scheduling class is limited to the percentage of CPU execution time allocated to that class. Users in a scheduling class can get additional CPU time if windfall is enabled for their scheduling class. Enabling windfall allows the system to give a small amount of CPU time to a scheduling class when a CPU is idle and the time alloted to that scheduling class has already been depleted.
To invoke the class scheduler, use the SYSMAN interface. SYSMAN allows you to create, delete, modify, suspend, resume, and display scheduling classes. SYSMAN command: class_schedule describes the SYSMAN command, class_schedule, and its sub-commands.
By using a permanent class scheduler, a process is placed into a scheduling class, if appropriate, at process creation time. When a new process is created, it needs to be determined whether this process belongs to a scheduling class. Since to determine this relies upon data in the SYSUAF file, and the Loginout image already has the process' information from this file, Loginout class schedules the process if it determines that the process belongs to a scheduling class.
When you use the SYSMAN command CLASS_SCHEDULE ADD, you can do the following:
For example:
SYSMAN> CLASS_SCHEDULE ADD MAINCLASS - _SYSMAN> /ACCOUNT = (ACCTNAME1, ACCTNAME2) - _SYSMAN> /USERNAME = HOTSHOT - _SYSMAN> /CPU_LIMIT = (PRIMARY, 08-17=15, SECONDARY, 00-23=30) - _SYSMAN> /WINDFALLThis example performs the following actions:
Note that you can use the /PRIMEDAYS qualifier to change the primary and secondary days assigned to a scheduling class.
CPU time restrictions created with the class scheduler do not apply to system users (see Understanding Protection Codes).
For more detailed information about the SYSMAN CLASS_SCHEDULE command, see the HP OpenVMS System Management Utilities Reference Manual: M--Z.
Restricting Login Functions ![]()
In addition to specifying hourly login restrictions, you can
assign function restrictions to an account by using appropriate
keywords with the /FLAGS qualifier in the Authorize utility. By
default, there are no restrictions. Options are shown in the following
table:
| Keyword | Meaning |
|---|---|
|
[NO]AUDIT
|
[Do not] audit all security-relevant
actions.
|
|
[NO]AUTOLOGIN
|
[Do not] prevent access
except by automatic login when automatic logins are enabled.
|
|
[NO]CAPTIVE
|
[Do not] prevent user from
changing any defaults at login (implies DISCTLY).
|
|
|
[Do not] deny user access
to the DCL command level.
|
|
[NO]DEFCLI
|
[Do not] prevent user from
changing default CLI or CLI tables.
|
|
[NO]DISCTLY
|
[Do not] disable Ctrl/Y
interrupts.
|
|
[NO]DISFORCE_PWD_CHANGE
|
[Do not] remove requirement
that user must change an expired password at login.
|
|
[NO]DISIMAGE
|
[Do not] prevent user from
using the RUN or MCR commands or from executing "foreign" commands.
|
|
[NO]DISMAIL
|
[Do not] prevent mail delivery
to the user.
|
|
[NO]DISNEWMAIL
|
[Do not] suppress "New
Mail... " announcements.
|
|
[NO]DISPWDDIC
|
[Do not] disable automatic
screening of new passwords against a system dictionary.
|
|
[NO]DISPWDHIS
|
[Do not] disable automatic
checking of new passwords against list of user's old passwords.
|
|
[NO]DISRECONNECT
|
[Do not] disable automatic
reconnection to an existing process when a terminal connection has
been interrupted.
|
|
[NO]DISREPORT
|
[Do not] disable reporting
of login information (last login date, login failures, and so on).
|
|
[NO]DISUSER
|
[Do not] disable account
completely.
|
|
[NO]DISWELCOME
|
[Do not] suppress "Welcome
to... " login message.
|
|
[NO]GENPWD
|
[Do not] require user to
use generated passwords.
|
|
[NO]LOCKPWD
|
[Do not] prevent user from
changing password.
|
|
[NO]PWD_EXPIRED
|
[Do not] mark password as
expired.
|
|
[NO]PWD2_EXPIRED
|
[Do not] mark second password
as expired.
|
|
[NO]RESTRICTED
|
[Do not] prevent user from changing any
defaults at login.
|
Using Login Command Procedures for Restricted
or Captive Accounts ![]()
Using the /LGICMD qualifier with the AUTHORIZE commands ADD,
MODIFY, or COPY defines the login procedure for a restricted or
captive account. A person logging in to such an account cannot modify
the procedure with any of the login qualifiers: /CLI, /DISK, /COMMAND,
/NOCOMMAND, /TABLES.
The CAPTIVE and RESTRICTED flags perform the following actions:
Once logged in, a person using a restricted account operates from the DCL level and can access any available software.
A person using a captive account is locked into the application software where access to the DCL level is denied, provided the system manager observes the following practices:
| ampersand (&) and double ampersand (&&) |
| angle brackets (<) (>) |
| apostrophe (') |
| at-sign (@) |
| dollar sign ($) |
| hyphen (-) |
| quotation mark (") |
| semicolon (;) |
| vertical bar (|) and double vertical bar (||) |
A simple login command procedure for a captive account used for an inventory system might consist of the following commands:
$ DEFINE SYS$DISK DISK$INVENT $ RUN INVENTORY $ LOGOUTThe application program INVENTORY assumes control when the user logs in to the account. Assign the CAPTIVE flag to the login flags field of the captive account UAF record by specifying the AUTHORIZE qualifier /FLAGS=CAPTIVE. Maintaining the User Environment shows how to use AUTHORIZE to create a UAF record for a captive account.
Sample Captive Command Procedure is a command procedure for a highly secure captive account, which restricts the user to a very limited set of commands. System managers must be sure to deny the account owner any write access to the login command procedure and its directory. Note also that the security manager would use the AUTHORIZE qualifier /NOINTERACTIVE when establishing this account.
For more information about captive and restricted accounts, see the HP OpenVMS Guide to System Security .
Setting Priorities for User Processes ![]()
A user's priority is the base priority used in scheduling
the process that the system creates for the user.
On VAX systems, priorities range in value from a low of 0 to a high of 31; 0 through 15 are timesharing priorities; 16 through 31 are real-time priorities.
On Alpha and I64 systems, priorities range in value from a low of 0 to a high of 63; 0 through 15 are timesharing priorities; 16 through 63 are real-time priorities.
Processes with real-time priorities are scheduled strictly according to base priority; in other words, the executable real-time process with the highest base priority is executed first. Processes with timesharing priorities are scheduled according to a slightly different principle to promote overlapping of computation and I/O activities.
In the user's account record of the UAF, the default value of a user's priority is 4; for practical purposes, the minimum value is 0. Ensure that the priority for timesharing users remains at the default. Note that if you give some users an advantage over other users by raising their priorities, ragged performance results, because the system reacts sharply to even small base priority differences.
|
|