Novell Home

AppNote: Accelerating Outlook Web Access (OWA) Server 2003 with Forms Based Authentication

Novell Cool Solutions: AppNote
By Bart Andries

Digg This - Slashdot This

Posted: 27 May 2005
 

This article describes how to configure iChain to accelerate and Single-Sign on to Outlook Web Access with Forms Based Authentication Enabled.

By default, OWA uses Basic Authentication to authenticate their users. Information on how to configure iChain with Basic Authentication can be found in Using iChain Single Sign-on with Microsoft Outlook Web Access.

OWA has the possibility to change this to Forms Based Authentication. If the Forms based Authentication is enabled, iChain will use the Form Fill future for SSO. In this article I'll explain how this can be configured.

There can be many reason why people change the authentication method. A good reason for us can be that when there is no synchronization between eDirectory users and Active Directory, you'll probably use Shared Secret to save the credentials in Secret Store. With OLAC the credentials are not saved to Secret Store, while with Form Fill we can have the credentials registered in Secret Store, so you can make users responsible for saving and maintaining their user name and password. I'll explain both procedures for retrieving the credentials, that means with synchronization (username and passwords are the same) and without synchronization (using Shared Secret).

Another reason why administrators change the login method is with Forms Based login you can customize the login page, while with Basic Authentication you'll only have the login Box.

For this article I've used the following environment:

- iChain 2.3 sp2 (192.168.8.23)

- eDirectory 8.7.3 server (192.168.8.30)

- Windows Server 2003 EE with Exchange System 6.5.6944.0 and OWA 2003 (192.168.8.35)

- Novell Linux Desktop with Mozilla Firefox Browser and Internet Explorer 6

Setup of the Outlook Web Access server

  • Make sure that SSL is configured correctly for IIS, install a valid certificate.


  • You enable Forms Based Authentication by going to the Exchange System Manager, Servers, Servername, Protocols, HTTP, right click Exchange Virtual Server and go to properties, enable Forms Based Authentication in the Settings tab. You must use SSL, ignore the warning you get when clicking Apply.


  • Open browser and go to https://192.168.8.35/exchange, you'll no longer see the authentication box but you're redirected to https://192.168.8.35/exchweb/bin/auth/owalogon.asp?url= https://192.168.8.35/exchange&reason=0. The OWA is running in /exchange but when the system cannot find a valid user it will automatically redirect to the login form. If this is the case, then we'll have &reason=0. If the user tries to authenticate, the browser will again redirect to /exchange, if the credentials are not correct, OWA will redirect back to exchweb/bin/auth/owalogon.asp&reason=2, it will then display the message "You could not be logged on to OWA". If a user logs out from OWA, the browser will be redirected to exchweb/bin/auth/owalogon.asp&reason=1, which will display the message "You have logged off from "OWA".

    We can use this functionality very good in Form Fill to detect the status.


click for larger view

  • Another important thing to note is that OWA ask for the domain to be typed (Domain\User name). We should change the script that this will be filled in automatically, so the user only have to provide their user name.

    Remembering and typing the domain name will not only confuse the users, you can then also use the CN value to create the Form Fill Policy.

To have the domain name populated automatically change logon.asp on the IIS server. This file can be found by default in c:\program files\Exchsrvr\exchweb\bin\auth\usa (the usa can be another language code depending on your environment, for more info on this, search the web). Another solution is to put the javascript in the FormFill policy itself instead of changing the server pages.

  1. Look for the following field and change the Text, remove "domain\":

    L_UserName_Text = "Text"

    L_401User_Text = "Text"

    L_RelogonUser_Text = "Text"

  2. Look for line:

    <FORM action="/exchweb/bin/auth/owaauth.dll" method="POST" name="logonForm" 
    autocomplete="off">

    and replace this line with the following (change "your domain" with the name of your domain):

    <script language=javascript> 
    
    <!--
    
    function logonForm_onsubmit()
    
    {
    
    if ((logonForm.username.value.indexOf("@") !=-1) |
     (logonForm.username.value.indexOf("\\") !=-1))
    
    {
    
    return true;
    
    }
    
    logonForm.username.value = "your domain\\" + logonForm.username.value;
    
    return false;
    
    }
    
    -->
    
    </script>
    
    <FORM action="/exchweb/bin/auth/owaauth.dll" method="POST" name="logonForm" 
    autocomplete="off" onsubmit="logonForm_onsubmit()">


  3. Look for line:

    <FORM action="/exchweb/bin/auth/owaauth.dll" method="POST" name="logonForm">

    and replace this line with the following (change "your domain" with the name of your domain):

    <script language=javascript> 
    
    <!--
    
    function logonForm_onsubmit()
    
    {
    
    if ((logonForm.username.value.indexOf("@") !=-1) |
     (logonForm.username.value.indexOf("\\") !=-1))
    
    {
    
    return true;
    
    }
    
    logonForm.username.value = "your domain\\" + logonForm.username.value;
    
    return false;
    
    }
    
    -->
    
    </script>
    
    <FORM action="/exchweb/bin/auth/owaauth.dll" method="POST" name="logonForm" 
    autocomplete="off" onsubmit="logonForm_onsubmit()">

