mod_auth_vas Installation - OneIdentity/mod_auth_vas GitHub Wiki

This guide describes how to install mod_auth_vas Apache authentication module. Step-by-step instructions are given for an example web server setup on various platforms.

The mod_auth_vas module is intended to be compiled from source form for your particular version of Apache HTTPD. This is because the Apache web server's module API changes substantially between different releases and modules compiled for one version of the Apache web server are not guaranteed to function correctly with another. However, One Identity does provide a few pre-compiled mod_auth_vas packages for some of the more popular and stable operating system distributions.

This section applies to SuSE, OpenSuSE, and other modern derivations of SuSE with apache2 installed.

1. Use the following command to install the RPMs:

   # yast2 -i mod_auth_vas-ap22-3.6.8.4.i386.rpm

2. Run the setup script to create a HTTP service and check file permissions:

   # /opt/quest/sbin/setup-mod_auth_vas

3. Either:

   • edit /etc/httpd/conf.d/auth_vas.conf and specify the protected directories (details),
   • or create .htaccess files in the directories to protect (details.)

4. Finally, activate mod_auth_vas by restarting the web server:

   # /etc/init.d/apache2 restart

5. Check /var/log/apache2/error_log for error messages.

This section applies to more recent Red Hat systems with httpd-2.0 installed.

1. Use the following command to install the RPMs:

   # rpm -Uvh mod_auth_vas-http20-3.6.8.4.i386.rpm

2. If you have not created a HTTP service account, do so now:

   # /opt/quest/sbin/setup-mod_auth_vas

3. Either:

   • edit /etc/httpd/conf.d/auth_vas.conf and specify the protected directories (details),
   • or create .htaccess files in the directories to protect (details.)

4. Finally, activate the module by starting or restarting the web server.

   # /etc/init.d/httpd restart

5. Check /var/log/httpd/error_log for error messages.

This section applies to any system where an Apache web server, or derivative, is installed.

1. Prerequisites:
   • Quest Authentication Services 3.0 or later
   • the Quest Authentication Services developer kit vasdev (found in the SDK directory on the Authentication Services CD)
   • a C compiler (e.g. gcc)
   • Your Apache HTTPD's extension tool (look for a program called apxs or apxs2)
   • make. GNU make is necessary to create a platform-native package (such as an RPM). Otherwise any sane version of make will be fine.
2. Download the source package, mod_auth_vas-[version].tar.gz
3. Unpack and build the source package:

$ gzip -dc < mod_auth_vas-3.6.8.4.tar.gz | tar fx -
$ cd mod_auth_vas-3.6.8.4
$ ./configure
$ make

If this step fails, please double-check that you have all the required software listed in the earlier steps. You may need to provide the path to apxs explicitly with the --with-apxs option to configure.

4. If your operating system uses dpkg (deb) or RPM packages, you can build a native package by running: $ make package The package will be built and put in the pkg directory, then you can install it with the appropriate command, eg. dpkg -i pkg/.deb or rpm -i pkg/.rpm . Otherwise install the module directly: # make install

5. Enable the module:

   If you built & installed a package then the module will have been enabled automatically. If you installed the module manually you can enable it by adding: LoadModule auth_vas_module /path/to/apache/modules/mod_auth_vas.so to your Apache config. You can find the module path by running apxs -q LIBEXECDIR . This LoadModule line should be added after the existing LoadModule lines to avoid a possible conflict between the system's libgcc_s.so and Quest Authentication Services' libgcc_s.so.

6. Run the setup script. This will create the service account in Active Directory and set it up for use with mod_auth_vas, as well as checking that the local keytab file is usable by the Apache server: # /opt/quest/sbin/setup-mod_auth_vas

   You may need to use the -a and -c options to specify the location of apxs and Apache's config file. Run /opt/quest/sbin/setup-mod_auth_vas -h for details. It is safe to run setup-mod_auth_vas more than once, for example to review the state of the service account.

