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 Safeguard 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 Safeguard 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 Safeguard Authentication Services Group Policy, which allows you to apply the following native Windows access policies under the User Rights Assignments settings in the Windows Security Policy:
- Access this computer from the network
- Deny access to this computer from the network
- Allow Log on Locally
- 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 Safeguard Authentication Services Group Policy applies and Safeguard 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.
Safeguard 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, Safeguard 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 Safeguard Authentication Services Group Policy. For more information, 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 that 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 the table in Resolving conflicts between the allow and deny files for additional information about the System Access Rules.
Safeguard 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.
Setting up access control
To use Logon To to set up access control
- 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.
- Open Active Directory Users and Computers.
-
Right-click the user, choose All Tasks | Logon To.
The Logon To dialog displays.
- Click Add to open the Select Computers dialog.
- Enter the name of a permitted computer and click OK.
- 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 the brad user. 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.
