Publishing Exchange 2007 OWA is one of the simpler Exchange 2007 services and is quite similar to traditional publishing for Exchange 2003. This area is also covered in some detail on the TechNet site here. Although OWA is covered in some detail by Microsoft, I had struggled to find information on the amendments that need to be made to allow the OWA Document Access feature to function correctly when the Client Access Server is published with ISA Server 2006. Based on several deployments, I had found that the Document Access feature did not work correctly and I was only able to access local shares on the Exchange CAS itself - this is not very useful unless you decided to make your CAS a File Server too! :)
The Document Access feature of OWA allows users to connect to Windows File Shares and Windows SharePoint Services via the OWA interface. It also allows users to open documents that are referenced or 'linked to' in emails that are read using the OWA interface. This seems like a pretty cool feature to me and hence I was keen to try and resolve any issues to enable access for my own production environment, in addition to providing the solution to customers.
The blog entry is focused on how to configure ISA and Active Directory to enable the Document Access feature and doesn't provide in-depth information on the actual Document Access feature of Exchange 2007, or how it should be configured within the Exchange 2007 Management Console. A few key elements are covered, but the Exchange 2007 documentation available here should be used for a more detailed view.
For completeness, I have also included a walkthrough for publishing OWA as this makes things flow a little better. I am going to reuse my example architecture from the previous Outlook Anywhere article. This is shown below:
The only difference with this model is the inclusion of a file server called FILE01; in all other aspects the environment is still covered by the summary information provided in my previous blog posted here. This file server contains shares that we would like to access via OWA. I have used a file server for this example (as this is the simplest example) and from what I can tell negates the need for complicated Kerberos delegation configuration in the same way as is needed for Windows SharePoint Services. I have yet to test Document Access to SharePoint, as I would normally provide access to these environments using some form of independent SharePoint publishing, as opposed to using the OWA interface.
The key to getting Document Access working (from what I could tell anyhow!) is to think about how the communication process works and then consider authentication during this process. Based upon trying to achieve the best security solution possible and normally having to cater for co-existence with Exchange 2003, I have always used Negotiate (Kerberos/NTLM) delegation as described in Appendix D of the Publishing Exchange 2007 with ISA Server 2006 document available here. I have yet to test whether Document Access works correctly when using Basic delegation, I would guess not, but I am not really sure in all honesty. The first thing that got me thinking about the approach detailed in this blog post was the following statement from Appendix D of the above document "To take advantage of the new Exchange 2007 features that require Negotiate authentication delegation...". Turning this around, it seems to imply that you should be using Negotiate authentication if you want to enable advanced Exchange 2007 features, maybe like Document Access for example???. Negotiate is actually a great choice for delegation, as it basically provides a fallback to NTLM if the necessary Kerberos configuration has not been completed on the published servers. However, if you get everything right with the Kerberos configuration on published servers, I see no reason why you couldn't actually change this to specifically utilise Kerberos constrained delegation (as opposed to Negotiate) if you are confident that fallback to NTLM is not actually required.
Please Note: It is important to understand that we are talking about delegation here and not authentication; ISA Server is not currently able to provide fallback to NTLM for authentication, only during the delegation process.
So, back to thinking about communication and authentication flows! The key difference with Document Access is that we are now involving a third (or maybe more) entity into the environment that is not actually being published by ISA Server. Instead, the Client Access Server is connecting to the file server, on the users behalf, in order to render the file share view and contents within the OWA interface. This is a common scenario and is often called a 'double hop problem' which is covered well here by Arunjeet Singh (Knowledgecast). Hence I figured that if I wanted to get Document Access to work, I would need the Client Access Server to be able to not only validate my credentials, but also be able to forward them onto the file server so that it was able to determine what access rights to shares/files I should be given, if any. As discussed in my previous blog post for Outlook Anywhere, this is something that the NTLM authentication scheme just cannot do and the Exchange CAS essentially becomes the 'man-in-the-middle' even if ISA Server is correctly configured to utilise Kerberos constrained delegation. With all this information in hand, I now realised that solving the problem involved ensuring that the Exchange CAS could delegate my credentials to the file server using Kerberos, in exactly the same way as ISA Server does.
So, hopefully we are all still on the same page :) and the following diagram shows an overview of the delegation model that needs to be defined:
I have already covered configuring ISA Server to be trusted for delegation to the Exchange CAS in my previous blog post here, so we now simply need to extend this model and configure the Exchange CAS to be trusted for delegation to the file server. A key element of successfully using KCD is ensuring that the correct Service Principal Names (SPNs) are defined and used. Rather than creating new SPNs, it makes sense to me to utilise the built-in SPNs that are created by default. Hence, this example makes use of the default SPN created for the file server. As we are accessing file services on the file server, this means that we are specifically talking about the CIFS SPN. In our example solution (as shown above) the default system generated SPN for the file server is cifs/file01.internal.msfirewall.org.uk so we will use this in our configuration.
This can be achieved using Active Directory Users and Computers. Firstly, find the computer object for the Exchange CAS and select Properties. Click on the Delegation tab. Select the option for Trust this computer for delegation to specified service only, then select Use any authentication protocol. Finally, click the Add button and browse for the file server computer object (FILE01 in our example). On the list of available SPNs defined for FILE01, select the entry for cifs/file01.
Once configured, you should see the following:
If you tick the Expanded option, you will actually see that both NetBIOS and FQDN are listed as shown below:
So, with the above configuration, we have configured the Exchange CAS to be trusted for delegation of credentials, but only to the file server, and only for the CIFS service, hence the term constrained.
Please Note: Active Directory will need to be running at Windows 2003 native functional level (or greater) in order to see the Delegation tab. Also, all computer objects will need to be in the same Active Directory domain for KCD to function (even with ISA Server 2006 SP1).
With delegation in place, we now need to ensure that the Document Access feature has been enabled on the Exchange CAS. As I discussed previously, this is not a complete guide, but covers the basics of enabling Document Access for Remote File Servers.
Using the Exchange Management Console, enable Document Access; this is available from the Properties page of the Outlook Web Access tab on the Server Configuration, Client Access node.
From the OWA (Default Web Site) page, select the Authentication tab and ensure that Integrated Windows authentication option is enabled.
Select the Public Computer File Access tab
Ensure the Enable direct file access option is enabled if you wish to enable access from public computers. This option is based upon the user selection chosen on the HTML form during the Forms Based Authentication logon process.
Ensure the Windows File Shares option is enabled as a minimum for our example.
Select the Private Computer File Access tab
Ensure the Enable direct file access option is enabled if you wish to enable access from private computers. This option is based upon the user selection chosen on the HTML form during the Forms Based Authentication logon process.
Ensure the Windows File Shares option is enabled as a minimum for our example.
Select the Remote File Servers tab
Click the Allow List button and enter the host names of required remote file servers. In our example this is just FILE01. Click OK to save.
Please Note: I would recommend that you ensure that the Unknown Servers option is configured for Block mode as a security measure. This ensures that only servers specifically defined within the allow list will be accessible.
Click the Configure button and enter the domain suffix for internal sites. In our example this is internal.msfirewall.org.uk. Click OK to save.
The Exchange 2007 CAS is now configured, Active Directory delegation is enabled and hopefully we have an understanding of the solution approach and proposed authentication elements. So, lets start configuring ISA!
From within the ISA Server Management Console, select the Publish Exchange Web Client Access wizard.
Enter a suitable publishing rule name like Publish Exchange 2007 OWA
Define the Exchange Version as Exchange Server 2007 and select Outlook Web Access.
Select Publish a single web site or load balancer
Define the Internal site name as email.msfirewall.org.uk. Select the Use computer name or IP address to connect to the published server option and enter cas01.internal.msfirewall.org.uk into the Computer name or IP address field.
Enter email.msfirewall.org.uk into the public name field.
On the Select Web Listener page, click New and define a suitable name for the listener like Exchange Listener (Internet FBA).
Select Require SSL secured connections with clients
Enable the External network listener and click on Select IP Addresses to define a unique IP address for the listener.
Click Select Certificate and select the appropriate certificate from the list
Please Note: This step assumes that you have already purchased and installed certificates into the Local Computer certificate store on the ISA Server.
On the Authentication Settings page, select HTML Form Authentication and Windows (Active Directory).
Click Next and then Finish.
You should now see the rule defined in the firewall policy.
However some of these directories are only required for legacy users with Exchange 2003 mailboxes. If you have a pure Exchange 2007 environment, you only actually need the /OWA/* entry.
Please Note: If you need to provide a co-existence environment for both Exchange 2003 and Exchange 2007 users, you should follow the guidance provided in Appendix D of the Publishing Exchange 2007 with ISA Server 2006 article available from Microsoft here.
Click on the link for Open Location
Enter a UNC path to the required share as shown in the following example.
You should now be able to see the share contents rendered in the right hand pane and you now have access to internal documents via OWA!
With successful access to a single file server, you should now be able to extend the solution to support additional file servers as required. Assuming internal SharePoint servers are configured to support Kerberos authentication, it should also be possible to access these resources in the same way.