Wednesday, 30 July 2008

Vista Problem Accessing Office Documents from SharePoint Document Libraries That Are Published Using ISA Server 2006

After recently upgrading my own work laptop to Windows Vista, I have been experiencing problems accessing Microsoft Office documents that are contained in SharePoint libraries which are published by ISA Server 2006. I have quite a lot of experience with SharePoint publishing and these problems appear to continue even when ISA Server is configured to utilise persistent cookies and all other ISA Server publishing configuration elements are correctly configured.

After quite a lot of investigation, it appears that a change has been made in Vista that alters the way that documents are accessed from SharePoint libraries. This change now utilises the Web Client service included with Vista (which acts as s WebDAV redirector). I think this is where the problem begins, as this service does not appear to support persistent cookies in the same way as other Office applications. Consequently, when trying to open Office applications you are now prompted to provide authentication details as ISA Server interperests the request as a new anonymous connection because the persistent cookie is not being used.

An example extract from the ISA Server logs is shown below:


After a bit of investigation of the ISA Server logs it can clearly be seen that this behaviour has changed for Vista machines compared to Windows XP; with the Web Client service enabled the ISA Server logs shows several denied entries for anonymous connections using a WebDAV client agent. Comparing the behaviour with my Windows XP SP2 virtual machine, documents are accessible seamlessly by way of the persistent cookies and the ISA Server logs show the standard Microsoft Office/12.0 client agent.

An example extract from the ISA Server logs is shown below:

At this time, the only way I can solve the problem is to stop the Web Client service on my Vista machine and add the SharePoint external URLs to my trusted sites. Upon doing this, I can open documents seamlessly (just like on my Windows XP SP2 VM) and the client agent in the ISA Server logs shows Microsoft Office/12.0 or Mircosoft Office Existence Discovery client agents as opposed to the WebDAV one.

Bizarrely enough, I have also found that if you cancel the password prompt the document will actually open. From looking at the ISA Server logs, it appears that when cancel is pressed the client falls back to the historic method and starts using the Microsoft Office/12.0 and Microsoft Office Existence Discovery client agents. This can be seen below:

However, with the Web Client service disabled, I can now no longer open a document in Read-only mode and then click the Edit Document link in the document information bar. This is not essential, as I can still open document in edit mode by using the Edit in Microsoft Word option from the document library interface, but this is potentially quite annoying for unknowing users.

I am not sure why the Web Client service is not able to consume the persistent cookies in the same way of Office applications, but until it can, I cannot see a clear way to provide a fully functional solution with Windows Vista. I could of course just tell people to click the cancel button when prompted are prompted for credentials, but this is not really an elegant solution! :)

Any ideas or suggestions, please comment!

Please Note: During my investigation I have tried the fix detailed in KB943280 but I have come to the conclusion that this fix is for a different problem although it appears to have similar symptoms.

Monday, 28 July 2008

Publishing Exchange 2007 Services with ISA Server 2006 – Creating the Publishing Rule for Outlook Anywhere with Transparent Windows Authentication

I originally planned to do a series of blog entries in article format to cover the entire concept of publishing Exchange 2007 services with ISA Server 2006. However, this is not an insignificant task and the more I have started putting content together, the more I have realised what a mammoth task it is!

Based upon demand from users over at the ISAserver.org forums, I have created this blog entry to accelerate the process and produce the articles a little out of sync, and without too much Exchange 2007 preamble. Exchange 2007 publishing is very different to Exchange 2003 publishing and introduces many new concepts that are important to understand before you even start creating your ISA Server firewall policy rules. Some of this article may seem a little confusing as it was written based upon the fact that I had already published the Outlook Web Access publishing guide and we would have a working setup in place with necessary SSL certificates and FQDNs already in place. Hopefully once both articles are available they will 'gel' a little better and remove any potential confusion!

