SURROGATE Class

Each record in the SURROGATE class defines restrictions that protect a user from other users when they try to change their identity to his or hers.  treats a change identity request as an abstract object that can be accessed only by authorized users.
capamsc141
Each record in the SURROGATE class defines restrictions that protect a user from other users when they try to change their identity to his or hers. 
PAM Server Control
 treats a change identity request as an abstract object that can be accessed only by authorized users.
A record in the SURROGATE class represents each user or group who has surrogate protection. Two special records-USER._default and GROUP._default-represent users and groups who do not have individual SURROGATE records. If there is no need to differentiate between the default for users and the default for groups, you may use the _default record for the SURROGATE class instead.
Many Windows utilities and services (for example, Run As) identify as user
NT AUTHORITY\SYSTEM
and not as the original user running them. To let users who use these utilities and services as impersonate another user, you must create this SYSTEM user in the 
PAM Server Control
 database and authorize it to impersonate the target user.
The key of the SURROGATE class record is the name of the SURROGATE record.
The following definitions describe the properties that are contained in this class record. Most properties are modifiable and can be manipulated using selang or the administration interfaces. Non-modifiable properties are marked 
informational
.
  • ACL
    Defines a list of accessors (users and groups) permitted to access the resource, and the accessors access types.
    Each element in the access control list (ACL) contains the following information:
    • Accessor
      Defines an accessor.
    • Access
      Defines the access authority that the accessor has to the resource.
    Use the access parameter with the authorize or authorize- command to modify the ACL.
  • CALACL
    Defines a list of the accessors (users and groups) that are permitted to access the resource, and their access types according to the Unicenter NSM calendar status.
    Each element in the calendar access control list (CALACL) contains the following information:
    • Accessor
      Defines an accessor.
    • Calendar
      Defines a reference to a calendar in Unicenter TNG.
    • Access
      Defines the access authority that the accessor has to the resource.
    Access is permitted only when the calendar is ON. Access is denied in all other cases.
    Use the calendar parameter with the authorize command to permit user or group access to the resource according to the access defined in the calendar ACL.
  • CALENDAR
    Represents a Unicenter TNG calendar object for user, group, and resource restrictions in 
    PAM Server Control
    PAM Server Control
     fetches Unicenter TNG active calendars at specified time intervals.
  • CATEGORY
    Defines one or more security categories that are assigned to a user or a resource.
  • COMMENT
    Defines additional information that you want to include in the record. 
    PAM Server Control
     does not use this information for authorization.
    Limit:
     255 characters.
  • CREATE_TIME
    (Informational) Displays the date and time when the record was created.
  • DAYTIME
    Defines the day and time restrictions that govern when an accessor can access a resource.
    Use the restrictions parameter with the chres, ch[x]usr, or ch[x]grp commands to modify this property.
    The resolution of daytime restrictions is one minute.
  • GROUPS
    Defines the list of CONTAINER records that a resource record belongs to.
    To modify this property in a class record, change the MEMBERS property in the appropriate CONTAINER record.
    Use the mem+ or mem- parameter with the chres, editres or newres command to modify this property.
  • NACL
    The
    NACL
     property of a resource is an access control list that defines the accessors that are denied authorization to a resource, together with the type of access that they are denied (for example, write). See also ACL, CALACL, PACL. Each entry in the NACL contains the following information:
    • Accessor
      Defines an accessor.
    • Access
      Defines the type of access that is denied to the accessor.
    Use the authorize deniedaccess command, or the authorize- deniedaccess- command, to modify this property.
  • NOTIFY
    Defines the user to be notified when a resource or user generates an audit event. 
    PAM Server Control
     can email the audit record to the specified user
    .
    Limit:
     30 characters.
  • OWNER
    Defines the user or group that owns the record.
  • PACL
    Defines a list of accessors that are permitted to access the resource when the access request is made by a specific program (or a program that matches a name-pattern) and their access types. Each element in the program access control list (PACL) contains the following information:
    • Accessor
      Defines an accessor.
    • Program
      Defines a reference to a record in the PROGRAM class, either specifically or by wildcard pattern matching.
    • Access
      Defines the access authority that the accessor has to the resource.
      You can use wildcard characters to specify the resource in a PACL.
      Use the via(
      pgm
      ) parameter with the selang authorize command to add programs, accessors, and their access types to a PACL. You can use the authorize- command to remove accessors from a PACL.
  • RAUDIT
    Defines the types of access events that 
    PAM Server Control
     records in the audit log. RAUDIT derives its name from 
    R
    esource 
    AUDIT
    . Valid values are:
    • all
      All access requests.
    • success
      Granted access requests.
    • failure
      Denied access requests (default).
    • none
      No access requests.
    • PAM Server Control
       records events on each attempted access to a resource, and does not record whether the access rules were applied directly to the resource, or were applied to a group or class that had the resource as a member.
    Use the audit parameter of the chres and chfile commands to modify the audit mode.
  • SECLABEL
    Defines the security label of a user or resource.
    The SECLABEL property corresponds to the label[-] parameter of the chres and ch[x]usr commands.
  • SECLEVEL
    Defines the security level of an accessor or resource.
    This property corresponds to the level[-] parameter of the ch[x]usr and chres commands.
  • UACC
    Defines the default access authority for the resource, which indicates the access that is granted to accessors who are not defined to 
    PAM Server Control
     or who do not appear in the ACL of the resource.
    Use the defaccess parameter with the chres, editres, or newres command to modify this property.
  • UPDATE_TIME
    (Informational) Displays the date and time when the record was last modified.
  • UPDATE_WHO
    (Informational) Displays the administrator who performed the update.
  • WARNING
    Specifies whether Warning mode is enabled. When Warning mode is enabled on a resource, all access requests to the resource are granted, and if an access request violates an access rule, a record is written to the audit log.
