Return
-
Title
Configuring Local File-Based Access Control -
Description
Access Control can be managed through local users.allow and users.deny files.
-
Resolution
Lines starting with '#' in the users.allow and users.deny files are comments. Valid entries are user principal names, Active Directory groups, Active Directory organizational units, and Active Directory domain names.
User principal names have the form of user@domain, OU (organizational unit); distinguished names have the form of ou=myou,dc=mydc,dc=com; and domain names have the form of @domain. Any entry that does not have the '@' character or is not an LDAP distinguished name, is interpreted as a group name. You can use both Unix-enabled Active Directory groups and standard Active Directory groups.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, QAS treats both Unix-enabled and non-Unix Active Directory groups the same. Remember that QAS 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 QAS 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 invas.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), QAS 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
fred@example.com
sue@example.com
unixAdminsThe 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
brad@example.comNote: Note that in most cases QAS uses /etc/opt/quest/vas/users.allow more often than
the /etc/opt/quest/vas/users.deny file.QAS provides the /etc/opt/quest/vas/users.deny file to allow maximum flexibility to administrators.