Safeguard Administrator's Manual (G06.24+, H06.03+)
Table Of Contents
- What’s New in This Manual
- About This Manual
- 1 Introduction
- 2 Controlling User Access
- Introduction
- Using SAFECOM to Establish a Local User Community
- Using SAFECOM to Manage User Access to Your System
- Changing the Owner of a User Authentication Record
- Granting a User Temporary Access to Your System
- Requiring Users to Change Their Passwords
- Granting a Grace Period for Changing an Expired Password
- Forcing Immediate Expiration of a User’s Password
- Freezing a User's Ability to Access the System
- Specifying Auditing for a User ID
- Deleting Users
- Deleting Administrative Groups
- Using SAFECOM to Establish a Network of Users
- Using Safeguard With Nodes With Standard Security
- Identifying Network Users
- Granting a Network User Access to Objects on Your System
- Establishing a Community of Network Users
- Changes to the PAID During a User’s Session
- Additional Considerations for Aliases and Groups
- Additional Considerations for ACCESS with Network Specific Subject IDs
- Establishing Default Protection for a User's Disk Files
- Specifying a Default Command Interpreter for a User
- Establishing Guardian Defaults
- Assigning an Alias to a User
- 3 Managing User Groups
- 4 Securing Volumes and Devices
- 5 OBJECTTYPE Control
- 6 Managing Security Groups
- 7 Securing Terminals
- 8 Warning Mode
- 9 Configuration
- Safeguard Attributes
- Configuring User Authentication
- Configuring Password Control
- Configuring Device Control
- Configuring Process Control
- Configuring Disk-File Control
- Configuring Safeguard Auditing
- Configuring a Default Command Interpreter
- Configuring Communication With $CMON
- Configuring Logon Dialog
- Configuring Exclusive Access at Safeguard Terminals
- Configuring Warning Mode
- Configuring Persistence
- Configuring Attributes for Node Specific Subjects in ACLs
- 10 Installation and Management
- Safeguard Components
- Process Considerations for the SMP and SAFECOM
- Safeguard Subsystem Management Commands
- General Installation Procedure
- Installing the Safeguard Software
- Starting the SMP
- Converting to the Safeguard Subsystem
- Updating the Safeguard Software
- Guidelines for Securing the Safeguard Subsystem
- Monitoring the Safeguard Subsystem
- A SAFECOM Command Syntax
- Index
Controlling User Access
Safeguard Administrator’s Manual—523317-013
2-21
Requiring Users to Change Their Passwords
and asks her to find out why he cannot log on. Susan runs SAFECOM and enters the
following INFO USER command:
=INFO USER admin.bob
The STATUS field in the short INFO USER report shows SECURITY.SUSAN that
ADMIN.BOB's password has expired.
To restore ADMIN.BOB's ability to log on to the system, SECURITY.SUSAN uses the
ALTER USER command to change his PASSWORD-EXPIRES date and the INFO
USER command to check the results:
=ALTER USER admin.bob, PASSWORD-EXPIRES 29 jul 05, 18:00
=INFO USER admin.bob, GENERAL
The INFO USER report shows that ADMIN.BOB's status is now THAWED (that is, he
can log on to the system). Bob has until 6:00 p.m. on July 29 to change his password.
When ADMIN.BOB changes his password, the Safeguard software recalculates the
PASSWORD-EXPIRES date by adding the PASSWORD-MUST-CHANGE period to
the current date.
GROUP.USER USER-ID OWNER LAST-MODIFIED LAST-LOGON STATUS WARNING-MODE
ADMIN.BOB 1,0 200,1 28JUN05, 14:09 27JUL05, 08:02 PSWD-EXP OFF
GROUP.USER USER-ID OWNER LAST-MODIFIED LAST-LOGON STATUS WARNING-MODE
ADMIN.BOB 1,0 200,1 29JUL05, 8:38 27JUL05, 8:02 THAWED OFF
UID = 256
USER-EXPIRES = * NONE *
PASSWORD-EXPIRES = 29JUL05, 18:00
PASSWORD-MAY-CHANGE = * NONE *
PASSWORD-MUST-CHANGE EVERY = 30 DAYS
PASSWORD-EXPIRY-GRACE = * NONE *
LAST-LOGON = 27JUL05, 8:02
LAST-UNSUCESSFUL-ATTEMPT = * NONE *
LAST-MODIFIED = 29JUL05, 8:38
FROZEN/THAWED = THAWED
STATIC FAILED LOGON COUNT = 0
GUARDIAN DEFAULT SECURITY = OOOO
GUARDIAN DEFAULT VOLUME = $SYSTEM.NOSUBVOL
Note. If you set the user’s PASSWORD-EXPIRES attribute after setting the
PASSWORD-MUST-CHANGE attribute, the explicit setting of the PASSWORD-EXPIRES
attribute overrides the PASSWORD-EXPIRES date previously calculated as a result of setting
PASSWORD-MUST-CHANGE.
If you set the user’s PASSWORD-MUST-CHANGE attribute after setting the
PASSWORD-EXPIRES attribute, the PASSWORD-EXPIRES date calculated as a result of
setting PASSWORD-MUST-CHANGE overrides the explicit setting of the
PASSWORD-EXPIRES attribute. That is, whichever attribute is set last takes precedence over
the other setting.