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-32
Changes to the PAID During a User’s Session
With these remote passwords, SALES.FRED can access objects on \SF when he is
logged on with the alias Freddie at \NY. SOFTWARE.JOE can access objects on \NY
when he is logged on with alias Freddie at \SF. However, Safeguard access control
decisions are based on the underlying user ID of the alias at the remote node. In effect,
SALES.BOB has access to objects to which SOFTWARE.JOE is normally granted
access at \SF, and vice versa.
Changes to the PAID During a User’s Session
Prior to D30 Safeguard, remote validation is always based on the PAID of the process
running on behalf of the requesting user. In most instances, the PAID is the same as
the user ID of the user who initially logged on at the start of the session. Under certain
circumstances, such as when the user executes a PROGID program, the PAID is
changed so that it no longer matches the original user ID. For remote validation to be
successful in this instance, matching remote passwords must exist for the user ID
identified by the PAID.
Remote validation involving systems running D30 Safeguard functions similarly, with
one distinct exception. If the user originally logged on as an alias, and the PAID of the
process running on behalf of the alias remains unchanged, the alias name rather than
the PAID is used for remote validation. (For more information, see User Aliases.) If the
PAID has changed during the session, the user ID identified by PAID is used for
remote validation.
Additional Considerations for Aliases and Groups
D30 and later Safeguard offers features that include the support of user aliases and
file-sharing groups. When you define users for remote access, you should be aware of
certain additional considerations regarding these features.
Additional Considerations for ACCESS with Network Specific
Subject IDs
The global configuration attribute ALLOW-NODE-ID-ACL defines whether ACL entries
containing explicit node identifiers for subjects are consulted to determine access. The
initial ALLOW-NODE-ID-ACL value is off, ignoring ACL entries containing explicit node
identifiers.
User Aliases
If a user who logs on as an alias is to have remote access to another node, alias
authentication records with matching underlying user IDs and remote passwords must
be defined on both the local and remote nodes. When an alias attempts remote
access, the alias authentication record on the remote node is checked for a matching
user ID and remote password. The underlying user name of the alias requesting
access is not verified on the remote node. The same alias can have a different
underlying user names at different nodes.