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-28
Granting a Network User Access to Objects on Your
System
Granting a Network User Access to Objects on Your System
This subsection gives instructions for using SAFECOM to set up remote passwords for
a network user. The SAFECOM ADD USER and ALTER USER commands in this
procedure can normally be executed only by the local super ID or the local group
manager.
Before a user on a remote system can access objects on your system, take these
steps:
1. Add the remote user as a local user on your system. The user name and user ID
you add to your system must be the same user name and user ID defined on the
remote system.
2. On your system, give the remote user a remote password for your system.
3. On the remote system, the remote user must be given a matching remote
password for your system.
As an example of establishing a network user, suppose your system is \NY and you
want a user on system \LA to be able to access a disk file on your system. If the
remote user's local user name is ADMIN.BOB, and his local user ID is 1,0, the
following steps give him access to your local disk file:
On the local system, \NY
Add the remote user as a local user on your system, \NY:
=ADD USER ADMIN.BOB , 1,0
Give the remote user a remote password for your system, \NY:
=ALTER USER 1,0, REMOTEPASSWORD \NY xyz
On the remote system, \LA
The remote user is given a remote password for \NY:
=ALTER USER 1,0, REMOTEPASSWORD \NY xyz
ADMIN.BOB now has one-way network access between his home node (\LA) and your
node (\NY). ADMIN.BOB at \LA can be granted the authority to access objects on your
system (\NY).
However, if ADMIN.BOB logs on to \NY, he cannot access his own objects on \LA from
\NY. Although ADMIN.BOB has matching remote passwords for \NY on both \NY and
\LA, he does not have matching remote passwords for \LA on both \LA and \NY. Before
a network user can access objects on two systems from either system, he must have
matching remote passwords for both systems set up on both systems.
Continuing with the example, the network user ADMIN.BOB can be granted two-way
access between \LA and \NY if the system managers at both systems take these
additional steps: