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.
GREAT Post. You spelled out the ‘limitations’ precisely (as I’ve been encountering anyway), so that I didn’t get lost between the lines of the M$ articles that only spell out what is supported.
We user Windows/Integrated Auth for our entire Intranet here, and there are several applications across several webservers that provide my users with alot of stuff, in one place. It’s silly to have them log into their PC’s and then into the website, so Integrated/Windows Auth solved this.
I am mid-Migration to Exch2007 but now I have to wait until all mailboxes are moved to Exch2007 MB Role, for the Integrated Auth to work for them for their email; if they use it via OWA.
I think this is an oversight on M$ part. Lots with Exch2007 are wonderful, especially the new OWA; but the coexistence piece has alot of missing pieces I think.
One work around I’m am working towards is using ISA as the Publishing Front End. Currently it has FBA for the outside, and therefore proxies Basic Auth into the CAS, and thus OWA works great for both versions through the CAS. I think if I enable an internal Web-Listener on ISA with Integrated Auth, ISA will proxy Integrated Auth to the CAS, and I will be no further ahead, but I think I might try.