Example 1: 
An example to show how the SURROGATE rule refrains user “john” from switching to the “root” user to perform privileged operations.
Step 1:
Create a user “john”.
PAMSC> nu john pass(john)
Step 2:
Write the SURROGATE rule to protect “root” from the user “John”.
PAMSC> er SURROGATE USER.root owner(root) defacc(r) 
PAMSC> auth SURROGATE USER.root uid(john) access(n)
Step 3:
Verify if “john” can switch to root using “su”.
The SURROGATE rule restricts “john” from switching to the “root” account.
Example 2: 
An example to show how the SURROGATE rule refrains user “smith” from switching to another user “john”.
Step 1:
Create a user “smith”.
PAMSC> nu smith pass(smith)
Step 2:
Create a user “john”. 
PAMSC> nu john pass(john)
Step 3:
Write a SURROGATE rule to protect “john” from “smith”.
PAMSC> er SURROGATE USER.john owner(john) defacc(r)
PAMSC> auth SURROGATE USER.john uid(smith) access(n)
Step 4:
Verify if “smith” can switch to "john" using “su”.
The SURROGATE rule restricts “smith” from switching to the “john” account.
Example 3: 
An example to protect user groups using SURROGATE rule.
Step 1:
Create a group “finance”.
PAMSC> ng finance unix
Step 2:
Create a group “engineering”.
PAMSC> ng engineering unix
Step 3:
Create a user “john” and join the user to the 'finance' group.
PAMSC> nu john pass(john)
PAMSC> eu john unix pgroup(finance)
Step 4:
Create a user “smith” and join the user to the 'engineering' group.
PAMSC> nu smith pass(smith)
PAMSC> eu smith unix pgroup(engineering)
Step 5:
Prevent users from “engineering” to switch to users in “finance” group.
PAMSC> er SURROGATE GROUP.finance defacc(r)
PAMSC> auth SURROGATE GROUP.finance gid(engineering) access(n)
Step 6:
Log in as “smith” user from “engineering” and try to switch to the user “john” from the “finance” group. You notice that the access is denied due to the SURROGATE rule.
The ideal way to implement SURROGATE policy in an enterprise is to create SURROGATE rule with access via PROGRAM /opt/CA/PAMSC/bin/sesu.
The original 'su' program is backed up in a separate place and made as a link to /opt/CA/PAMSC/bin/sesu. This way, we force users to switch to other account only via 'sesu' PROGRAM. With this implementation, the example 1 changes as follows wherein we allow all users to switch to 'root' via 'sesu' PROGRAM and specifically deny access to the user "john" from switching to root. 
PAMSC> SURROGATE USER.root owner(root) defacc(n)
PAMSC> auth SURROGATE USER.root uid(*) via(pgm(/opt/CA/PAMSC/bin/sesu))
PAMSC> auth SURROGATE USER.root uid(john) access(n)