Anyhow, enough waffle...this blog entry covers publishing Exchange 2007 Outlook Anywhere using ISA Server 2006, but the key differentiator being that we can achieve all of the following:

  • Provide transparent authentication for external Outlook Anywhere users if they are logged into domain member computers with cached credentials. This means that the Outlook password prompt seen with Exchange 2003 will no longer be present.
  • Provide ISA Server pre-authentication for all requests, thereby providing the ultimate level of protection for Exchange 2007 Client Access Servers.
  • Provide access to advanced Exchange 2007 Outlook Anywhere features like Autodiscovery, Out of Office, Offline Address Book, Unified Messaging and the Auto Account Setup Wizard etc.
Before getting started on the ISA Server configuration, it is helpful to provide an example environment upon which to base the examples. The diagram below shows an overview of a relatively standard architecture for external remote access to Exchange.






A summary of the environment is provided below:

  • A single ISA Server 2006 (pre-SP1) firewall named ISA2K6.
  • A single Exchange 2007 Client Access Server named CAS01.
  • Two SSL server certificates are installed on the ISA Server. These are issued from a public Certificate Authority (CA) each with unique common or subject names of email.msfirewall.org.uk and autodiscover.msfirewall.org.uk respectively.
  • A single SSL server certificate is installed on the Exchange CAS which replaces the default self-signed certificate. This is issued from an internal CA and is a Subject Alternate Name (SAN) certificate (sometimes called a Unified Communications (UC) certificate). The common or subject name of this certificate is email.msfirewall.org.uk and the primary SAN entry is also email.msfirewall.org.uk. Additional SANs have been defined as per the diagram to cater for alternate access names used by internal clients.

  • ISA Server is configured to trust the internal issuing CA that issued the Exchange CAS certificate and also trust any additional Root or Intermediate CAs, as necessary.
  • The ISA Server and Exchange CAS are both members of the same Active Directory domain.
  • SSL bridging is used to ensure all communications are encrypted across both the public and private networks.
  • All clients are using Microsoft Outlook 2007.
  • A dedicated FQDN is defined for Outlook Anywhere which resolves to a dedicated public IP address.

Please Note: In order to minimise potential problems with ISA Server 2006 pre-SP1, it is recommended to define the Exchange CAS certificate common name and first SAN as email.msfirewall.org.uk. This configuration will negate likely problems with ISA Server 2006 pre-SP1 from reading multiple SAN entries as discussed here. For the purposes of this article I have assumed that ISA Server is running the RTM pre-SP1 version and we would also be publishing access to Outlook Web Access using a URL of email.msfirewall.org.uk.

Although not covered in this article, it is possible to extend the simple approach defined above with the use of additional certificates to personalise external DNS names to specifically match each Exchange service. An overview of this architecture is shown below.



This configuration is not technically necessary, but it does provide a slightly more elegant solution and makes things a little bit more intuitive when looking at DNS names in Windows Mobile or Outlook configuration screens. However, apart from 'elegance', a solution comprising of two individual SSL server certificates is more than sufficient for a working configuration.

Please Note: In theory it is possible to use a single wildcard certificate for this scenario, but from my own testing I have found that the use of a wildcard certificate had an adverse effects on the Outlook Auto Account Setup wizard which I was unable to resolve (even after enabling the 'Set-OutlookProvider -identity EXPR -CertPrincipalName msstd:*.yourdomain.com' PowerShell command as defined here). We also need to consider that Windows Mobile 5 does not support wildcard certificates, so if you have a mixed Windows Mobile client base this will also cause issues. Based upon this, for the time being (and for this example solution) I have been cautious and used individual certificates for most of my deployments.

One of the challenging aspects of Outlook Anywhere publishing is how to achieve transparent authentication (e.g. not having to enter a password in Outlook when away from the office) and also ensure that all Outlook Anywhere connections are pre-authenticated by ISA Server. ISA Server pre-authentication is a vital part of any ISA Server deployment as this ensures no anonymous connections can ever reach the internal Exchange infrastructure.

In it's current form, ISA Server is not able to require Windows integrated authentication and then delegate credentials using NTLM delegation. This is based upon the fact that this authentication protocol is designed to use a challenge/response process and specifically prevent 'man-in-the-middle' attacks. As ISA Server is the 'man-in-the-middle' in a reverse proxy topology, this is just not possible to achieve. Therefore, in order to authenticate Outlook Anywhere connections using Windows authentication is it necessary to use Kerberos Constrained Delegation (KCD). ISA Server 2006 introduces support for Kerberos constrained delegation to enable published Web servers to authenticate users by Kerberos after their identity has been verified by ISA Server using a non-Kerberos authentication method. When used in this way, Kerberos constrained delegation eliminates the need for requiring users to provide credentials twice. For example, because it is unrealistic to perform Kerberos authentication over the Internet (no access to the KDC server), Windows authentication might be used for authenticating users at the ISA Server computer. After ISA Server verifies the user's identity, ISA Server cannot pass the Windows credentials provided by the user to a published server, but it can impersonate the user and obtain a Kerberos service ticket for authenticating the user (client) to a published Web server.

Based upon this approach, the following diagram shows an overview of the authentication elements used in our solution example.


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 Exchange CAS. As we are publishing web services on the Exchange CAS, this means that we are specifically talking about the HTTP SPN. In our example solution (as shown above) the default system generated SPN for the Exchange CAS is http/cas01.internal.msfirewall.org.uk so we will use this in our configuration.

In addition to thinking about SPNs, for KCD to function correctly it is also necessary to configure the ISA Server computer object in Active Directory and enable delegation. In order for the ISA Server to be trusted for delegation, it needs to be correctly defined. Furthermore, to ensure we provide a least privilege solution, we will use constrained delegation to ensure that we only trust ISA Server to delegate the appropriate service (HTTP in our example) and not all services (hence constrained).

This can be achieved using Active Directory Users and Computers. Firstly, find the computer object for the ISA Server 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 Exchange CAS computer object (CAS01 in our example). On the list of available SPNs defined for CAS01, select the entry for http/cas01.

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 ISA Server to be trusted for delegation of credentials, but only to the Exchange CAS, and only for the HTTP 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, both computer objects will need to be in the same Active Directory domain for KCD to function (even with ISA Server 2006 SP1).

As Windows authentication and Forms Based Authentication (FBA) are mutually exclusive, it is not possible to use a single web listener for all Exchange 2007 publishing and achieve transparent authentication within Outlook Anywhere. Therefore, as part of this solution it is necessary to create a dedicated web listener that is used exclusively for Outlook Anywhere and associated services like Exchange Autodiscovery, EWS, OAB, UM etc. This is a bit of a shame, but an acceptable compromise in my opinion and likely to remain until ISA Server is able to perform fallback to NTLM. The introduction of a dedicated web listener for Outlook Anywhere also introduces the need for an additional public IP address.

Without going into specific details (more detail can be found here) the Outlook Anywhere client relies upon the Exchange 2007 Autodiscover service in order to determine where to find information about supplementary services like EWS, UM, and OAB. Therefore, within our solution we need to provide access to the Exchange 2007 autodiscover service located on the Exchange CAS. The Outlook Anywhere client is hard coded to look for the autodiscover services using the following URLs:

https://smtpdomain.tld/autodiscover/autodiscover.xml
https://autodiscover.smtpdomain.tld/autodiscover/autodiscover.xml.

In our example, these become:

https://msfirewall.org.uk/autodiscover/autodiscover.xml
https://autodiscover.msfirewall.org.uk/autodiscover/autodiscover.xml.

In reality, we only really need to consider the second of these URLs as this contains a specific hostname value which is more practical. Seeing as though this URL will always be required by the Outlook Anywhere client, it makes sense to me to reuse this URL as the Outlook RPC over HTTP(S) proxy definition URL. This ensures that a single URL and single SSL server certificate will be sufficient for all Outlook Anywhere functionality, including advanced features.

