Some customers (developers) wish to use Basic Authentication when Forms Based Authentication (FBA) is enabled for Outlook Web Access (OWA). If OWA's FBA is enabled, all WebDAV access needs to be FBA authenticated - which means significant changes need to be done to the code - not to mention the testing. The changes and testing will often take several days even for more experienced programmers.
Many software developers run into this issue only when they have deployed the application in a live environment or have released their software - which puts them in a situation where they need at least an interim way around the need to have FBA authentication code written and integrated with their application. One reason that they might not have considered the issue of OWA FBA being enabled is that this feature is not on by default and is enabled by some administrators who what a higher level of security. Most developers will test their code using Windows and Basic Authentication since these settings show under the "exchange" virtual directory in Exchange System Manager (ESM) - while the setting for FBA is in a different place... its under the server-level settings.
Note that OWA's FBA Authentication is an override of the authentication methods normally used by WebDAV - ie those covered by the WebDAV RFC. This work-around has been tested under Exchange 2003. Exchange 2007 has more detailed settings for security and this work-around will thus not apply in this case. Basic and Windows Authentication methods are covered by the WebDAV RFC and are most often used.
If you are going against Exchange 2007, you really need to think hard of why you are using FBA authentication. People have been using FBA authentication for WebDAV against Exchange 2000 and 2003 for one reason - to work around the issue of FBA being turned on for OWA, which casuses WebDAV to only be able to authentication using FBA (unless one of two specific work-arounds are used as noted below). With Exchange 2007, the virual folder and its settings are split-up and seperate for OWA and WebDAV so that one will not affect the other. This means that WebDAV can authenticate using Basic Authentication instead of FBA even if its turned-on for OWA.
Trying to work-around the problem by changing the settings for the "exchange" virtual directory or by just adding a different Virtual Server does not resolve the issue. However, there is a way around this. Since alternat path offers a by-pass to FBA logon, you should be sure to use SSL and limit which IP addresses have access. You should consider possible secuirty risks when using this work-around.
Resolution:=========There is a work-around, however it will defeat FBA authentication. The end-customers should make the decision if this can be done since security may be an issue. In call cases SSL should be enabled with this work-around.
OK, there are two ways to defeat FBA:
Additional NIC: 1) Add a new NIC to the Exchange Server. Give it a static IP. Example: Existing NIC is 65.53.01.01, so the new one will be 65.53.01.02. 2) Configure ESM: A) Under Protocols/HTTP, add a new virtual Server. B) Configure that new virtual server to use the Static IP Address. D) Under the new Virtual Server, add a new virtual directory called "Exchange". 3) In your WebDAV code, you can now use the new IP address. Example: <https://65.53.01.02/exchange/administrator>.
Use a the existing NIC, but use a different port: Note: There are issues with the reliability of using this work-around. 1) Configure ESM: A) Under Protocols/HTTP, add a new virtual Server. B) Configure that new virtual server to use a different port. Example: Port 82. D) Under the new Virtual Server, add a new virtual directory called "Exchange". 3) In your WebDAV code, you can now use the new port. Example: <http://65.53.01.01:82/exchange/administrator>. Note: You may need to restart Exchange and IIS after making these changes.