Eliminating Web Server Failures when Single Sign-On Is Used

This document is company-confidential and should not be distributed externally as a whole

Status:	Published
Version:	1.0
Authors:	HTL QA
Applies to:	Core Services

Eliminating Apache Server Failures when Single Sign-On Is Used

Introduction

There is a fundamental problem with the gradual accumulation of Windows Kerberos authentication packets/tokens, within the SSPI process, that causes the Apache server to hang from time to time when the Windows domain contains a large number of user groups.

The workaround to this problem consists of implementing changes to the single sign-on process that will involve redirecting the SSPI authentication to Microsoft's Web server, IIS.

How the New Process Will Work

The changes to be made will force the process to work as follows (using SelfService as an example):

1. The customer accesses the SelfService module.
2. The modified index page on the Apache server checks whether there is a valid user (domain/user ID). As there will never be a valid user due to SSPI now being disabled on Apache, authentication is redirected to the index page on IIS.
3. IIS tries to confirm the validity of the domain user and, if successful, returns control to the SelfService module. If it is not successful, the user is presented with an IIS 401 error.
4. The modified index page then continues to process as normal and checks whether the Active Directory user is a registered Supportworks analyst. If so, the user is taken to the SelfService home page. If not, the user is presented with an Invalid User message and is directed to the login page of the SelfService Module.

The Changes to Be Implemented

The steps to implement the workaround are as follows (using two instances of SelfService as an example):

1. Configure an IIS website with single sign-on, so that on accessing the page, the user is identified without the need to enter their user name and password.
2. Download the file Apache-IIS.zip and unzip it to reveal two .asp and two .php files.
3. Copy the file auth1.asp to the IIS website root and open it in a text editor.
4. Find the URL string http://SERVER/SELFSERVICE1/index.php. Change SERVER to the name or IP address of the installed Supportworks server, and change SELFSERVICE1 to the name of the first SelfService instance.
5. Copy the file auth2.asp to the IIS website root and open it in a text editor.
6. Find the URL string http://SERVER/SELFSERVICE2/index.php. Change SERVER to the name or IP address of the installed Supportworks server, and change SELFSERVICE2 to the name of the second SelfService instance.
7. Copy the file index1.php to the root of the first SelfService instance, whose default path would be C:\Program Files\Hornbill\Supportworks Server\html\_selfservice\SELFSERVICE1\. Rename the existing index.php file as something else and then rename the index1.php file as index.php.
8. Open this new index.php file in a text editor and find the URL string http://IIS_SERVER/auth1.asp. Change IIS_SERVER to the name or IP address of the installed IIS.
9. Copy the file index2.php to the root of the second SelfService instance, whose default path would be C:\Program Files\Hornbill\Supportworks Server\html\_selfservice\SELFSERVICE2\. Rename the existing index.php file as something else and then rename the index2.php file as index.php.
10. Open this new index.php file in a text editor and find the URL string http://IIS_SERVER/auth2.asp. Change IIS_SERVER to the name or IP address of the installed IIS.
11. Open the Apache configuration file httpd.conf (located by default in C:\Program Files\Hornbill\Core Services\SwHttpServer\conf\) in a text editor and remove the SSPI location settings. Typically, they would be in a section such as this:

    <Location "/sw/selfservice">

    AuthType SSPI

    AuthName "INTERNAL"

    SSPIAuth On

    SSPIAuthoritative On

    require valid-user

    </Location>

    If Virtual Hosts are defined in the configuration file, each of these would have a section similar to the above, which you would also need to remove.

12. Restart the SwHttpServer service.

Once you have completed this procedure, SelfService users will be authenticated using IIS.