Are You Using TMG and Having Issues Publishing Outlook Anywhere?

Ever tried to publish Outlook Anywhere using NTLM with TMG and use Kerberos Constrained Delegation? Many people have tried and failed, or at least had some major trouble before they were finally able to get things going.

To help make things a little easier, here is a simple checklist on how to publish Outlook Anywhere using NTLM with TMG, using Kerberos Constrained Delegation.

The simplest scenario is a single Exchange server and a single TMG server.

1. TMG must be domain joined to use Kerberos Constrained Delegation (KCD), which can be a problem for some organizations. Domain where TMG is member of must be in Windows 2003 mode and it must be the same domain that your Exchange server is on.

2. Configure KCD.

With ADUC (Active Directory Users and Computers),
Find the TMG computer object, select properties and the Delegation tab,
click “Trust this computer for delegation to specified services only” and then select the “Use any authentication protocol”.

Click Add button and then Click “Users or Computers” button and enter the Exchange server.

Then click “OK” and scroll to find “http – servername”,
click to select it, and then click OK twice to save the configuration.
If you tick the checkbox “Expanded” while selecting protocol you will see that both the FQDN and host name will be in the list.

What you have done now is allowed TMG computer to delegate credentials to the Exchange server, but only if it’s using HTTP, that’s why it’s called constrained delegation.

Why do we mess with the Exchange computer object? Well, Exchange web services run under the local system account, if it was running using a service account, then we must use this account to delegate to instead.

3. Create a Listener and publish rule on TMG.

Start by creating a Listener. As the create Listener wizard goes by select these options:
Select “Require SSL secured connections with clients”,
Select an external IP and a certificate to be used by the listener.
For Authentication you have several options and it all depends on what you want to do, but for this walkthrough select HTTP and Integrated. This means NTLM since we are connecting from internet where there is no Kerberos service is available (or have you put a Domain Controller on Internet?).

Create the publishing rule by starting the Exchange Web Client Access publishing rule wizard.
Select version of Exchange and Outlook Anywhere as the service, and also select “Publish additional folders…”. This will add paths for OAB, EWS and Autodiscover URL.
Select “Publish a server farm of load balanced web servers”,
“Use SSL to connect to the web server or server Farm”,
Internal site name is important: enter a name that is on the certificate used by IIS on Exchange server, that is not the certificate clients “see” when connecting to TMG from internet. This certificate is seen only by TMG.
Create a new Exchange server farm. Give it a name and add your Exchange server to it.
For the connectivity monitoring, select “Send an HTTP/HTTPS Get request”.
Farm is complete.

For the public name, select a name that this publishing rule will accept traffic on.
Select the Listener you created earlier.
For the Authentication delegation select Kerberos constrained delegation and change the SPN to “http/*”.
On user sets, select “All authenticated users”. This can be changed to an AD group to limit who is allowed to use the services you’re publishing.

4. Configure Outlook Anywhere to use NTLM.
Set-OutlookAnywhere -IISAuthenticationMethods 'Ntlm' -ClientAuthenticationMethod 'Ntlm'

Why do a farm of servers instead of just a single server?

With a farm, you get the opportunity to do monitoring of the published server. This means that if you encounter that the published server doesn’t work while monitoring, it won’t even try to send traffic to the published server. Flexibility is another thing, you never know what will happen in the future, servers may be added, changed or removed and it’s easier to change the farm membership instead of redoing the publishing rule.

“Test Rule” button. This function is really good but when using KCD it will often fail. One reason for failure is that there is a firewall running between or on the published server which blocks traffic to port 445 and 139. 

Another failure is when you set change configuration on the Authentication Delegation tab to use KCD and set the SPN to “http/*”, a star tell TMG to replace it with the published server FQDN when doing the KCD. Unfortunately, TMG doesn’t do this when you click “Test Rule” button. My thought on this is function behind “Test Rule” button only takes this text string and doesn’t translate the star to FQDN. KCD will fail because it is not allowed to delegate to http/*. To overcome this while testing your configuration,replace “http/*” with “http/x” where x is one of the previously allowed delegation. If you have multiple servers in your farm, you should change configuration and test every published server. When done, don’t forget to change back to “http/*”.

One more plus is that even if you have Basic authentication enabled on the Listener, you can still use KCD on the Authentication Delegation tab, which is good for clients who don’t know how to use NTLM.

More advanced configuration with multiple CAS servers and Load Balancer.

The difference with this configuration is that we have a Load Balancer between TMG and CAS. This provides us with a couple of options. Either a) configure TMG to send traffic to Load Balancer, or b) configure TMG to send traffic directly to CAS.

The problem with the first option is that Load Balancer most likely thinks everything comes from TMG and therefore will not distribute traffic to all CAS, but instead sends it to only one of them. This can be fixed by using more sophisticated distribution algorithms on Load Balancer. But in order for that to work, we need to disable SSL between TMG and Load Balancer, and also allow HTTP to CAS. We also have another source to troubleshoot if something breaks. Another thing is the KCD configuration. Since there is no computer account for Load Balancer, the KCD needs to be configured with a name that TMG can use for the delegation. You must add the SPN string to the msDS-AllowedToDelegateTo attribute on the TMG computer account and finally this invented name must be configured in the publishing rule in the delegation tab as the SPN. This is a valid configuration, but with many variables’ in it I think it’s much too .The other option with TMG sending traffic to CAS servers directly and bypass Load Balancer is much easier to configure and to troubleshoot.

Picture only shoving a single TMG and a single Load Balancer but they can in fact me multiple of them for redundancy and load distribution. Either way, it doesn’t matter when you use KCD.

Connectivity monitoring

TMG will periodically connect to the published server. How TMG connects depends on the connectivity monitoring configuration. We selected to “Send an HTTP/HTTPS Get request” together with a URL. This means that TMG will connect to this URL and if it gets a response back it will allow traffic on this rule.
If you publish for example outlook anywhere you would most certain need to publish a couple of more URL’s than the /RPC such as /OAB, /EWS and /Autodiscover. Sad story here is that TMG cannot monitor more than one URL. If we monitor /rpc directory then all other can fail without TMG noticing it so TMG will still end traffic to one farm member even though for example the EWS service don’t work on it.

Solution can be to have individual publishing rule for each service you publish. Another solution could be your own developed solution. Create a script that monitor services of your choice, and simply create a file in an IIS directory if every service is working or delete the file if something is not working. In TMG we can then configure the URL to point to this file.

RPCping

If you published Outlook Anywhere you verify configuration with rpcping.exe.
Be aware of that rpcping has several parameters and you have to specify them correctly. Here is an example.

rpcping -t ncacn_http -s mapi.corp.contoso.com -o RpcProxy=oa.contoso.com -P "billg,contoso,Password2" -I "billg,contoso,Password2" -H 2 -u 10 -a connect -F 3 -v 3 -a connect -e 6001

This means connect to the rpcproxy name “oa.contoso.com” and the internal server name with mapi.corp.contoso.com. User name is billg, password is Password2,netbios domain name is contoso both for the rpcproxy auth and auth to internal server, e = 6001 means internal tcp port 6001 which is on out of the three ports used by outlook anywhere. The others are 6002 and 6004.