Chat now with support
Chat mit Support

Safeguard Authentication Services 5.1.2 - Administration Guide

Privileged Access Suite for UNIX Introducing One Identity Safeguard Authentication Services Unix administration and configuration Identity management Migrating from NIS Managing access control Managing local file permissions Certificate Autoenrollment Integrating with other applications Managing UNIX hosts with Group Policy
Safeguard Authentication Services Group Policy
Group Policy Concepts Unix policies One Identity policies
Display specifiers Troubleshooting Glossary

Setting up access control

To use Logon To to set up access control

  1. Turn on log on support by setting the use-log-on-to option to true in the vas_auth section of the vas.conf file.

  2. Open Active Directory Users and Computers.

  3. Right-click the user, choose All Tasks > Logon To.

    The Logon To dialog displays.

  4. Click Add to open the Select Computers dialog.

  5. Enter the name of a permitted computer and click OK.

  6. Repeat this procedure to specify additional computers.

Configuring local file-based access control

Lines starting with "#" in the users.allow and users.deny files are comments. Valid entries may be Active Directory users or groups (both UNIX-enabled and standard) in the Domain\sAMAccountName format (preferred), Active Directory organizational units, and Active Directory domain names, or you may define users with the user principal name format (for backward compatibility).

Using non-UNIX-enabled groups is useful in environments where UNIX-enabled users easily hit the group membership limits of UNIX. For purposes of access control, Safeguard Authentication Services treats both UNIX-enabled and non-UNIX Active Directory groups the same. Remember that Safeguard Authentication Services only uses UNIX-enabled Active Directory groups to control permissions on UNIX files and directories. Non-UNIX-enabled groups are only updated and added to the cache when the user logs in, as this group information is obtained from the user's PAC encoded in the Kerberos tickets obtained during log in. These groups can be from anywhere in the Active Directory forest.

When determining if a given user is a member of a group, by default Safeguard Authentication Services only considers the explicit membership of the group. This is to avoid potential security holes when administrators have ACL's controlling group membership, but are unable to control who manages the GID number attribute for users. In versions of VAS previous to 2.6.22, this behavior was different in that the implicit membership of UNIX-enabled groups was also used. You can enable this old behavior by setting the checkaccess-use-implicit option to true in the [vas_auth] section in vas.conf. When checkaccess-use-implicit is set to true, a user is considered a member of a group if that group is UNIX-enabled, and the user's primary GID matches the group's GID.

Also note that in determining whether a given user belongs to an organizational unit (OU), Safeguard Authentication Services supports OU nesting with the OU closest to the user's actual distinguished name (DN) taking precedence.

Since it is possible to put groups into /etc/opt/quest/vas/users.allow and /etc/opt/quest/vas/users.deny, you can set each file's contents once and then manage who has access to that UNIX host through Active Directory by managing the group membership lists of the groups used in the files.

The following is an example of a /etc/opt/quest/vas/users.allow file that grants access to the Fred and Sue users and to the unixAdmins group:

# users.allow - allow fred, sue, and the unixAdmins group
example\fred
example\sue
example\unixAdmins

The following example shows a /etc/opt/quest/vas/users.deny file that is configured to deny access to user brad. This user belongs to the unixAdmins group, but has had his access taken away.

# users.deny - don't let brad in regardless of group membership
example\brad

Note: Note that in most cases Safeguard Authentication Services uses /etc/opt/quest/vas/users.allow more often than the /etc/opt/quest/vas/users.deny file.

Safeguard Authentication Services provides the /etc/opt/quest/vas/users.deny file to allow maximum flexibility to administrators.

Resolving conflicts between the allow and deny files

If a user is allowed by the users.allow file and denied by the users.deny file (either directly or indirectly), you must resolve the inconsistency. As a quick rule of thumb, precedence is given to the more specific user reference. The precedence is as follows: user listed (sAMAccountName or UPN), group listed, OU listed, and domain listed.

If there is a tie between users.allow and users.deny, users are denied access. In the following table, the columns represent users.deny and the rows represent users.allow.

Table 17: Conflict resolution
  No file User Group OU Domain Not listed
No File

A

D

D

D

D

A

User

A

D

A

A

A

A

Group

A

D

D

A

A

A

OU

A

D

D

*

A

A

Domain

A

D

D

D

D

A

Not Listed

D

D

D

D

D

D

Note: The labels in ALL CAPS indicate the users.deny files, while the labels in Title Caps indicate the users.allow files. The asterisk (*) in the table denotes that if a user is both denied and allowed by means of OU membership, the OU closest to the object takes precedence. If the same OU is specified in both files, the user is denied access.

Rules for System Access

  • No File

    There is no file, or else the file is empty with no entries.

  • User

    The user is explicitly listed.

  • Group

    A group to which user belongs is listed.

    Note: Non-Unix-enabled/Active Directory-only groups used for host access do not count against group membership limits.

  • OU

    An OU to which the user belongs is listed. For example, if a user's distinguished name is CN=John,CN=Users, DC=example,DC=com, then the OU of CN=Users,DC=example,DC=com would match the user John.

  • Domain

    The Active Directory domain to which the user belongs is listed. For example, if a user belongs to the example.com domain, then @example.com is listed.

  • Not listed

    The entries do not include the user in any way.

Note: The allowed scenarios (same descriptions as those listed above) make up each row of the matrix.

Per-service access control

If you are using local file-based access control, it is possible to configure different sets of Allow and Deny rules for each individual authentication service. Per-service access control is only supported on PAM-based systems. Service-specific Allow and Deny rules take precedence over other access control rules that may be in effect.

The default directory for service access configuration files is /etc/opt/quest/vas/access.d. You can override this by setting the service-access-dir option in vas.conf. Access control rules are specified in files named <service>.allow and <service>.deny in the /etc/opt/quest/vas/access.d directory where <service> is replaced with the name service according to PAM.

The following example sshd service access control configuration allows members of the ssh_users group access, but not pspencer@example.com. This example assumes that you have created sshd.allow and sshd.deny in the /etc/opt/quest/vas/access.d directory:

# sshd.allow - Allow only users that are members of ssh_users group
EXAMPLE\ssh_users
# sshd.deny - deny pspencer access regardless of group membership 
EXAMPLE\pspencer

Note: If either of the <service>.allow or <service>.deny files exist, then both the users.allow and users.deny files will be ignored.

Note: The vas.conf options hide-if-denied and check-host-access do not support service-specific access control settings because there is no way to associate a service with the access checks performed by these options.

A service-specific allow file cannot allow a user explicitly denied by the Windows Security Policy.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen