Authentication Services 4.2 - Administration Guide

One Identity Privileged Access Suite for Unix Introducing One Identity 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
Authentication Services Group Policy
Group Policy Concepts Unix policies One Identity policies
Display specifiers Troubleshooting

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 18: 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 indicates the users.deny files; the labels in Initial Caps indicates 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 or 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 jdoe@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 jdoe access regardless of group membership 
EXAMPLE\jdoe

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.

Configuring access control on ESX 4

If you are configuring Authentication Services on VMware ESX Server vSphere (ESX 4.0) you must decide if you want to use the ESX interface for managing access control, or if you want to use standard Authentication Services methods for managing who is allowed access to the machine by means of the users.allow and users.deny files.

By default, ESX has its own access control list stored in /etc/security/access.conf. After joining a domain, this file does not have any Authentication Services users in it; thus, no Authentication Services users will have access to the machine. If you do not modify the ESX access control list to allow specific Authentication Services users, you must allow all users in /etc/security/access.conf and begin managing access control through the Authentication Services users.allow and users.deny files.

Configuring Sudo access control

Authentication Services allows you to not only use Unix-enabled groups in sudo access control rules, One Identity provides the sudo_vas group provider module in Authentication Services to allow you to use non-Unix-enabled Active Directory groups in sudo access control rules.

Note: This feature requires Sudo 1.8. If you are upgrading from One Identity Sudo 1.7, you must move the sudoers file from /etc/opt/quest/sudo/sudoers to /etc/sudoers.

sudo_vas uses Authentication Services to determine group membership. Once you enable sudo_vas, sudo uses it to resolve groups that are not known to the local system by means of the Name Service Switch (NSS).

Note: Refer to the sudo_vas man page for more information on the sudo add-on features provided by Authentication Services.

Enabling sudo_vas

You enable sudo_vas by running vastool configure sudo. This command configures sudo to allow access control based on Active Directory groups that are not Unix-enabled. The vastool configure sudo command inserts the group_plugin line into the sudoers file, which ensures it uses the correct path and remains valid.

Note: When using the sudo_vas group_plugin option with Privilege Manager for Sudo, the path to the sudo_vas group_plugin must be the same on all servers and any system with a joined Privilege Manager for Sudo plugin. This means you may need to create a symbolic link to the library on those systems for Privilege Manager for Sudo to resolve those Active Directory groups when handling off-line mode requests. The symbolic link must refer to the actual path for the sudo_vas group_plugin library on that system.

The group_plugin line looks similar to:

Defaults group_plugin="/opt/quest/lib/libsudo_vas.so"

The location of the configuration file (sudoers file) is determined automatically if visudo is in your PATH.

Generally, you can enable the sudo_vas module by running:

vastool configure sudo

Alternatively, you can provide the path to visudo with the -V option, or the path to a sudoers file with the -f option, as follows:

vastool configure sudo -V /usr/sbin/visudo

-OR-

vastool configure sudo -f /etc/sudoers

vastool configure sudo is not run automatically as part of vastool join. You must run vastool configure sudo explicitly if you intend to use non-Unix-enabled groups in your sudo configuration.

Note: Refer to the vastool man page for more information about enabling sudo_vas.

Related Documents