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.

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

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 "#":
  $ sudo -g '#1013' id
  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


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

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.