Friday, 1 August 2008

Publishing Exchange 2007 Services with ISA Server 2006 – Creating the Publishing Rule for Outlook Web Access Including Document Access

Moving on from my existing article which covered Outlook Anywhere, this blog post covers Exchange 2007 Outlook Web Access (OWA) specifically including the Document Access feature.

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



Select Use SSL to connect to the published Web server or server farm



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.





With the web listener created, click Next to continue.



On the Authentication Delegation page, select Negotiate (Kerberos/NTLM) and enter http/cas01.internal.msfirewall.org.uk into the SPN field.




Click Next



Click Finish to complete the rule wizard.





You should now see the rule defined in the firewall policy.



To make life a little easier for users, I generally enable HTTP to HTTPS redirection on the HTTPS listeners.



I also tend to enforce 128-bit (high) encryption for HTTPS traffic.


Looking at the Paths tab, we can clearly see all of the virtual directories used by Exchange OWA.




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.

So, if we now login to our published OWA interface and click on the Documents button in the bottom left pane.



Click on the link for Open Location



Enter a UNC path to the required share as shown in the following example.

Please Note: For future reference, you may like to add the location to your favourites to negate having to enter UNC paths each time you need them.

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.

Download this Article

7 comments:

  1. Thanks for this great post!
    Actually I have one unresolved problem. When a user opens a file share in OWA and navigates up (or directly opens \\FILE01 e.g.) he sees all file shares available on this server (including the hidden ones). Is it possible to hide specific file shares depending on the user accessing a fileserver through OWA?
    This would be really great!

    -
    Tobi

    ReplyDelete
  2. >> Tobi

    Hi - yeah I have noticed the same thing. I am not sure if it is possible to hide anything and from what I have seen, you just need to rely on NTFS permissions to prevent access even though they can be viewed. I am guessing it is not possible for CAS to render based upon some sort of limitation. I will have a look into it....

    ReplyDelete
  3. Thanks for one more very usefull article,Jason.

    ReplyDelete
  4. Jason,

    Great post and I'm trying to find a way how this can be applied favourably in a distributed environment(read:global) where users logging in centrally via CAS can access their own localised data. While I could delegate 10 or 20 file servers via KCD for CIFS, that's pretty meaningless, as OWA has no concept of a home server.

    It'd be nice if one could equate access on a personal level where users document access can be pegged to the users home file server, e.g. their home directory.

    Will delegation work with DFS?

    Regards,
    Mylo

    ReplyDelete
  5. >>Mylo

    Hi - I'm not sure OWA Document Access is your best solution. Maybe something like IAG and the File Access feature may be a better solution for this?

    With KCD configured, if the user "knows" their home server they should be able to access it using the server\share format, but this is admittedly far from ideal.

    Interesting question re KCD and DFS, but don't know the answer, sorry!

    Cheers

    JJ

    ReplyDelete
  6. thanks for the great article.

    best regards

    ReplyDelete
  7. Hi,

    Thanks for the nice article.

    i have problem with ssl listener.

    i cannot use owa listener with outlook anywhere listener at the same time.


    ---------------------------
    Microsoft Internet Security and Acceleration Server 2006
    ---------------------------
    A Web listener specifying the same port and similar IP addresses is already used by rule "Exchange OWA (Negotiate)". The port and IP addresses specified in a Web listener cannot overlap with the IP addresses and ports specified in another Web listener already used in a different rule.
    ---------------------------
    OK
    ---------------------------

    ReplyDelete