OWA 2013 SSO failed

In the meanwhile I found out that the issue seems to be related to our overall network design.

Sorry that I don't mentioned this before, but we have to BIG-IPs in the traffic path. One in the Intranet, which hosts the "real" Exchange LTM configuration and another one in the DMZ, which acts just as reverse proxy, but handles all the APM stuff. Means the DMZ-LB forwards the traffic to the VS of the Intranet-LB.

I now reconfigured this and put all the LTM logic for Exchange on the DMZ-LB as well. With this setup it's working now (with this start URI "/owa/auth/logon.aspx?url=https%3a%2f%2f%2fowa%2f&reason=0"). Any idea what's the reason for this, because I still prefer to have the LTM logic only in place ones (due to inconsistency risks).

The only small issue I'm currently seeing is, when I logout from OWA I'm not getting redirected to the APM logon page, but ending on the OWA logon page. Is this related to the "Logout URI Timeout" value, because I see that the APM session is not deleted immediately.

Thank you!

Ciao Stefan :)

Glad you could get it working. By LTM logic, do you mean the iRule? This is just necessary to forward the requests for the different Exchange protocols to the virtual server on your internal LTM.

With Exchange 2010, we inject an HTTP header that includes the APM session ID that the LTM can use to persist sessions; however, persistence isn't required in 2013 so you could probably just assign a default pool to your APM VS that points to the LTM.

When you go to "/owa", CAS redirects you to the encoded URL you have above. IIRC, your version of APM won't match an encoded URL to its non-encoded counterpart, or do wildcard matching.

Does the value you have for APM Logout URI match the URI users click to log out?

Hi Mike,

with LTM logic on the internal-LB I mean all the things mentioned in the Exchange 2013 Deployment Guide when just using LTM (different pools/monitors, OneConnect- and HTTP-profiles, iRule to do the pool separation). Our external-LB should only act as simple reverse proxy (internal VS is the poolmember of the external VS). And here something seems to get broken for the SSO-part. Right now we copied all the LTM logic to the external-LB as well so it points directly to the Exchange-servers (bypassing the internal-LB). This way everything seems to work correctly. That's why I'm asking which setting of our initial setup is braking the SSO.

And according to the Logout URI, I traced this with FF "Live HTTP headers" and I think it's the correct one, because the session is correctly delete on the APM. But with a few seconds delay (I assume the 5 seconds default Logout Timeout) and therefore the redirect to the OWA Logon page is NOT catched by the APM. Can this be changed somehow?

Thank you!

Ciao Stefan :)

It's hard to say what's going on without looking at the configs on both boxes. If it's possible, one thing that might be helpful is to download the latest 11.6 demo VE image and the Exchange 1.5.0 iApp template from downloads.f5.com, do a test deployment using the VE, and then comparing the configurations with your 10.2.4 boxes.

The iApp supports 3 deployment scenarios: LTM with an option to deploy APM on the same box, APM forwarding to an LTM, or LTM receiving from APM. If you deploy 2 and 3 on your VE(s), you will get a config that has been extensively tested by us. If there's something that got missed in your manual configuration, you would see it in the comparison.

Did you configure the APM timeout iRule from the deployment guide? This should handle the logout URI and timeout from OWA directly if applied on the APM VS, regardless of what's configured in the Logout URI in APM.

Hi Mike,

do you mean the "APM session check iRule"? I implemented it, but still ending up on the OWA logon page after logout. Furthermore I see three "blue" sessions in the current sessions menu from my sourceIP.

Thank you!

Ciao Stefan :)

The iRule throughs a TCL error, when performing the logout:

 - Operation not supported (line 1)     invoked from within "ACCESS::session remove"

Therefore the following redirect to "https://[HTTP::host]/vdesk/hangup.php3" is not executed and the iRule is broken.

Any idea what's wrong here and how this can be corrected?

Thank you!

Ciao Stefan 🙂

The supported solution in F5 is "Client initiated Form Base SSO". I don't know if it is available in version 10.

When deploying Exchange 2013 behind APM, I always configure Kerberos contraint delegation which is the easiest way to configure all services with the same SSO method (OWA, ActiveSync, Outlook Anywhere, Offline Address Book, Autodiscover, Exchange Web Services)

In APM V11.4 and above, the Exchange profile allow you to configure quickly client side authentication method and server side SSO...

Client-initiated Forms SSO ("Forms v2") was introduced around BIG-IP 11.1 or 11.2, IIRC. The v1 Forms config from the v10 deployment guide should still be applicable.

Using KCD does let you use one SSO for all services, but our iApps and solutions are targeted at deploying with the least amount of changes needed on the CAS. The dissimilar SSO methods are used to match the out-of-the-box Exchange settings.