View source for Eliminating Web Server Failures when Single Sign-On Is Used

{| border=2
| '''This document is company-confidential and should not be distributed externally as a whole'''
|}

{{Template:Basic Cover
|title=Eliminating Web Server Failures when Single Sign-On Is Used
|type=FAQ
|htl=Y
}}

{{Template:Basic Status
|status=Published
|version=1.0
|authors=HTL QA
|applicableto=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):

# The customer accesses the SelfService module.
# 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.
#  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.
#  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):

# 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.
# Download the file [http://wikiFiles/Devwiki/Downloads/Apache-IIS.zip Apache-IIS.zip] and unzip it to reveal two .asp and two .php files.
# Copy the file auth1.asp to the IIS website root and open it in a text editor.
# Find the URL string <code><nowiki>http://SERVER/SELFSERVICE1/index.php</nowiki></code>. Change <code>SERVER</code> to the name or IP address of the installed Supportworks server, and change <code>SELFSERVICE1</code> to the name of the first SelfService instance.
# Copy the file auth2.asp to the IIS website root and open it in a text editor.
# Find the URL string <code><nowiki>http://SERVER/SELFSERVICE2/index.php</nowiki></code>. Change <code>SERVER</code> to the name or IP address of the installed Supportworks server, and change <code>SELFSERVICE2</code> to the name of the second SelfService instance.
#  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.
# Open this new index.php file in a text editor and find the URL string <code><nowiki>http://IIS_SERVER/auth1.asp</nowiki></code>. Change <code>IIS_SERVER</code> to the name or IP address of the installed IIS.
#  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.
# Open this new index.php file in a text editor and find the URL string <code><nowiki>http://IIS_SERVER/auth2.asp</nowiki></code>. Change <code>IIS_SERVER</code> to the name or IP address of the installed IIS.
#  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:
#:<pre><Location "/sw/selfservice">
#:AuthType SSPI
#:AuthName "INTERNAL"
#:SSPIAuth On
#:SSPIAuthoritative On
#:require valid-user
#:</Location></pre>
#: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.
# Restart the SwHttpServer service.

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