This post 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:
In our example, these become:
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!
Post by http://blog.msfirewall.org.uk/2008/07/publishing-exchange-2007-services-with.html