Configuring the iChain Accelerator

  • Configure this accelerator like any other


  • Make sure to have Forward host name sent by browser to the web servers checked


  • No need to enable "Forward authentication information to web server" in Authentication options


  • Enable secure exchange and enable secure access between the iChain Proxy and the Origin Web Server in Secure Exchange Options.


  • Install the OWA trusted root certificate in the trusted root container specified by the iChain Service Object (see online documentation how to do this).


  • Don't forget to configure the ACL.


  • test the accelerator (open browser to https://mail.home.ba/exchange)


click for larger view

Enable and configure the Form Fill Policy

The first policies you should have in the list are policies to control and policies to detect the status. Put these policies before the actual login policy.

This policy will redirect the browser to /exchange when accessing the root of the web server (can also be an index.html on the server that takes care of this).

<urlPolicy>
<name>MailRoot</name>
<url>mail.home.ba/</url>
<actions>
<redirect>https://mail.home.ba/exchange</redirect>
</actions>
</urlPolicy>

If a user press logout in OWA, they are redirected to the owalogon.asp?reason=1, when we don't configure a policy here, Form Fill will detect this page as the login page and re-authenticate the user.

<urlPolicy><name>MailLogout</name>
<url>mail.home.ba/exchweb/bin/auth/owalogon.asp</url>
<cgiCriteria>reason=1</cgiCriteria>
<actions>
<redirect>https://mail.home.ba/cmd/ICSLogout</redirect>
</actions>
</urlPolicy>

The Form Fill Policy with Synchronization between eDirectory and active Directory

These policies are only working when both the user name and the password are the same in both directories.

When the wrong password or the wrong user name is put in the form, (this should never occur if you use IDM), OWA will redirect the browser to owalogon.asp?reason=2

The action that can be done is for example redirect the browser to an error page that ask the user to try again or contact helpdesk. What I'll do here is leave the actions tag empty,

so users see the login page and they still can try to log in (maybe with other credentials).

<urlPolicy>
<name>MailWrongPW</name>
<url>mail.home.ba/exchweb/bin/auth/owalogon.asp</url>
<cgiCriteria>reason=2</cgiCriteria>
<actions>
</actions>
</urlPolicy>

This is the actual Form Fill Policy to authenticate the user. For the user name we'll look up the CN of the user via LDAP (~cn) and we use the same password as the one used to authenticate to iChain (~password). In case we don't use the javascript to populate the domain name we can create an extra attribute (ex ntloginname) which has "domain\cn" as value, ~cn needs to be replaced with ~ntloginname and we can skip the javascript tags.

We need to copy the javascript function "logonForm_onsubmit()". We do this by putting this between the javaScript tags, if we don't do this, the function will not be available and the domain name will not be populated automatically. We also need to tell iChain to execute the script before posting the form to the web server, that's why the scriptForPost tag is used.

<urlPolicy><name>MailLogin</name>
<url>mail.home.ba/exchweb/bin/auth/owalogon.asp</url>
<javaScript>function logonForm_onsubmit()</javaScript>
<scriptForPost></scriptForPost>
<actions>
<fill>
<input name="username"
value="~cn">
<input name="password"
value="~password">
</fill>
<post/>
</actions>
</urlPolicy>

The Form Fill Policy without Synchronization between eDirectory and active Directory, using Shared Secrets

The Wrong password detection is very important here, when a user types in the wrong credentials, iChain should detect this, otherwise there will be an endless loop trying to connect with the wrong password. When the page is detected (owalogon.asp&reason=2), we'll delete the stored credentials for ADAccount, wich is specified in policy MailLogin. After the credentials are removed, we'll redirect back to the login page.

<urlPolicy>
<name>MailWrongPW</name>
<url>mail.home.ba/exchweb/bin/auth/owalogon.asp</url>
<cgiCriteria>reason=2</cgiCriteria>
<actions>
<deleteRemembered>MailLogin</deleteRemembered>
<redirect> https://mail.home.ba/exchange</redirect> </actions> </urlPolicy>

This is the actual Form Fill Policy to authenticate the user. We need to copy the javascript function "logonForm_onsubmit()". We do this by putting this between the javaScript tags, if we don't do this, the function will not be available and the domain name will not be populated automatically. We also need to tell iChain to execute the script before posting the form to the web server, that's why the scriptForPost tag is used.

With the sharedSecret tags we tell iChain to store and search the credentials in SecretStore. The secretName will specify the name that will be used to store this Credential set (SS_CredSet) in SecretStore, if we don't specify this, the name of the CredSet will be MailLogin. Also optional is the ff_shared_name field, this will specify the name used by iChain to write the value to the CredSet. This is needed if this CredSet will be shared with other accelerators or with SecureLogin.

<urlPolicy><name>MailLogin</name>
<url>mail.home.ba/exchweb/bin/auth/owalogon.asp</url>
<javaScript>function
logonForm_onsubmit()</javaScript>
<scriptForPost></scriptForPost>
<sharedSecret> 

<secretName>ADAccount</secretName>
</sharedSecret> <actions> <fill> <input name="username" value="~" ff_shared_name= "ADUsername"> <input name="password" value="~" ff_shared_name= "ADPassword"> </fill> <post/> </actions> </urlPolicy>

Conclusion

This article describes two different scenarios on how you can configure iChain to accelerate and single sign on OWA 2003.

There are other possibilities or configurations possible, but they will most probably be very similar to the ones described above.

For iChain and SecretStore, the online documentation can be found at www.novell.com/documentation for more features, details and explanation.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell