07-01-2009 06:10 AM
I've setup an authentication only activesync sign-in policy. Everything works but there is something I don't understand.
It works because in the backend url field I put our currently external-facing OWA server URL. However, I'm planning on using this for our upcoming Exchange 2007 deployment which requires the CAS role (i.e. OWA) to be internal. I was hoping to use the Juniper to reverse proxy the requests. However, my understanding of the way Juniper handles it is that it simply send the calling web browser the backend URL. In other words, the user enters a URL that matches the hostname set in the sign-in policy, then the juniper replaces that with the backend url. The problem here is that the backend URL must be publicly accessible, no? If that's the case it totally defeats the purpose of having the reverse proxy as you can't have your backend url be an interal address, right?
What am I missing?
07-01-2009 07:22 AM
The back-end URL does not have to be publicly accessible, it does not even have to be the address that you've defined in you OWA properties for your CAS.
In my Exchange environment I have the Internal URL defined for OWA as http://owa.domain.local/owa; I do not have the External URL defined, though I'm not sure it would matter if I did.
On my SA, I am NOT referencing the Internal URL, but I am referencing the server directly. So, my virtual host name is "autodiscover.domain.com" and the backend URL is http://cas01.domain.local:80/*.
iphones are configured to hit the virtual host url, the SA then proxies the request through to my CAS. Make sense?
07-01-2009 07:39 AM - edited 07-01-2009 07:41 AM
Makes perfect sense, and that's what I'm trying to do but it isn't working...
When I setup the backend url using our internal domain name (http://server.mydomain.local:80/*), the client browser errors out and explicitly states that it can't connect to the internal server and displays http://server.mydomain.local in the error message. So, it is obviously sending the client the internal back-end url that is configured.
In fact, the documentation even says that it redirects the client to the backend URL:
When requests match the hostname in the Virtual Hostname field, the request is transformed to the URL specified in the Backend URL field. The client is directed to the backend URL unaware of the redirect.
Is there another setting I'm missing?
07-01-2009 08:18 AM
Hi all, I'm having the same issue :
my direct link to the owa is - owa.mydomain.com/owa
however the IVE cannot deal with the URI - /owa
any workaround for this?
07-01-2009 10:24 AM - edited 07-01-2009 10:58 AM
Yes, the internal URL works internally. I think part of the problem was that I was initially testing on 2003, which didn't work. When I switched to test on my CAS server, it worked as expected (I could access OWA).
But, even though OWA works, activesync isn't working at all...
UPDATE: Turns out my problems were cert related. I turned SSL off on the OWA and activesync sites and it works.
07-01-2009 10:58 AM
Sorry for the back-and-forths, but are you able to hit the http(s)://autodiscover.company.com/owa virtual host from a browser, from an internet source, and are you able to log in to OWA on your CAS this way? I am able to do this, without any cert errors since I'm using a SAN cert on my SA that includes the virtual host name used for ActiveSync. I only mention this as I'm not sure if you already have your cert loaded on the SA and that it corresponds or contains the virtual host name that you and your devices are trying to hit.
Also, did you verify that the virtual host name can be resolved by internet name servers? I'm sure you have, but I thought I should ask.
If that's all cool, I'll post exactly how my SA is configured to support ActiveSync.