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 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 and 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 and the primary SAN entry is also 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 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

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:*' 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/ 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 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 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:




This can be achieved using the following PowerShell commands:

Set-WebServicesVirtualDirectory -Identity 'CAS01\EWS (Default Web Site)' -ExternalUrl

Set-OabVirtualDirectory -Identity 'CAS01\OAB (Default Web Site)' -ExternalUrl

Set-UMVirtualDirectory -Identity 'CAS01\UnifiedMessaging (Default Web Site)' -ExternalUrl

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 Select the Use computer name or IP address to connect to the published server option and enter 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 ( in our example) as opposed to using However, this issue has been fixed in ISA Server 2006 SP1 so we could actually specify 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 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/ 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


  1. You've posted another valuable article. So thanks a lot, Jason. But I have some questions about delegation properties of computer object in AD. What about delegation not only for HTTP but also for W3SRV service? And why you haven't configured the CAS server's delegation properties for Mailbox Server to trust them? These procedures were described as neccesary operations in the technet article by Microsoft:
    Publishing Exchange Server 2007 with ISA Server 2006(

  2. >>artyom

    These additional steps are only necessary if you plan to use certificate based authentication (as is required for ActiveSync).

    Some of these additional steps are required for OWA Document Access so keep tuned to see when similar additional delegation configuration is needed!

  3. Hello Jason,
    Thanks for a great article. I’ve spent weeks migrating from exchange 2003 to 2007 and at the same time also migrating from win 2003 to win 2008 including new forests and sanitizing name spaces for several customers. Reading your article summarizes the very elegant way of doing the NTLM to KCD authentication for Oulook anywhere users through ISA server. During my struggle for achieving the same goal, but without your article, I did come across some real showstoppers.

    My approach for all customers was to utilize wildcard certs, and at the same time implementing equal namespace internally/externally.
    The first problem was of course the outlook wizard not working. After implementing the 'Set-OutlookProvider -identity EXPR -CertPrincipalName msstd:*' it looked like the problem was solved at first glance. Windows 2003 terminalservers and XP domain members worked as expected. Windows Vista SP1 domain members and Windows 2008 terminal server still had problems. My problem was that I misinterpreted this as an Outlook autodiscover problem due to the fact that outlook 2007 users on vista SP1 or terminal server 2008 could not complete the Outlook wizard. So there was a second problem disguising itself (at least to me) as an Outlook autodiscover problem. The fact is that they were not able to connect to Exchange 2007 at all.

    I am sure I am not the only one postponing implementing IP ver6 in their infrastructure. By disabling IP ver 6 on all Windows 2008 servers I assumed that I could safely ignore any issues involving the new Ip protocol. I was wrong.

    After finding this article on technet:

    and implementing those changes even vista sp1 users using Outlook Anywhere could complete the wizard.

    Within the scope of your article I would say that this issue is worth mentioning.

    I do have some additional comments:
    I cannot see any reason to leave the http protocol active on the Outlook anywhere listener. Is this not a SSL/TLS only scenario, at least from the outside? Are you trying to achieve http access on the OAB path for internal users with the same listener?

    I also miss articles like yours with the approach to use wildcard certs. Prices have dropped to acceptable levels on those, and I can’t be alone choosing a wildcard cert path for exchange publishing. I ran into problems binding the cert to the UM service in Exchange but I chose to ignore it for the time being cause the service is not implemented by my customers in any near future.

    A little outside the scope of your article:
    I even find it suspect to leave the http protocol active on the second listener used for OWA/EAS. After entering the the listener effectively redirects you to the https://. But if the user ,after that, manually changes the url by removing the ‘s’ in https connection, ISA server accepts that and the SSL connection between client and ISA server is broken hence posing a security risk. I prefer using a https only approach to all exchange publishing rules. I tend to use a redirect website as a solution, like: redirects to

    I also miss a good discussion about real life certificate issues. Local certificate stores on exchange/isa/GC servers are populated with machine cert from local CA, 3rd party wildcard and SAN certificates, exchange self signed certificate. What certificates are eligible for use with the different exchange services and transports? Requirements?

    Hopefully, in the near future, you and Tom could put together a complete and revised exchange 2007 to ISA publishing guide.

    Henning Søilen
    Senior Consultant

  4. >>Henning

    Thanks for the detailed feedback!

    I tend to enable HTTP to HTTPS redirection for most applications that require SSL. I would agree that in this particular case it is not strictly necessary as there is no real user interaction.

    I did consider including inforamtion on wildcard certificate, but wanted to keep things simple for the first entry. I may do a follow artcile that covers this area in addtion to showing the differences needed when you have a Exchange CAS farm.

    I also find that some customers are not keen on using wildcard certificates, for security reasons, as they only authenticate the domain and not the actual server which isn't ideal. Also, if you have you own internal CA I cannot see the benefit in using wildcards are it is very simple to use and amend SAN based certs which I think is MS best practice. Once more public CAs offer SAN certs with 10 or so names, I will probably move to using SAN certs on ISA as well as Exchange.

    From memory, I think the Exchange 2007 Autodiscover Service whiteaper covers a fair bit of detail on certificate detail, bt I would agree that they omit to include ISA certificate requirements.

    I believe Tom is looking at a complete series of articles including a fair bit of content from my blog posts. I have been promisong Tom some of this content for quite a while. so hopefully now he can help some more "polished" articles :)

  5. Pingback:

  6. What happens with Outlook clients on machines that are not in the domain? Do they simply get prompted for authentication, or do they not work at all?

  7. >> Tim

    Hey, Tim - yep, non-domain joined machines will receive an authentication prompt as there will be no transparent authentication using cached credentials. I have tested this and all works fine if you enter valid credentials in the authentication pop-up for a non-domain joined machine.



  8. I think even if you are connecting from a non-domain joined client, you should be able to achieve transparent authentication by adding the CAS and Mailbox server netbios and fqdn and saving the credentials for each of them in the local password store (start--->run-->control userpasswords2)

    A very good and informative article. Keep up the good work!

  9. >> Abdul

    Hmmm...I'm not too sure, have you actually tested this? Due to the use of KCD, I am pretty sure the machine would have to be a member of the domain in order to provide correct authentication. Not something I have tried though to be honest! ;)

  10. Chris Bushong5 May 2009 at 02:53

    This is an excellent article, Jason! I don't know how I would have implemented transparent authentication without your article. I do have one question... I would like to implement redundant servers, using Network Load Balancing (NLB), that host the CAS/HUB roles to provide service high availability to my users. Is there any way to do Kerberos Constrained Delegation against multiple CAS servers in a NLB cluster?

  11. >> Chris

    Thanks! I think this has been one of my more popular posts ;)

    Due to the way Exchange 2007 works, it is better to use ISA web server farm publishing (WSFP) than NLB fro CAS roles. You can still enable NLB for non-web service like POP3/IMAP, but WSFP is the best choice for web protocols needed for OWA, OA, EAS etc. You then use NLB VIPs for non-web services and dedicated IP addresses for WSFP.

    When you configure the farm, make sure to use internal FQDN which will already have correct SPN'd values defined in AD. You then configure the publishing rule to use an SPN of http/* and ISA will insert the correct SPN value depending on which server is being published.

    I've setup this scenario quite a few times, and it works well.

    Hope this helps...



  12. Hi Jason,

    Just re transparent authentication with non-domain joined clients.

    IE (and FF via config file) can send the credentials of the logged on user transparently if the site is in the Intranet security zone. There is no need for access to the KDC as NTLM is acceptable:

    Of course, for non-domain joined clients the logged on user wouldn't have valid AD credentials in the first place. But previous poster's suggestion of saving the username/password in the User credential cache will work.


  13. "This configuration will negate likely problems with ISA Server 2006 pre-SP1 from reading multiple SAN entries as discussed here."

    According to my research ISA Server 2006 SP1 doesn't resolve the problem if you are using 64-bit Exchange 2007.

    Strange, there is no "multiple SAN" problem on non-production 32-bit Exchange 2007 SP1.

    Vladislav Artukov
    (Sorry, doesn't work with OpenID.)

  14. >> Vladislav

    You sure about that?

    I have quite a few deployments where I am publishing Exchange 2007 64bit with ISA Server 2006 SP1 and then have SAN certs...are you talking about a specific problem?

  15. According to this article:
    You can now use KCD to authenticate users cross-forest/domain with the appropriate trusts in place. You would need to be @ISA 2006 SP1 as it has a couple necessary hotfixes.

  16. >>VileTasteOfDeath

    That is true for user objects, but for KCD to work the ISA Server computer object(s) and the published server computer object(s) MUST exist in the same domain.

    Check "The Limitations: Windows Requirements Item 2" in the article URL you provided...



  17. Hi Jason,
    Re certificates; any thoughts on using one public CA UC Certificate, for both Exchange and ISA.

    The UC certificate would be with a SAN of

    If I use this this certificate on the email ISA rule, its obviously valid. If I use it for the Autodiscover rule, I believe the only consequence is the SSL setting becomes (still using as the url)

    Anything I am missing? Is your plan of two public certs and an internal UC better for a reason you could explain?


  18. thank you for this information. quick question. if i'm using a two certificates, one for owa and activesync and one for autodiscover and outlook anywhere. on the exchange server, don't i have to set up a new website for autodiscover, rpc, ews, and oab? any help would be appreciated.

  19. Nope, you can listen on two different public names with different certs, but send them to the same destination server name; the differing paths will be used as appropriate...

  20. >> Paul

    Yep, that is workable, but I prefer to use internal PKI for internal certs and public PKI for ISA certs.

    This is more manageable, felxible and cost effective in the long term...



  21. Hi Jason,

    I have multiple questions (all related to the goal of securing the corporate data by ensuring we connect via trusted client machines, bear with me...)

    1. First of all does this work with Exchange 2003? I have not been able to get confirmation on KCD working with Exchange 2003 with Outlook 2007 RPC/HTTPS

    2. Secondly, I'm a little confused about the comments on non-joined machines being able to receive the prompt: that would be insecure as we are back to any client on the internet being able to connect. I contacted Microsoft, who indicated "KCD will still allow users to log in from any client". So our company's security goal is to prevent access from ANY old client (read, my home pc) and only allow corporate imaged pcs, i.e. domain members with cached credentials. My understanding of KCD is that it must be with a domain member machine, which is the whole reason for going to KCD.

    3. Comment by above reader: "Of course, for non-domain joined clients the logged on user wouldn't have valid AD credentials in the first place. But previous poster's suggestion of saving the username/password in the User credential cache will work" suggests we can now bypass the whole transparent KCD setup. What's the point then??(sorry said in frustration, not at your comment)

    4. Are user certs not involved in KCD as well? I asked Microsoft, and who seemed to indicate certs were only usable in a IAG/UAG scenario: "I also talked to our IAG/UAG team and the only way to use certs to authenticate would be to setup a SSL VPN.”

    So I'm abit confused: your (excellent) article suggests KCD is doable for what I want to accomplish, but Microsoft are saying otherwise. BTW this Microsoft engineer did appear very knowledgeable on this, and is a SME on Exchange.

    Thanks for any input.

  22. Hi Mike,

    Wow, how many questions! ;)

    Please find answers below:

    1. I have only used this approach for Exchange 2007, so not sure about Exchange 2003. I don't think Exchange 2003 supported NTLM authentication for Outlook Anywhere, but I could be wrong here.

    2. I can confirm 100% that a non-domain member *can* connect to Exchange using Outlook Anywhere if the user configures Outlook correctly. Don't forget that ISA KCD requires the delegation to be configured with "any authentication" and then uses KCD protocol transition. See the following quote "The protocol transition extension allows a service that uses Kerberos to obtain a Kerberos service ticket to itself on behalf of a Kerberos security principal (a user or a computer) without requiring the principal to initially authenticate to the KDC. Instead, a user sending a request to a service with credentials, such as an SSL client certificate, that are not acceptable for Kerberos authentication can be authenticated by any appropriate Windows authentication method. When authentication is completed, Windows creates a user token. Then, if the service has the necessary impersonation privileges in Windows, when the service uses this token to impersonate the user and request a Kerberos service ticket to another service, the service ticket issued, which is to the requesting service, is mapped to the user token. The service may use the service ticket obtained through protocol transition to obtain service tickets to other services and thereby delegate the credentials if the account under which the service is running is configured correctly to use the Kerberos constrained delegation extension." from here:

    The end result is that external users will be prompoted for credentials. If valid credentials are provided, ISA then uses protocol transition for the KCD element. If the delegation was configured to use "kerberos only" authentication would fail as an external clinet could never reach the KDC to obtain a ticket.

    3. See above. If the credentials can be stored and presented automatcially (as suggested in previous comments) then the user would have the illusion of "transparent authenticaton"

    4. It is my understaning that Outlook Anywhere does not support any two-factor solutions like certificates or RSA as there is no interface in Outlook to prompt users for which certificate, the SmartCard PIN or RSA passwode as examples.

    So, in summary, although KCD provides a better level of authentication, it doesn't in itself prevent non-domain joined machines from connecting to Exchange using a correctly configured Outlook client when using ISA Server.

    I would agree, that the only way to truly prevent this from occuring would be to use UAG. This is also able to enforce two-factor authentication before gaining access to Outlook Anywhere.

    Hope this helps...



  23. I did all of this; and I still get the login prompt... what's the first place I should check?

    'Set-OutlookProvider' do I need to do anything with that command? my EXPR is set to NULL currently... help.

  24. Hi Aaron,

    This looks resolved now ;)



  25. Can autodiscover for ActiveSync be accomplished without using KCD, for example, if the ISA servers are not in a domain? All I care about is autodiscover for ActiveSync.

  26. Hi Eric,

    Yep, http auth combined with basic auth delegation should be fine for mobile devices.



  27. Hi Jason,

    Thank for you info, this works with Exchange 2010 and TMG, split DNS and 1 certificate with &,,

    I use two IPs, one for Discover,RPC,CDP - Certificate validation point, and other for OWA & ActiveSync.


  28. Thanks Wyvern...used it for that scenario too ;)

  29. Thanks for the useful information, I will use this along with my work.

  30. Those are some amazing ideas to utilize the parts of the car. But using those parts I prefer fixing the car. I repair my car from Car Service Dublin panel.