Using Quest Authentication Services and Sudo to manage administrative (root) access to Unix systems
This guide explains Sudo, its advantages and provides examples of use with Quest Authentication Services.
- Example: Configuring sudo to authorize by AD group membership
- Example task: changing the ownership of a file
- Finer-grained authorization
- Managing sudoers file with VGP
- Quest Enhancements
Windows and UNIX systems implement different models for granting privileged access and control to administrative users. Microsoft's Active Directory grants access to all user and system configuration attributes and administrative actions within its domain based on the acting user's membership in administrative groups such as Domain Admins or Enterprise Admins.
UNIX, on the other hand, uses the root account as a coarse bypass of normal access checks. In environments where machines are administrated by teams rather than a single individual, access to the root account must be shared, typically by sharing the root password.
Two disadvantages of the UNIX model are the increased security vulnerability and the corresponding management burden of maintaining root passwords on multiple machines. If a single root password used on multiple machines is compromised, then all machines are compromised. Also, regularly changing the root password (even if only in response to events such as an employee termination) involves some overhead.
A tool to address these problems is sudo. The sudo tool is an open source project (homepage) Sudo provides a highly configurable mechanism for allowing specific users (more importantly, specific groups) access to run restricted sets of commands with the privileges of root.
By combining sudo with Quest Authentication Services (QAS), you can manage access to administrative privileges entirely from within Active Directory and in a manner consistent with the Active Directory authorization model.
Quest Software recommends that you do not manage the root account as an Active Directory user. While this is technically feasible, a root identity in Active Directory does not correspond to an actual real-world user. Instead, using sudo to grant root access to users by group membership permits you to audit through log files which real-world users accessed root privileges and what commands they invoked.
Quest Authentication Services is well-suited for using administrative groups with sudo because it uses local PAC data to look up group membership. PAC is a Microsoft Active Directory extension to the Kerberos ticketing structure that contains group membership information. When a user authenticates on a UNIX system using Quest Authentication Services, it creates a Kerberos ticket that contains PAC data.
Sudo is included with most Linux distributions and has been packaged for many other variations of UNIX.
Note: Sudo must have been compiled to use PAM for it to work with Quest Authentication Services. Some versions compiled for Solaris do not have this property.
The following distributions of sudo have been tested by us on non-linux platforms and are known to work:
- Solaris: sudo-1.6.8p9 for Solaris
the sudo that comes on Solaris 10's Software Companion CD also works
- AIX: sudo-1.67.p5 for AIX 5.1+, 4.3.3
Example: Configuring sudo to authorize by AD group membership
This section shows how Quest Authentication Services and sudo work together in an example scenario.
A site wishes to create a group to hold all the UNIX system administrators and then grant access to sudo for all the members. The UNIX system administrators are IT personnel, John Smith (johns), John Doe (jdoe), and Sally Smith (sallys).
- Create an Active Directory group named UnixAdmins (Note that UNIX does not allow space characters in group names);
- Unix-enable the group (in the group properties dialog)
- Add the users johns, jdoe and sallys to the UnixAdmins group;
- On each UNIX host, use the visudo tool (part of sudo) and add this line
%UnixAdmins ALL=(ALL) PASSWD: ALL
These steps are explained in detail:
- The visudo tool locks and edits the /etc/sudoers file which is read by the sudo tool to authorize actions. It also checks the file for syntax errors.
- The sudo distribution contains a sample /etc/sudoers file with all of the example commands commented out but the documentation available on the site contains more extensive examples. These and the above example are provided as a "proof of concept" — you should study the full capabilities (and limitations) of sudo before attempting to deploy in a production environment.
%UnixAdminsindicates to sudo that UnixAdmins is a group and not a username. This user specification indicates which user or group the directive on this line is applied to.
- The keyword
ALLis a special alias that matches any invocation context. The sudo configuration language allows, among other features, aliases to be defined for users (including groups), hosts, 'runas' specifications, and commands. The first '
ALL' in the example line matches all hosts so members of UnixAdmins can execute commands as root on any host. Alternatively, you could specify an alias or list of fully qualified host names (e.g.
server.example.com) and narrow the application to only those systems.
- The second '
(ALL)' is a runas list that can be changed to allow the invoked command to be run as a different user, instead of root.
- The final
ALLis the command list. In this case,
ALLis used to indicate that it applies to any commands run by members of UnixAdmins. The command list is qualified with the
PASSWD:directive, meaning that users must authenticate themselves each time sudo is invoked to run a command. You can change this behavior by using the corresponding
PASSWD:option is used on a command list, sudo authenticates through to PAM and NSS, which in turn call Quest Authentication Services to obtain the Active Directory user and group identities.
Example task: changing the ownership of a file
Consider now that John Smith needs to change the ownership of a file on one of the managed unix hosts so it can be controlled by Joe Bloggs (jbloggs). John Smith logs in to the host as johns using his normal user password, and then executes:
johns@unixhost$ sudo chown jbloggs /some/file Password:
Sudo prompts for John's password before executing the chown command as root. After the command completes, johns remains logged in as johns.
Had John Smith wanted to perform a great many operations as root, he may have chosen to run a shell as root, which provides the equivalent functionality of su:
johns@unixhost$ sudo /bin/sh Password: # chown jbloggs /some/file #
Warning: Commands executed in a root shell are not logged.
Sudo provides great flexibility through the sudoers file, allowing you to adapt it to diverse requirements. For example, you could allow one group of users to execute only a specific set of commands associated with their particular job functions (such as running backup utilities) without granting them unlimited root access. You could also organize groups by the type of system administered, so the group SolarisAdmins could access only the Solaris systems, while LinuxAdmins would be for administering the Linux hosts.
Managing sudoers file with VGP
Sudo's configuration file can be managed by Quest Management eXtensions for SMS (VMX).
VGP can manage the deployment of sudoers files from Active Directory using Group Policy. VGP ships with sudo policies which allow domain administrators to configure the /etc/sudoers file for a large number of managed unix hosts.
The sudo policies allow administrators to set up aliases, override built-in defaults, and configure rules.
Detailed help text for this feature is provided with the ADM file. See the Quest Authentication Services Solutions Guide for more details.
This section contains the text of the "README.Quest" file, available in the source and binary packages of Quest Sudo.
2: readfile(http://rc.quest.com/gitweb/gitweb.cgi?p=sudo.git;a=blob_plain;f=README.Quest): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found at /home/www/rc.quest.com/html/topics/sudo/howto.php:216
|Message||readfile(http://rc.quest.com/gitweb/gitweb.cgi?p=sudo.git;a=blob_plain;f=README.Quest): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found|
With Quest Authentication Services and an Active Directory infrastructure, you can define root access policies for the entire organization in a single /etc/sudoers file that can be centrally maintained and replicated enterprise wide. The conditions you define in sudoers allow precise control of access policies. The use of groups with Quest Authentication Services and Active Directory allows you to abstract individual user identities out of the Unix hosts being managed and controlled in Active Directory along with all other user account information.
You can grant all levels of access (to commands, systems, etc.) on the basis of group membership. When employees or team members change, their privileges are reflected in Active Directory and do not need to be reconfigured on a per UNIX host basis. The /etc/sudoers file can reference any Active Directory user or group on a Quest Authentication Services-enabled system.
The combination of Quest Authentication Services, sudo, and Active Directory allows you to conveniently and securely manage root level access to UNIX and Linux hosts.