RSS Subscription 168 Posts and 2,769 Comments

Archive for September, 2007

Integrated Authentication and Exchange 2007

When doing a multi-site Exchange 2007 deployment, you need a CAS and HTS in each site where a MB server exists. When working on multi-site deployments, you will need to learn about CAS-CAS Proxying/Redirection. Proxying/Redirection is the configuration of InternalURLs and ExternalURLs so when an external URL accesses the Autodiscover service and retrieves the ExternalURLs for that internet facing CAS, that CAS can proxy information between other CAS servers in another site where that user’s mailbox is located. On the internal facing CAS servers, for this to work, you must configure Integrated Authentication on those directories in order for Proxying/Redirection to work.

Now here is where the issue arises. Because those CAS servers are using Integrated Authentication, you might end up using Integrated Authentication for OWA instead of Forms Based Authentication (I talk about how to get this all to work with FBA in a bit). So in this scenario, a user who is authenticated to AD should automatically be granted access to OWA because they are authenticated. The problem I have found, is that Integrated Authentication WILL NOT work if the CAS is on a server where other roles are installed as well.  There’s some documentation on this here and here

So there are two ways to get Integrated Authentication to work.  The first is by having a CAS only server.  This allows you to have Integrated Authentication working for only Exchange 2007 virtual directories (/owa only).  The second is by having a server that has both the Client Access and Mailbox roles installed. This allows you to have Integrated Windows authentication working with any virtual directory.  The problem here is when co-existing with Exchange 2000/2003 and Exchange 2007, the CAS needs to be on a separate server from the Mailbox Server or you won’t be able to proxy.  See the dilemma?  If you split the CAS from the Mailbox Server, you can allow Integrated Authentication, but you’ll break proxying to the Exchange 2000/2003 Back End Server. So in either situation (CAS only vs CAS/MB only), integrated Authentication will work fine /OWA, but won’t for /Exchange when you’re co-existing with Exchange 2000/2003 when directing Exchange 2000/2003 users to go through your CAS.

If you are using Integrated Authentication when the CAS is installed with other server roles, it’ll prompt you for a password as if you were using Basic Authentication. This integrated authentication limitation is only when you are accessing OWA. Integrated Authentication will still work just fine for CAS-CAS Proxying/Redirection purposes.

So how can we get around this?

1. Since Integrated Authentication is only needed on Intranet-Facing CAS servers, we can use Forms-Based Authentication on the Internet Facing CAS and just use Proxying for all other Intranet-Facing CAS servers. This will allow you to have 1 OWA URL across the board. This is because once the external URL authenticates to the FBA Internet-facing CAS, they will be authenticated and the Internet-Facing CAS will proxy information between the CAS that is located in the site where that user’s mailbox is located.

2. If the client does not want to use Proxying for OWA, but wants to use Redirection, then you will most likely want to use Integrated Authentication across the board with all CAS servers so user’s will have a consistent experience. In this case, you’ll want to install your CAS servers on their own servers so a user will not be prompted for a password when they are properly authenticated. Of course you can just leave this alone and leave the CAS installed with other roles and just have it as if they were authenticating using basic authentication.

Note: Re-Direction can only be used for OWA. What Re-Direction does, is when a user authenticates to the Internet-Facing CAS, that CAS will see that the user’s mailbox is located in another site, and that CAS will change the URL in the user’s browser to the OWA address configured for the CAS in their own site. Proxying will not change the user’s URL, but will essentially keep the user’s OWA URL the same, but just proxy the data in the background making the URL experience the same wherever their mailbox is located at.

Share

New Method to Deploy Autodiscover (Using DNS SRV)

Microsoft has released a new client-side hotfix (KB 939184) for Outlook 2007 which will allow Outlook 2007 to contact the Exchange 2007 Autodiscover using DNS SRV records (KB 940881). This allows you to save costs by using a single-name certificate with a single IP. A con to this is your Outlook 2007 clients will have to accept a re-direct message. This hotfix will be included in Outlook 2007 SP1.

More information:
http://support.microsoft.com/kb/940881 (How to configure)
http://support.microsoft.com/kb/939184/ (Information about hotfix)
http://support.microsoft.com/gp/CUHotFix_LandingPage_Request (Request hotfix)
http://msexchangeteam.com/archive/2007/09/21/447067.aspx (Msexchangeteam.com article)

Share

Client Access Server Proxying and Redirection

There is an excellent article that describes how CAS to CAS proxying and redirection works over here. It was created to supplement this white paper. It also discusses CAS to Exchange 2003. I wanted to discuss some key points on this article from a CAS to CAS situation.

  • Proxying is used when you have one internet facing CAS. Your other CAS will be accessible via intranet only. When a client connects to the internal facing CAS, that CAS will see that the user’s mailbox is located in another site. That CAS will then proxy information from the CAS which is located in that user’s site. In order to have CAS Proxying working, ExternalURL properties must not be configured (default) on intranet-only CAS. You must use proxying if you want to have 1 common URL. For example, you want to expose only https://owa.domain.com. This is because even if a client connects to a CAS in another site, that CAS server will do the proxying behind the scenes. Redirection is a bit different since it re-directs the client to a new URL for the CAS that is located in the user’s site in which their mailbox is located. More on this in the next bullet.
  • Redirection is used when you have more than one internet facing CAS. So if we have two sites, we make both CAS accessible via the internet. We then configure the CAS’ ExternalURL properties. This method will expose multiple OWA URLs. So in this configuration, one CAS may use https://mail1.domain.com and the other CAS may use https://mail2.domain.com. If a user connects to https://mail1.domain.com and their mailbox is located in a site where the CAS uses the https://mail2.domain.com, the CAS they connect to will automatically re-direct that user to https://mail2.domain.com

Other things to note:

  • Proxying does not work with POP3 or IMAP4. If you use either of these protocols, you will have to make sure your certificate, DNS, and firewall is configured to allow POP3 or IMAP4 connectivity to the CAS in that user’s specific site where their mailbox is located. Because of this, you cannot have 1 common URL.
  • Redirection only works with OWA.
  • Outlook Anywhere uses neither Redirection or CAS-CAS Proxying. If you contact a CAS in another site, the CAS will talk directly with the Mailbox in the other site.
  • In order for Proxying to work, Integrated Windows Authentication must be used on the necessary directories in IIS on the intranet-facing CAS.
  • If you want to use re-direction for OWA but Proxying for all other services, you can configure the external URL for OWA but leave all other ExternalURL properties blank ($null).

I would highly suggest reading the two articles I linked in the first paragraph if you are deploying Exchange 2007 in separate sites which contain a Mailbox Server, Hub Transport Server, and Client Access Server.

Share