Using VAS and SUDO to manage administrative (root) access to UNIX systems

This guide explains sudo, its advantages and provides examples of use with VAS.

Introduction
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
Summary

Introduction

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 Vintela Authentication Services (VAS), 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.

VAS is well-suited for using administrative groups with sudo because VAS uses 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 VAS, it creates a Kerberos ticket that contains PAC data.

Availability

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 VAS. 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 10/sparc, 10/intel, 9/sparc, 8/sparc, 8/intel, 2.6/sparc
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 VAS 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);
Enable it as a VAS unix group;
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.
The % character before %UnixAdmins indicates 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 ALL is 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 ALL is the command list. In this case, ALL is 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 NOPASSWD: directive. When PASSWD: option is used on a command list, sudo authenticates through to PAM and NSS, which in turn call VAS 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.

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 Vintela Group Policy Administrator's 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
'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.

Summary

With a VAS/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, VAS, 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 VAS enabled system.

The combination of VAS, sudo, and Active Directory allows you to conveniently and securely manage root level access to UNIX and Linux hosts.