ActiveSync and Multi Domain SSO issue

The Multi-Domain SSO option in APM is generally intended to create single sign-on between two or more APM VIPs. It's also been awhile since I've tested this, but I believe clientless-mode doesn't function correctly in this manner. So while the web-based Outlook works (as it supports the redirects and cookies), do you really need client side SSO for the ActiveSync client?

Have you tried the Exchange iApp?

Hello Kevin,

No, I don't need SSO for ActiveSync. The issue is that the costumer doesn't want to change the URL for ActiveSync, in other words not change the ActiveSync configuration on existing devices, as transparent as possible for end users.

I currently have 2 VSs. One for outlook and one for authentication, two VIPs and we'll add more soon.

And yes, I'm using the Exchange iApp.

Thanks,

Pedro

I used the Exchange iApp to build the initial configuration and then changed a little bit to accomplish SSO between multiple VIPs (we tested with a third VIP and it works great). As I sad before we currently only have 2 VIPs, and yes we'll use the credentials from outlook, or any other site, to access multiple sites within the same domain (i.e. SharePoint, some customer apps and etc.), therefore multiple VIPs.

The Exchange iApp is configure on an APM box (BIG-IP APM will provide secure remote access to CAS) and the load balancing is done on a LTM running on a separate box.

Exchange iApp Config: BIG-IP APM will provide secure remote access to CAS Exchange Server 2010 AD authentication (4 AD servers) SSL Offloading WAN connections OWA and ActiveSync Deployed

Multiple Domain SSO config:

Domain Mode: Multiple Domains Primary Authentication URI: https://authentication.example.com Primary Cookie Optios: Secire SSO Configuration: HTTP Basic

Authentication Domains - Only one for now: Cookie: DOmain - outlook.example.com Cookie Options: Secure and Persistent SSO COnfiguration: HTTP Basic

Thanks,

Pedro

After noodling on this one for a bit, I've come to the following thoughts:

1. It's pretty clear that ActiveSync won't work with the APM Multi-Domain SSO process. You could certainly modify the iApp's iRules to perhaps accomodate for this, or

2. And this isn't completely vetted, but I believe it'd be possible to VIP target your configuration.

   • Change your existing iApp-created Exchange VIP so that it listens on an internal, non-routable address.
   • Create a new standard Exchange iApp that JUST handles ActiveSync and also put it on an internal, non-routable address - all other settings the same as above.

   • Create an externally-accessible LTM HTTP VIP and an iRule that sends traffic to either internal VIP based on URI. Example:

     when HTTP_REQUEST {
         if { [HTTP::uri] starts_with "/microsoft-server-activesync" } {
             virtual active_sync_vs
         } else {
             virtual exchange_vs
         }
     }  
     

So based on the incoming URI, the request will either go to the ActiveSync VIP and authenticate directly, or to the Exchange VIP and authenticate via Multi-Domain SSO. Give that a shot.

I tried the second option without success.

I think that's an issue with the returning traffic, there's to many paths going back and forth. I also included a SNAT so traffic passing through the External VIP could return, but it didn't help.

The first option seems more interesting anyway. Is it possible to change to assign a Access Policy based on an URI? If I could "select" the Access Policy accordingly to my URI, I think it would solve this issue. An iRule, if URI equals "microsoft-server-activesync" then use Access Policy "basic_access_policy" else use Access Policy "Multi-Domain-SSO". Something like that.

Thanks,

Pedro

While you can switch SSO profiles in an iRule, you cannot dynamically switch an assigned access profile. The general alternative for such a thing is what I outlined in option two. Understand that you have two different VIPs with two different access policies: one for standard non-multi-domain ActiveSync, and the other for everything else. An external VIP is used to broker the traffic to the appropriate internal access policy VIP based on the URI. The external VIP is simply LTM with an HTTP profile, a client SSL profile to terminate the HTTPS, and an iRule - no pool, no SNAT, and no APM. The virtual command produces no routing issues and no latency.