One of the critical steps in getting Outlook Anywhere to be fully function is to define external URLs for each Exchange service used by Outlook. This ensures that when Outlook is used externally (without access to Active Directory or the Exchange Service Connection Point) it will be able to determine the correct external URLs using the autodiscover process, as opposed to using the default internal URLs defined as part of the Exchange setup process. The default internal URLs will normally contain internal URLs of the form https://cas01.internal.msfirewall.org.uk which will probably not function externally.

At this time, I am not including specific details on configuring the Exchange CAS (as this is quite an in-depth subject!) but the following summary covers the key configuration steps:

Using the Exchange Management Console, enable Outlook Anywhere; define the external hostname as autodiscover.msfirewall.org.uk and client authentication method as NTLM authentication.

Using IIS Manager, ensure the following virtual directories have Integrated Windows authentication enabled:

  • Autodiscover
  • EWS
  • OAB
  • RPC
  • Unified Messaging

Using the Exchange Management Shell, define Exchange Web Services (EWS), Offline Address Book (OAB) and Unified Messaging (UM) External URLs as follows:

EWS: https://autodiscover.msfirewall.org.uk/ews/exchange.asmx

OAB: https://autodiscover.msfirewall.org.uk/oab

UM: https://autodiscover.msfirewall.org.uk/unifiedmessaging/service.asmx

This can be achieved using the following PowerShell commands:

Set-WebServicesVirtualDirectory -Identity 'CAS01\EWS (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/ews/exchange.asmx

Set-OabVirtualDirectory -Identity 'CAS01\OAB (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/oab

Set-UMVirtualDirectory -Identity 'CAS01\UnifiedMessaging (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/unifiedmessaging/service.asmx

Please Note: For completeness, I would recommend defining the External URL reference for all services (as shown above) even if they are not in use at the present time. This minimises the risk of forgetting they have not been configured when you try to access a new Exchange service and it doesn't work via Outlook Anywhere!

If the above means nothing to you then I suggest you start by reading the Exchange 2007 Autodiscover Service whitepaper
here for a bit of background/bedtime reading...

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, let's 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 Outlook Anywhere



Define the Exchange Version as Exchange 2007, select Outlook Anywhere (RPC/HTTP(s)) and Publish additional folders on the Exchange Server for Outlook 2007 Clients.


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.


Please Note: Due to issues with ISA Server 2006 pre-SP1 and SAN certificates (discussed here) it has been necessary to use an internal site name that matched the actual subject name (or first SAN entry) of the SSL server certificate installed on the Exchange CAS (email.msfirewall.org.uk in our example) as opposed to using autodiscover.msfirewall.org.uk. However, this issue has been fixed in ISA Server 2006 SP1 so we could actually specify autodiscover.msfirewall.org.uk as this is listed in the SAN entries of the Exchange CAS certificate. However, with an ISA Server 2006 SP1 both FQDNs should work fine.

Enter autodiscover.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 Integrated).



Select Require SSL secured connections with clients



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 HTTP Authentication and Integrated.



Click Next and then Finish.



With the web listener created, click Next to continue.



On the Authentication Delegation page, select Kerberos constrained delegation 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 Outlook Anywhere which should match the External URLs defined on the Exchange CAS earlier within this post.



So, with all this in place, all we need to do is configure Outlook with the appropriate settings. This can be done using the Auto Account Setup Wizard which is initiated from the Mail applet in Control Panel. The following diagrams show this process.





Looking at the Exchange Proxy settings (RPC/HTTP(s) settings) that have been configured by the wizard, you should see something like this:



So, you should now be able to start Outlook and successfully connect to Exchange 2007 without providing any credentials (assuming you are on a domain member computer and logged in with cached credentials).

Hopefully this blog entry has provided a good overview of the necessary elements required to publish Exchange 2007 via ISA Server with transparent authentication and ISA pre-authentication. Obviously, it does not cater for all scenarios (like wildcard certificates and ISA/CAS high availability for example) but it should be relatively easy to adapt to your specific needs.

I hope to add more blog entries for publishing other Exchange 2007 services, the next probably being publishing Exchange 2007 Outlook Web Access specifically covering the Document Access feature, which is pretty cool for remote users!

Download this Article