How-To Docs

A guide for setting up web site single sign-on with Quest Authentication Services

This guide will show you how to set up Internet Explorer, Firefox and the Apache HTTP server so that users in Active Directory are authenticated to resources without passwords. This guide covers the steps needed to install Apache, the Quest Authentication Services module, how to configure the module to protect a URL and how to configure web browsers to authenticate properly.

Installing the Apache web server

Show specific instructions for:

This section assumes you don't already have the Apache web server installed. If you know you already have Apache installed, please skip to the next section on installling the Apache module.

Some systems come with Apache already installed, or available as a package on their the installation media. If your system doesn't have the Apache web server (also known as httpd), then the first step is to download and install it.

For AIX platforms, you can download

For HP-UX, you can download and install Apache

For Sun Solaris systems, please refer to

For SuSE Linux, the steps are:

  1. Invoke the YaST administration tool, either from the menu system, or with this command:
    # yast2
  2. Choose the Software Management task (previously called Install and Remove Software)

    Starting the software manager with YaST on SuSE Linux 10.0
  3. Select the Selections filter
  4. Enable the Simple Web Server with Apache selection then click Accept:

    Selecting the Apache packages on SuSE Linux 10.0

For Red Hat Linux, access the package manager and enable the Web Server package:


Accessing the package manager on Red Hat 4.0


Adding the web server package on Red Hat 4.0

Installing the Quest Authentication Services module for Apache

Our mod_auth_vas module allows Apache to perform the server side of web user authentication. This module should be installed after the web server. These instructions assume you have Quest Authentication Services installed on the same server as the Apache web server runs.

From a package

SuSE linux RPM packages of mod_auth_vas can be downloaded from the mod_auth_vas page, and installed with YaST at a command prompt:

# yast2 -i quest-mav-ap22-3.6.8.i386.rpm

Red Hat Linux packages of mod_auth_vas can be downloaded from the mod_auth_vas page, and installed with RPM using the command:

# rpm -i quest-mav-http22-3.6.8.i386.rpm

Please note that packages of mod_auth_vas are not available for all platforms/apache combinations. For these platforms, please see the next section on compiling the module from source form.

From source

For platforms where a binary package is unavailable or fails to install, you must compile the module from source.

The mod_auth_vas module can be compiled from source for most platforms. Start by downloading the source archive from the mod_auth_vas website.

You will need

For SuSE Linux, the Apache developer tools are installed by running

# yast2 -i apache2-devel

For Red Hat Linux systems, the Apache developer tools are named httpd-devel and can be found on the installation CDs.

Instructions for building the mod_auth_vas module:

  1. Extract the source archive, using this command:
    $ gunzip -c mod_auth_vas-3.6.8.tar.gz | tar xf -
    This will create a directory called mod_auth_vas-3.6.8.
  2. Invoke the configure script, like so
    $ cd mod_auth_vas-3.6.8
    $ ./configure

    The configure script checks that the module can be built. It should complete successfully with a line such as

    config.status: creating Makefile

    (Any errors creating files in the test subdirectory can be ignored.)

  3. Start the module compile (requires GNU make)
    $ make
  4. Install the module (as root)
    # make install APXS_ACTIVATE=-a

    The APXS_ACTIVATE=-a option causes the module to be enabled by adding it into the Apache configuration file (usually /etc/apache2/httpd.conf or /etc/httpd/httpd.conf). The line added will appear similar to this:

    LoadModule auth_vas_module /usr/lib/apache2/modules/mod_auth_vas.so
  5. Create an HTTP service account and set file permissions (as root):
    # sh ./setup-mod_auth_vas
  6. Restart the web server.

    For SuSE Linux, use one of these commands:

    # /etc/init.d/apache restart
    # /etc/init.d/apache2 restart

    For Red Hat Linux, use

    # /etc/init.d/httpd restart

At this point, you will have a web server with the mod_auth_vas module loaded, but with no specific directories being protected.

Configuring the web server for single sign-on

This section provides a step-by-step guide for setting up a simple protected directory. More detailed instructions are available from the mod_auth_vas installation guide. When complete, the web server's public directory structure will look like this:

   DocumentRoot/
       protected/
           .htaccess
           hello.html

You will need to find out where your web server's DocumentRoot directory is. This can be determined by looking for the DocumentRoot directive in the httpd.conf configuration file.

  1. Create the protected directory
    # cd DocumentRoot
    # mkdir protected
    # cd protected
  2. Create a text file called .htaccess inside the protected directory, and enter the following lines:
    <Files "*">
        AuthType VAS
        Require valid-user
    </Files>
    

    The valid-user directive refers to any user with an Active Directory account.

  3. Create the hello.html file in the directory, and place in it a simple greeting:
    Hello, world!

