Forms-based Authentication
Exchange 2003 has a snazzy new feature called Forms-based Authentication, which I’ll refer to as FBA. FBA is the new logon security feature for Outlook Web Access (OWA) which is disabled by default in Exchange 2003.
Why use FBA?
There are several security benefits to running FBA:
1. If the session is inactive for a period of time, the session will expire. The only way to gain access again is to re-authenticate. More on this later.
2. Users can no longer click the Remember my password check box in Internet Explorer.
3. Like the session inactivity setting, if you log out, you really log out. The only way to gain access again is to re-authenticate. Previously in Exchange 2000, the user had to complete the logout session by closing the browser window.
Enabling FBA
Enabling FBA is a simple process performed in Exchange System Manager. First, you should note that you need SSL enabled on the target Exchange 2003 server. When you’ve done that:
1. Drill down to your server object in ESM.
2. Under the server object, expand the Protocols container.
3. Under the Protocols container, expand HTTP.
4. Bring up the properties of the Exchange Virtual Server.
5. Click the Settings tab. Here you will see the option to enable FBA.
Here’s what you should see. Note that this option is greyed out on a cluster server because FBA isn’t available on a cluster. You’ll need a front-end server in this scenario.
You will also note an option for compression. I’ll leave that subject for another article. I’ve recently enabled FBA in a front-end back-end scenario here at my office. Note that FBA only needs to be enabled on the front-end server in this scenario.
If you’ve done everything correctly, you should get the following new OWA logon screen. Note that one difference is the fact that your users will now need to enter domainusername when logging on, or they can use their UPN if they prefer. There are ways around the domainusername sequence by modifying the logon.asp page, but these changes will be lost when you perform upgrades or re-installations. I think I’m going to leave this as it is for now – it’s not much for users to learn, after all.
A Choice of Experience
The first option on the FBA screen is for you to select your choice of client experience: Premium or Basic. The Premium client gives you the full new OWA interface, whereas the Basic client gives you a cut-down version with less features. As you might guess, the Basic client is somewhat faster due to it offering less features. Hopefully that may help those still using dial-up connections to their OWA mailbox. If you’ve never seen the basic client, here’s a quick screen shot.
Tweaking Security Options
Also on the opening logon screen are two options surrounding the security of the session: Public or shared computer and Private computer. The Private computer option assumes you are accessing OWA from a trusted computer, such as a computer within your normal office, your home, or perhaps from a partner site where you trust the other workers! The Public or shared computer option is for those situations where you are accessing OWA from a non-trusted network, such as an Internet cafe or other public area.
The difference between the two options is how long the inactivity timeout will last. With the Public or shared computer option, the timeout is 15 minutes by default. With the Private computer option, the timeout is 24 hours by default. These values can be modified via the following registry keys:
HKLMSystemCurrentControlSetServicesMSExchangeWEBOWATrustedClientTimeout
HKLMSystemCurrentControlSetServicesMSExchangeWEBOWAPublicClientTimeout
Both are DWORD values, and are set in minutes. For both, the minimum value is 1 and the maximum value is 43200, which translates to 30 days.
By the way, in case you’re curious, I understand that the timeout will not kick in during long message composition!
What About ISA?
What if you are using ISA in your DMZ and you publish OWA?
When I enabled FBA on my front-end server, I had the following message pop up:
This message indicated that I could offload SSL to the ISA server, or so I thought. Great – no need for an SSL certificate on my front-end server. Wrong! It’s my understanding that you have to have SSL enabled on both the ISA and the front-end server for FBA to work. I did try without SSL on the front-end, all to no avail.
I’m not saying that this is a bad thing. In fact, bridging SSL across the DMZ has to be a good thing as far as I can see. I just found the above message a little misleading. Or maybe it’s just my interpretation, but it’s one to watch for, anyway.
FBA is an extremely useful addition to OWA in Exchange 2003. It gets my vote!
Source: Microsoft Exchange Blog