Sunday, January 4, 2009

OWA authentication and its affect on OWA functionality

You’re probably aware of that you can configure different authentication methods for OWA (Outlook Web Access). But different authentication mechanisms for OWA alter some behavior in OWA.
When you install an Exchange 2007 CAS, OWA is configured with form based authentication (FBA). This gives the end user a HTML form to fill in with username, password and also some configuration on OWA’s behavior.

The checkbox “Use Outlook Web Access Light” gives a light version of OWA with no activeX controls or other IE only features. This is of course a less feature rich version of OWA than if you use IE. Advantage is that is consumes less bytes on the wire and is therefore suitable if you are on a low bandwidth connection. OWA light is also default selected if you use a non IE and cannot be changed.

Now to the interesting part: selection between Public and private computer.
Clicking on the show explanation link doesn’t give any good clues.

This is a public or shared computer. Select this option if you use Outlook Web Access on a public computer. Be sure to log off when you have finished using Outlook Web Access and close all windows to end your session.

This is a private computer. Select this option if you are the only person who uses this computer. Your server will allow a longer period of inactivity before logging you off.

OWA with forms based authentication saves information in a cookie on the client computer. One thing that is stored in the cookie is the idle time before the user is automatically logged off. By selecting Public computer gives the user an idle period of 15 minutes before the cookie expires and the user is logged off. The timeout period for Private computer is 8 hours. CAS is using several encryption keys and cycle them every half of the time out interval so the actual timeout is between 15 to 22.5 minutes and 8 to 12 hours for private computers.

Timeout values can be changed and is configured with registry values in the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA

Value names are “PublicTimeout” and “PrivateTimeout”, both are DWORD and numbers are in minutes.

some usefull links on the subject.

Other behavior that is dependent on the Public/Private computer selection is “File and Data Access”.
With “File and Data access” the administrator can configure what servers and file types are accessible and how users interact with files by using Allow, Block, or Force save options.This gives the administrator a very good control on how files are accessed through OWA. The good part is that all configurations regarding file access in OWA is separate for public and private computer.
This gives the administrator the ability to have different OWA behavior dependent on what user select during OWA logon. for example a user logon with public computer and tries to download a document from a file server, this is blocked by OWA, but if user logon with a private computer option selected the file is successfully downloaded to the client.

Options that can be configured are: access to windows file shares, access to sharepoint document libraries, webready document viewing, direct file access.
You can also set what file types are allowed and what types are not. Very handy and extremely useful, the only hard part is to make users select the correct option, but I guess that is up to information and education.

But what if you don’t want to use Forms Based Authentication?
There are three other standard authentication mechanisms to choose from: Basic, Windows and Digest authentication.
(Configuring Standard Authentication Methods for Outlook Web Access

With Basic authentication you will always get prompted for username and password.

Once logged on, OWA treats this session as private computer regarding to attachment and data file access, but it will not use a cookie on the client to timeout the session and credentials will be cached by the browser until it’s closed or user click on the Log Off link. With the browser caching users credentials a user can use OWA and then point there browser towards another website and then hit back again and enter OWA without typing in any credentials, so it’s important to educate users about closing the browser or hit the Log Off link to secure access to there’s mailbox.

With Digest Authentication you get almost the same behavior as with basic authentication, except that OWA doesn’t know your credentials and cannot authenticate when you try to open a fileshare or a sharepoint document library. There is an exception when this work anyway and that is if you install CAS and Mailbox role on the same server.

With windows integrated authentication you get the same behavior as with Digest authentication except that if your browser is configured to use windows integrated for your CAS server website you will get automatically logged on with the same user as you’re logged on to windows with. This gives user a seamless access to OWA with typing in credentials. Windows Integrated uses the most secure authentication scheme but hopefully you’re forcing use of SSL on CAS website so this should be no problem to use other authentication than windows integrated.

So be careful when you set your authentication scheme on your CAS, more things change than you first might realize.

If you also have an ISA in front of your CAS, the possibilities and complexity raises, but that’s another story I save for later.

No comments:

Post a Comment