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. For more information, see the vas.conf man page.
Using "Logon To" for access control
Configuring local file-based access control
Resolving conflicts between the allow and deny files
Configuring access control on ESX 4
Safeguard Authentication Services extends the native access control capabilities of Active Directory to non-Windows systems, providing centralized access control. Safeguard Authentication Services allows non-Windows systems to become full citizens in Active Directory. Once you have joined your UNIX, Linux, and macOS systems to the Active Directory domain, you can easily control which Active Directory users are permitted to authenticate to your non-Windows systems.
Safeguard 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)
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 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. For additional information about the System Access Rules, see the table in Resolving conflicts between the allow and deny files.
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.
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.
© ALL RIGHTS RESERVED. Términos de uso Privacidad Cookie Preference Center
