Saturday, August 13, 2011

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.
simplest scenario is a single Exchange 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 – server name”,
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. TechNet has a good post related to “test rule” button failure
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.
advanced configuration with multiple CAS
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.
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 -o -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 “” and the internal server name with 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.
The other parameters aren’t that easy to figure out but you can read everything about them here


  1. Great post lasse.. i see people having problems with this everywhere and its not that well documented.

  2. I have the external pointing to an IP-address and want OWA, ActiveSync and OA on that IP but it seems like you need to configure two listeners for the above, one for OA/ActiveSync and another one for OA but since it uses the same name/IP, this is not possible. Is the only solution to get KCD working properly to create two different Listeners and therefore differnet IP-addresses/external hostnames?

  3. You can use KCD with any listener. The trick is to allow application in IIS to handle windows integrated authentication.
    So if you have Forms Based Authentication enabled for OWA on Exchange server it will not work since TMG cannot enter logon information on a webpage.

    If you have Forms Based Authentication on TMG it will only show the FBA forms for browsern and not for other services like OA. FBA will fall back to HTTP Basic Authentication when there is no browser.

    Do you have FBa enabled somewhere and if so, where ?

  4. To clearify :) What we want to accomplish is that when user from Internet go to they get to a FBA on the TMG. Internally we have CAS (https://cas.domain.local) configured with Basic Auth. cas.domain.local is also the array all internal Outlook clients connect to. This works!

    Now we want Outlook Anywhere from Internet through TMG where cached credentials work for the users so they don't have to enter credentials when starting Outlook on the Internet. Is this possible to accomplish using the same listener? Or do we HAVE to create another listener with another IP and another hostname (like

  5. For Outlook to use the cached cred you must use NTLM which cannot be use together with Forms Based Auth on TMG. With FBA you can only use FBA or HTTP/Basic.
    In your case you need another listener which use NTLM and then do KCD agains Client Access Server.

  6. Thanks Lasse - I got everything to work thanks to you with traffic flow Internet -> TMG -> CAS Farm (2 of them in an array). Cached Credentials work now!

    But there's one thing that I want to get working in the lab (even though you recommend not to :)) and that is the scenario you're mentioning above when you have an HLB in front of the CAS and you want to configure TMG to send traffic to the HLB instead of directly to the CAS. I have tried to add a made up name on the TMG server object attribute msDS-AllowedToDelegateTo. I call it http/loadbalancer. Then I change on the TMG rule -> Authentication Delegation I put http/loadbalancer instead of http/*

    But when I start Outlook authentication fail.

    Anything else I need to do to get it to work?

  7. Sending traffic from TMG to LoadBalancer and using KCD is something I have never done. Read this article an explanation of kerberos.
    If you carefully you will notice that you can delegate KCD with help of msDS-AllowedToDelegateTo as you already tried but it will fail caused by SID's and server verifying the client as explained in the article.
    The solution would be to enable kerberos on CAS services with an ASA account, also explained in the article and then do teh KCD to this account instead of a CAS computer account or LoadBalancer VIP address.
    I haven't really tried this but it would be a good experiement to do one day.
    To me this is overcomplicating things adding the loadbalancer as an extra component in the chain between clients from Internet and your CAS servers.

  8. I think one must surely read this post..Very informative..

  9. Excellent publish.I want to thank you for this useful study Test Guide, I really appreciate giving this excellent publish. Keep up your perform.

  10. Hi Lasse,

    Thanks for the excellent post, no-one else has barely mentioned the implications of a HLB fronting CAS. In my case we have 4 TMG servers, 2 HLB's and 4 CAS servers. The TMG servers are LB'd themselves by a seperate external HLB. Given then that the 4 TMG servers are LB'd would this negate the problem you described of all requests ending up at the first CAS server as the request are coming from 4 sources from the internal HLB's perspective?

    Also why would SSL need to be disabled between the two, I'm guessing the distribution algorithms require looking at the traffic? Any examples?

    Thanks in advance,

  11. Ich frage mich, welche Plugins Sie für Ihren Blog benutzen, um
    Spam zu verhindern. Vielen Dank. Können Sie mir da was angebrachtes anraten?

    Here is my web-site: Engel channeling