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 might 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. |
Certificate distribution policy
Group Policy supports the ability to distribute trusted certificates. Certificates in the "Trusted Root Certification Authorities" and "Intermediate Certification Authorities" group policies (located at <Policy_Object_Name>/Computer Configuration/Windows Settings/Security Settings/Public Key Policies/) are automatically copied to the Unix host. After group policy has applied them, the certificates are located at /var/opt/quest/vas/certs/CA/ and are automatically copied into Keychain on Mac OS X.
Refer to the following link for the procedure to add a trusted root certification authority to a Group Policy object: http://technet.microsoft.com/en-us/library/cc738131%28v=ws.10%29.aspx
Managing local file permissions
Changing file ownership manually
Changing file ownership using the script
Active Directory User Information file
Authentication Services provides tools to help consolidate Unix identity into a single entity in Active Directory. As part of this process you may need to change permissions on local Unix files and directories. The Ownership Alignment Tool (OAT) helps simplify this process by matching accounts and providing the ability to roll back changes.