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.
Quest sudo for VAS ------------------ Table of contents: 1. newgrp-style group changing 2. Active Directory (non-unix) group matching 3. Notes on compiling from source Quest sudo has some extensions beyond the standard sudo distribution. Our extensions are also described briefly in the sudo and sudoers manpages. =============================== 1. newgrp-style group changing =============================== This extension allows the controlled changing of group ID. This can help when a user is a member of more unix-enabled Active Directory groups than can fit into the host's auxilliary GID array (typically limited to 16 groups). The "-g" flag: sudo -g
Specifies that the chosen command should be run with a different primary group id. Permission is managed through the sudoers file. Specifying -g implies "-u ", so: tedp@host$ sudo -g dev id tedp@host$ sudo -u tedp -g dev id Runs 'id' as 'tedp' with 'dev' as the primary group. tedp@host$ sudo id Runs 'id' as 'root' with root's group set. tedp@host$ sudo -u carrot id Runs 'id' as 'carrot' with carrot's group set. tedp@host$ sudo -u carrot -g vegies id Runs 'id' as 'carrot' with carrot's group set and the primary group 'vegies'. All the above examples assume the sudoers file permits such actions. The sudoers file contains a new runas_group_spec which allows specification of which groups can be used with the -g flag: tedp kookaburra = (tedp) [%cvs] ALL tedp may run all commands on kookaburra with '-g cvs' Two magic tokens, INVOKER and RUNAS_USERS_GROUPS: %opers kookaburra = (INVOKER) [%adm] ALL members of the "opers" group can use -g to run commands in with the primary group 'adm', but only as themselves. %opers kookaburra = [%adm] ALL Possibly dangerous syntax required for backwards compatability, members of the opers group can run ALL commands as root (the default runas_user) with the 'adm' primary group. %opers kookaburra = (mysql) [RUNAS_USERS_GROUPS,%syslog] /usr/sbin/mysqladmin opers can run mysqladmin as the 'mysql' user in any of that user's groups, as well as the 'syslog' group. Group IDs can be specified rather than group names in both the config file and for the "-g" option on the command-line by prefixing them with a "#": invocation: $ sudo -g '#1013' id config: tedp kookaburra = [%#1013] ALL ============================================== 2. Active Directory (non-unix) group matching ============================================== The nonunix group changes are fairly simple. Rather than just specifying %group kookaburra = (ALL) ALL you can now specify %Domain\ Users kookaburra = (ALL) ALL %"Domain Users" kookaburra = (ALL) ALL %"Domain Users@RCDEV.VINTELA.COM" kookaburra = (ALL) ALL %Domain\ Users\@RCDEV.VINTELA.COM kookaburra = (ALL) ALL %"CN=sudoers,CN=Users,DC=rcdev,DC=vintela,DC=com" kookaburra = (ALL) ALL %"S-1-2-34-5678901234-5678901234-5678901234-567" kookaburra = (ALL) ALL etc. Prior to 1.6.8p12q94, a colon was required after the '%' to specify that the group was an Active Directory group. This syntax is still supported but not required. Putting quotes around the group name is recommended for group names containing special characters like spaces or commas. An alternative, backwards-compatible syntax is to use hexadecimal escapes to specify special characters. In this example, a space is replaced by \x20 - 20 is the hexadecimal ASCII value of the space. %Domain\x20Admins kookaburra = (ALL) ALL This escape syntax is recommended for use when the same sudoers file is shared by both Quest Sudo and regular Sudo, and is generated by Quest's VGP. AD Distribution groups cannot be used for access control and are not recognized by Quest sudo. Security groups must be used instead. ================================= 3. Notes on compiling from source ================================= The shell script 'rcconfigure' found in this directory is a wrapper script that will invoke configure with the right arguments to enable the Active Directory extensions. Packages are created using 'make package'. We enable Active Directory group matching by passing this option to configure: --with-nonunix-groups=vasgroups.c The resulting Makefile requires GNU make to be used to build Sudo. You can determine whether you have GNU make by looking at the output of `make -v`. GNU make is sometimes installed separately as the 'gmake' command. You will also need the vasdev (VAS developer) package installed to successfully build the vasgroups.o object. This can be found in the SDK directory of the VAS CD.
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.