7. Restart the Apache server. (Usually /etc/init.d/httpd restart or /etc/init.d/apache2 restart) As the source is available, you are free to modify and enhance the module. If you extend mod_auth_vas in a way that is likely to be useful to other Authentication Services users, please submit a pull request!

When running the configure script, it is likely that the compiler reported by apxs will not work. In that case, re-run ./configure with CC=gcc at the end of the command-line to override the choice of compiler:

$ ./configure CC=gcc

If you get an error that strict.pm is not found when running apxs, consider changing the * apxs script (Apache/Apache/bin/apxs) to use the system's perl instead of Oracle's bundled perl by changing the first line of the apxs script to

#!/usr/bin/perl

(or wherever your system's perl program is).

If you get an error loading libdms2.so when starting httpd, set the LD_LIBRARY_PATH environment variable to your ORACLE_HOME/lib directory.

Running on a server that is not joined to the same domain is not a supported configuration for mod_auth_vas. mod_auth_vas is designed to work on a machine that is joined to the same domain, however many configurations (such as a simple "Require valid-user") usually do work on a machine that is joined to another, untrusted domain or not joined at all. If it does work you might find that some operations are slow or cause more network traffic than when run on a server that is joined to the same domain.

To install mod_auth_vas on a machine that is not joined to the domain, the domain must be set in /etc/opt/quest/vas/vas.conf by adding a line in the "[libdefaults]" section like so:

[libdefaults]
  default_realm = EXAMPLE.COM

This should be done before executing the setup-mod_auth_vas script. All other installation steps are the same, including the requirement of having the Authentication Services package(s) installed.

After installing mod_auth_vas, you now need to configure the web server to enable it for authentication and authorization on the resources you want protected. The next sections detail this process.

mod_auth_vas understands the following directives when they are used in the httpd.conf file's global and/or <VirtualHost> sections.

Debug verbosity levels for the Authentication Services API logging. Debug will be written out to system log under the name mod_auth_vas. Debug levels 0-6. Debug level 3 or higher will include nested logging when an error occurs from the LDAP or KRB5 layers of the API. The default is level 0. (Since mod_auth_vas 3.6.8.2)

The number of user objects to keep in mod_auth_vas's user cache. The default is 200. (Since mod_auth_vas 3.6.0)

The amount of time (in seconds) after which cached user objects shall be expired from mod_auth_vas's user cache. The default is 60 seconds. (Since mod_auth_vas 3.6.0)

The number of user objects to keep in mod_auth_vas's negative group cache. The default is 200. (Since mod_auth_vas 3.6.8.4)

The amount of time (in seconds) after which cached invalid group objects shall be expired from mod_auth_vas's negative group cache. The default is 60 seconds. (Since mod_auth_vas 3.6.8.4)

Changes the default Active Directory domain to assume when matching usernames with Require user. The domain defaults to the realm to which the host is joined. The domain is also displayed to users when Basic authentication is being used. Defaults to the domain that Quest Authentication Services is currently using to join the web server host to Active Directory. Note: An Active Directory 'domain' is the same as a Kerberos 'realm', and is usually written in uppercase, e.g EXAMPLE.COM. Active Directory domains should not be confused with DNS domains, although they're usually closely related.

The keytab file containing the server's Kerberos credentials. If not set, it is automatically derived from the AuthVasServerPrincipal — usually /etc/opt/quest/vas/HTTP.keytab. (Since mod_auth_vas 3.6.0)

Changes the user principal name (LDAP userPrincipalName) used by the web server. Defaults to HTTP/ which Quest Authentication Services expands to HTTP/hostname@realm, where hostname is the local machine's fully-qualified domain name, and realm is the realm (or domain) to which the host is joined. Normally this directive is not needed.

This option first appeared in version 3.6.0. It was previously called AuthVasServicePrincipal, but its meaning changed and the name became misleading. The old name is still supported.

A HTTP/ service key is necessary for your web server to engage in an SPNEGO exchange. The secret key is kept in two places: in a file accessible to the web server and in a host-based service account object inside the Active Directory server. The easiest way to create the service account and key is to use the setup-mod_auth_vas command on the web server:

# /opt/quest/sbin/setup-mod_auth_vas

Alternatively you can invoke vastool manually:

# vastool service create HTTP/

The above command creates the file /etc/opt/quest/vas/HTTP.keytab, which you should immediately chmodor chownso that the Apache web server can read it. The recommended permissions on the file are such that only the web server group can read it:

-rw-r----- 1 root apache 5600 Oct 4 09:28 /etc/opt/quest/vas/HTTP.keytab

The following directives can be placed in a .htaccess file, or in a <Directory> or <Location> section within httpd.conf.

Enables the mod_auth_vas module during requests on the resource. It permits the module to deny access to the resource depending on the satisfaction of the Require directives.

Optional string to be used in Basic authentication prompts. If not set, the Kerberos realm will be used instead. See also Apache's documentation on AuthName.

If this option is turned Off, mod_auth_vas will perform authorization checks but instead of immediately denying an unauthorized user, other configured authorization modules will be tried.

This option only affects what happens when a user is not authorized. If a user is authorized by mod_auth_vas then they will always be allowed access. The default is On.

See also AuthVasAuthz and Apache's documentation on Authentication, Authorization and Access Control.

Can be set Off to disable mod_auth_vas authorization checks. This might be useful if you want to use both Negotiate (SSO) and Basic (password) authentication, but you want to use another module to do all the authorization checks. For instance this can be used with mod_authz_svn which also has a "Require valid-user" option that bases its authorization decisions on the contents of its AuthzSVNAccessFile. The default is On, meaning mod_auth_vas will provide authorization checks.

See also AuthVasAuthoritative and Apache's documentation on Authentication, Authorization and Access Control. (Since 3.6.0).

Stores delegated credentials in a temporary credential cache file on each request. The default setting is Off. The path to the file is supplied in the _KRB5CCNAME _environment variable. Note that the created file is owned by the web server user and may be inaccessible when SUEXEC is active. It is deleted when the request completes.

This option is deprecated. It is equivalent to AuthVasRemoteUserMap local. Translates usernames in the REMOTE_USER variable to their local names. The default setting is Off. For example the user [email protected] would be translated to username john if the server is in the EXAMPLE.COM realm. (Since mod_auth_vas 3.4.0)

mod_auth_vas provides a built-in error page to clients that try NTLM authentication. The error page contains some hints on browser configuration. It can be overridden in a per-directory context in a similar way to Apache's ErrorDocumentoption, namely by specifying a custom error message or URL. For example:

AuthVasNTLMErrorDocument default
AuthVasNTLMErrorDocument "NTLM not supported" 
AuthVasNTLMErrorDocument /errors/ntlm.html

We recommend configuring your own site-specific document that covers the most likely solutions for your users. Don't forget to make the error page accessible by unauthenticated users. Use a <Files> container with Satisfy any to make exceptions, or store it in an unprotected directory. (Since mod_auth_vas 3.5.0)

Determines how the REMOTE_USER variable should be set. The parameter has the following meaning

• default: the user's Kerberos principal name (sAMAccountName@REALM, eg. [email protected])
• local: A local representation of the user. This means the canonical local username if they belong to the same realm, or the user's full Kerberos principal name for cross-realm users. All authenticated users regardless of Unix-enablement will be localized in this manner.
• ldap-attr attr: Any LDAP attribute fetched from the authenticated user's Active Directory user object. The following attributes are usually resolved from the Authentication Services cache and do not cause LDAP traffic:
  • userPrincipalName
  • sAMAccountName
  • distinguishedName
  • objectSid
  • uidNumber
  • gidNumber Other LDAP attributes will cause LDAP traffic for each request.

(Since mod_auth_vas 3.5.0)

Configures mod_suexec to execute CGI scripts as the remote authenticated user. This option overrides mod_suexec's SuexecUserGroup directive (which can only be specified per-server and not per-directory). If mod_suexec is not loaded, this option has no effect.

The default setting is Off.

This option was added in mod_auth_vas 3.5.0. Prior to that, mod_auth_vas behaved as if this option was On.

Enables/disables use of the Basic authentication fallback when the web browser/client does not understand the reply header WWW-Authenticate: Negotiate. When enabled, a second reply header is sent to the client: WWW-Authenticate: basic. This is sufficient for some browsers to prompt the user for their login name and password, and retry using Basic authentication. If the web server is not using SSL (HTTPS), then the user's password will be visible on the network. This configuration inherits its settings from parent directories. The initial setting is Off.

Enables/disables use of Negotiate authentication (SPNEGO). This configuration inherits its settings from parent directories. The initial setting is On.

Negotiate authentication can be enabled on a subnet-specific basis by specifying a list of subnets instead of On or Off. Subnets are specified in the network/mask notation. The optional /mask can be an IP address or the number-of-bits (CIDR notation). If left out, the mask is assumed to be /32 for IPv4 or /128 for IPv6, that is, exact IP address matching is performed. Multiple subnets may be specified, separated by spaces. Examples of directive use:

AuthVasUseNegotiate On
AuthVasUseNegotiate Off
AuthVasUseNegotiate 10.0.0.0/8 127.0.0.0/255.0.0.0

Examples of valid subnet expressions (IPv6 only available on Apache 2):

127.0.0.1
127.0.0.0/8
127.0.0.0/255.0.0.0
::/128
fe80::/ffff::

The AuthVasUseNegotiate option can be used on machines that serve both internal (Kerberos-capable) and external clients.

Support for subnet-specific Negotiation was added in mod_auth_vas 3.5.0. Prior to that it could only be On or Off.

Causes the authorization phase to succeed if the authenticated user principal name matches any of the given user principal names. An example of a user principal name is [email protected]. Each _upn _may also be a simple username, in which case the default realm (see AuthVasDefaultRealm) will be automatically appended.

Causes the authorization phase to succeed if the authenticated user is a member of any of the Active Directory groups named. Group names containing spaces should be quoted with double quotes.

Causes the authorization phase to succeed if the authenticated user is a member of any of the unix groups. (Since mod_auth_vas 3.3.0)

Causes the authorization phase to succeed if the authenticated user is within any of the given Active Directory containers named by the distinguished name dn. Normally, these are organizational unit names expressed as X.500 distinguished names. For example:

Require container "cn=Employees, dc=example, dc=com"

Causes the authorization phase to succeed if the user was authenticated. Any user that can obtain a ticket for the web service will satisfy this requirement. This allows you to trust all forests and domains that share some kind of trust relationship with the Active Directory server with which your web server host has joined.

See also: AuthType, Require, AuthAuthoritative

It is common to have a single Apache HTTP server serving multiple different sites for different hostnames. It is called virtual hosting and mod_auth_vas is capable of providing access control for virtual hosts.

There are several steps involved in setting up a virtual host to use mod_auth_vas for single sign-on. The following example assumes a web server with the hostname server123.example.com and with a DNS CNAME alias www.example.com. Clients will either access the site as http://server123.example.com/ or as http://www.example.com/. The server only needs to know that it is called server123.example.com, so long as there are servicePrincipalName entries in LDAP matching the names clients will use to access the server.

1. Make sure the HTTP/ service has been created. The simplest way is to run

# /opt/quest/sbin/setup-mod_auth_vas

as root. The setup-mod_auth_vas script will handle creation of the HTTP/ service account in Active Directory and the local keytab. It won't add any SPN aliases.

You could also manually create the service account using the vastool service create command. See the vastool manual page for more information.

Once you have created the HTTP/ service account, check what SPNs are attached to it by using vastool attrs:

$ vastool attrs -s HTTP/server123.example.com servicePrincipalName

servicePrincipalName: HTTP/server123.example.com

A newly-created service will have just one SPN. Keep a record of the existing servicePrincipalName values for the next step.

2. Add more servicePrincipalName attribute values using the vastool setattrs command. You must specify the existing servicePrincipalName values on the command line, otherwise they will be replaced. For example:

$ vastool attrs -s HTTP/server123.example.com servicePrincipalName servicePrincipalName: HTTP/server123.example.com

$ vastool setattrs -sm HTTP/server123.example.com servicePrincipalName \ HTTP/server123.example.com HTTP/www.example.com

Attribute changed: servicePrincipalName

Check that the new SPNs have been correctly updated:

$ vastool attrs -s HTTP/server123.example.com servicePrincipalName

servicePrincipalName: HTTP/www.example.com servicePrincipalName: HTTP/server123.example.com

3. Adjust the Apache configuration files as necessary. This means adding AuthType VAS to enable mod_auth_vas for that <VirtualHost>, and setting access controls with Require directives. mod_auth_vas determines the ServerPrincipalName to use automatically based on the ServerName, which is usually correct. This can be overridden with mod_auth_vas's AuthVasServerPrincipal option. The AuthVasDefaultRealm option is also useful for cross-domain environments.

<VirtualHost *:80>
    ServerName www.example.com
    AuthVasServerPrincipal HTTP/[email protected]
    AuthVasDefaultRealm EXAMPLE.COM
</VirtualHost>

• Verify your configuration by running the checking/verification commands from the previous section (vastool attrs and vastool ktutil)
• If you have recently added the service account, try destroying and re-initialise your credential cache. You may even need to restart your browser or logout and login again.

$ vastool kdestroy

$ vastool kinit

• On unix, test getting the service tickets manually:

$ vastool kinit -S HTTP/server123.example.com
$ vastool kinit -S HTTP/www.example.com
$ vastool klist

• Ensure Apache has read access to the HTTP keytab (/etc/opt/quest/vas/HTTP.keytab). The recommended permissions are 0640 root:apache (where apache is the group the Apache web server runs as)
• Make sure your browser is configured to perform SPNEGO HTTP authentication (see the How-To guide for detailed instructions).

Here is a simple .htaccess that authenticates everyone except anonymous users:

AuthType VAS
Require valid-user

Here is a more complicated example .htaccess:

AuthType VAS
Require user alice bob [email protected]
Require group finance
Require group it
Require group "Domain Admins"
Require container "ou=Sales, dc=example, dc=com"

AuthVasUseBasic on

If the server is joined to the EXAMPLE.COM domain, then the directives above allow the following users to access files in the directory:

• a user with the principal name [email protected]
• a user with the principal name [email protected]
• a user with the principal name [email protected]
• anyone in the Unix-enabled AD groups finance or it
• anyone from the Active Directory group Domain Admins
• anyone from the org-unit OU=Sales,DC=Example,DC=COM

The last line (AuthVasUseBasic on) enables the insecure 'Basic' authentication fallback, and should only be used with HTTPS.

Here are example fragments for httpd.conf:

AuthVasDefaultRealm EXAMPLE2.COM
<Directory "/srv/www/mytestdir">
    AllowOverride All
    AuthType VAS 
</Directory>

<VirtualHost *:80>
    ServerName www.example.com
    AuthVasDefaultRealm EXAMPLE.COM
    AuthVasServerPrincipal HTTP/[email protected]
</VirtualHost>

The first line changes the default realm, used by the Require user directive. The <VirtualHost> section gives an example of how different service keys can be used.

The following are known limitations with mod_auth_vas:

• If the server is unable to obtain a service key on startup (perhaps because of clock skew), then VAS authentication will continue to fail until the web server is restarted.
• Users of older versions of Internet Explorer will be prompted for their password twice, as IE attempts NTLM before falling back to Basic. This can sometimes be reduced by only enabling Negotiate auth for internal networks using the AuthVasUseNegotiate option.