There will be no need to restart the web server after making these changes. The web server will need to be able to access the protected/ directory and the hello.html file. Use the chmod and/or chown commands to make sure it can.

At this point, you should have a running web server on a Quest Authentication Services-enabled host with access to the /protected resource requiring authentication.

Configuring the web browser for single sign-on

This section explains how to configure your Unix and Windows web browsers to use Windows Integrated Authentication to automatically authenticated to the web browser. The first section is on the Mozilla-based browsers, and the second section is on Internet Explorer.

Firefox, Mozilla, Netscape, and Epiphany

This section assumes you have one of the Mozilla-based browsers, such as Firefox, Mozilla, Netscape or Epiphany.

  1. Navigate the browser to the RC Mozilla configuration site. This site allows the user to enable authentication features in the browser.

    Alternatively, you can type in the URL about:config and manually change the browser's "Negotiate auth" preferences.


    Manual configuration with Linux Firefox 1.5 and 2.0


    Manual configuration with Windows Firefox 1.5 and 2.0

    The meaning of the Mozilla preferences are as follows:

    network.negotiate-auth.gsslib
    The GSSAPI library to use, not required on Windows, and generally set to /opt/quest/lib/libvas-gssapi.so (or /opt/quest/lib64/libvas-gssapi.so on x86-64 systems) on Unix/Linux.
    network.negotiate-auth.using-native-gsslib
    Whether to use the browser's GSSAPI implementation. Should be disabled on Unix/Linux, and enabled (default) on Windows.
    network.negotiate-auth.trusted-uris
    URIs to attempt GSSAPI Negotiate authentication with. Set this to a comma-separated list of sites to automatically authenticate to, for example https://, vintela.com will enable Negotiate authentication for all secure servers and all sites in the vintela.com domain. Note that the URI used to match this setting is the exact requested URI (as shown in the address bar) — not necessarily the fully-qualified hostname.
    network.negotiate-auth.delegation-uris
    URIs to delegate credentials to. Same syntax as above.

Internet Explorer

Internet Explorer 6.0 will, by default, not attempt to use the Kerberos protocol to authenticate to any site on Windows 2000. Microsoft provides instructions for enabling Kerberos authentication in Internet Explorer (KB 299838). The article also includes instructions for administrators wanting to enable Kerberos authentication in Internet Explorer domain-wide. There is a separate article on adding sites to the local intranet or trusted sites zone. The following instructions are equivalent.

  1. Your mod_auth_vas-protected web sites should show up as being in the 'Local Intranet' zone or in the 'Trusted Sites' zone, indicated by an icon at the bottom right of the browser window when the site is being viewed.

    If the browser is not treating the web server as trusted, follow these steps. Open the Internet Options control panel from Start → Settings → Control Panel → Internet Options (or Tools → Internet Options in IE). Go to the Security tab and select Trusted sites. Click the Sites button and add the hostnames (or domain names) of the web servers. The figure below shows an entire domain (vintela.com) being added. It is safe (and recommended) to untick the option labeled Require server verification (https:) for all sites in this zone.


    Adding a web site in the Trusted sites dialog

    Click the Add button after entering in each name.

  2. The 'Trusted Sites' zone (or the 'Local Intranet' zone) must also be configured for automatic login. This is the default, but it may have been changed.

    To verify, click the Custom level... button in the Security tab and find the "Automatic logon with current username and password" option located near the end of the list.

    If it is already enabled, make no changes and choose Cancel. Otherwise, enable it and click OK.

    In Windows Vista IE7 there is an option called Protected Mode. Protected Mode does not affect Negotiate authentication with mod_auth_vas.


    Verifying "Automatic logon with current username and password" option
  3. Verify that Integrated Windows Authentication is active by visiting the Advanced tab of the Internet Options panel. The checkbox is found near the very end of the list as shown in the figure below. Changing this option requires you to restart the browser (close all its windows) to take effect. This option does not exist in Windows Vista IE7 - integrated authentication is always available.

    Verifying that "Integrated Windows Authentication" is enabled.

Konqueror

No special configuration is required for the Konqueror web browser — it will perform Negotiate authentication for all sites in the same domain.

Safari

No configuration is necessary for Safari — it automatically performs Negotiate authentication for users with Kerberos credentials.

Google Chrome

Chrome must be started with the following command line argument: --auth-server-whitelist="*.domain.com" With "domain.com" being the domain where you wish to perform single sign-on.

— Ted Percival and David Leonard, 2006 : Updated by Jayson Hurst for Mod Auth Vas4, 2013