Quest Sudo

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.


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:

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).

  1. Create an Active Directory group named UnixAdmins (Note that UNIX does not allow space characters in group names);
  2. Unix-enable the group (in the group properties dialog)
  3. Add the users johns, jdoe and sallys to the UnixAdmins group;
  4. 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:

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

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
# chown jbloggs /some/file

Warning: Commands executed in a root shell are not logged.

Finer-grained authorization

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.

Quest Enhancements

This section contains the text of the "README.Quest" file, available in the source and binary packages of Quest Sudo.

2: readfile(;a=blob_plain;f=README.Quest): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found at /home/www/
Error typeWarning
Messagereadfile(;a=blob_plain;f=README.Quest): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
Stack trace
  1. readfile() [howto.php:216]


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.