Chat now with support
Chat with Support

Safeguard Authentication Services 4.1.5 - 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
Integrating with GPMC
Display specifiers Troubleshooting

Maintaining netgroup data

The vasd daemon maintains the netgroup cache data regardless of whether netgroup data is resolved through the name service module or through NIS (vasyp).

You can configure netgroup-mode in the vas.conf file. See the vas.conf man page for more information.

Managing access control

Authentication Services extends the native access control capabilities of Active Directory to non-Windows systems, providing centralized access control. Authentication Services allows non-Windows systems to become full citizens in Active Directory. Once you have joined your Unix, Linux, and Mac OS X systems to the Active Directory domain, you can easily control which Active Directory users are permitted to authenticate to your non-Windows systems.

Authentication Services includes the industry’s largest collection of highly flexible access control options and integrates with your existing technology. This section discusses each of these options in detail:

  • Host access control
  • Access control using the "Logon To" functionality
  • Configuring local file-based access control
  • Access control based on service (PAM only)

About host access control

Administrators commonly want to restrict access to sensitive machines on the network to selected users and groups. This is especially true of Unix machines which are used to host business critical applications.

It is possible to have fine-grained control over which Active Directory users can log in using Authentication Services.

Note: Computer access control functionality does not work with local user accounts; it only works with Active Directory user accounts.

By default, each time a user successfully authenticates, the Authentication Services authentication module checks to see if it should allow access using one of two methods: file-based access control or policy-based access control.

File-based access control involves checking access control rules stored locally on each workstation in /etc/opt/quest/vas/users.allow and /etc/opt/quest/vas/users.deny. (You can change the default location for these files with the users-allow-file and the users-deny-file options in vas.conf.)

Policy-based access control involves using Authentication Services Group Policy which enables you to apply the following four native Windows access policies under the User Rights Assignments settings in the Windows Security Policy:

  1. Access this computer from the network
  2. Deny access to this computer from the network
  3. Allow Log on Locally
  4. Deny Log on Locally

To enable application of Windows access control policies, add the option ApplyWindowsHostAccess = true under the [policy] section of the /etc/opt/quest/vgp/vgp.conf file.

Note: The four native Windows access policies listed above are the only native Windows group policy settings that Authentication ServicesGroup Policy applies and Authentication Services enforces on the client. All other native Windows policy settings are applied by Windows to the server which then enforces the policy on itself.

Authentication Services always performs access control by checking local files unless you explicitly enable application of Windows access control policies on Unix hosts. If the ApplyWindowsHostAccess option is set to true in the vgp.conf file, Authentication Services ignores local file-based access control. This means listing a user in the /etc/opt/quest/vas/users.allow or /etc/opt/quest/vas/users.deny file has no effect.

You can centrally manage both methods of access control through Active Directory using Authentication Services Group Policy. (See Managing Unix hosts with Group Policy.)

Regardless of the method you choose for managing access, locking down a machine does not require you to deny everyone access explicitly. If you define only an "allow access" policy (that is, use only a users.allow file), only users granted access through that file have access. This simplifies the process significantly.

Both access control methods allow you to specify users or groups which you want to allow or deny. If a user is specified in more than one way, the most specific reference to the user takes precedence.

For example, suppose Bob is a member of the Domain Admins group. If the Domain Admins group is allowed access to a machine, but Bob is explicitly denied, he will NOT be granted access. (See table in Resolving conflicts between the allow and deny files for additional information about the System Access Rules.)

Authentication Services honors the Logon To workstation list (on the Account tab in the ADUC snap-in) as an additional security measure in both access control modes.

Using "Logon To" for access control

Each user has a Logon To attribute that is used to store a list of FQDNs that this user is allowed to access.

If your workstation is using file-based access control (versus policy-based), the Logon To attribute is absolutely authoritative. This means if you are allowed access by the Logon To attribute, you cannot be denied by any entry in the /etc/opt/quest/vas/users.deny file. Additionally if you are denied access by the Logon To attribute (done by exclusion; that is, you specify a list of workstations, excluding the workstation you are currently logging in to) no entry in the /etc/opt/quest/vas/users.allow file has power to grant you access. In short, if the user has a value set in the Logon To attribute, the contents of /etc/opt/quest/vas/users.allow or /etc/opt/quest/vas/users.deny file are ignored.

When using policy-based access control, the interaction between Logon To and the access policies are the same as they are with Windows clients. You have to be allowed by both the access control policy and the Logon To attribute before you are admitted. Being denied by either is enough to reject access.

Related Documents