SAM Auth Double Prompt Using Exchange iApp

Cory, would it be easier to convert all user sessions to either UPN or SAM. You're already doing an AD query so you can override the session.logon.last.username with the UPN or SAM. It would simplify your VPE configuration and should resolve your double prompt issue.

OK - After putting in some significant time, I've figured out how to solve this issue. We faced multiple symptoms that led to this particular problem, BUT I sincerely welcome the folks that write the Exchange iApp and associated documentation to provide feedback if I'm incorrect with my statements below.

ISSUE 1

Our Exchange CAS servers were configured to only accept Basic authentication in order to function properly with Forefront TMG. This has now been re-configured to utilize Forms-Based Auth as the Exchange iApp expects.

ISSUE 2

We have multiple internal domains within a single forest, so we cannot login with only a username. The username for OWA MUST be presented in a %DOMAIN%\%USERNAME% or %USERNAME%@%DOMAIN% format. Since the iApp has configured the Access Policy to Split Domain from Username, I reconfigured the Form Parameters field of the Forms-Client Initiated SSO Configuration to POST %{session.ldap.last.attr.userPrincipalName} instead of %{session.sso.token.last.username} for the username field. Obviously, you'll need to make sure you're running the prerequisite Query within the Access Policy to pull this variable so it can be leveraged.

ISSUE 3

The documented SSO Select iRule within the Exchange iApp Deployment Guide for OWA had a couple clarifications we had to modify (see p87 in the http://www.f5.com/pdf/deployment-guides/microsoft-exchange-iapp-v1_3-dg.pdf guide):

when RULE_INIT {
   replace exchange_forms_sso here with your forms-based SSO name
   set static::OWA_FORM_BASE_SSO_CFG_NAME "exchange_forms_sso"
}
when ACCESS_ACL_ALLOWED {
   set req_uri [HTTP::uri]
   selects the forms-based SSO when Outlook Web Access is detected
   if { $req_uri contains "/owa/&reason=0" } {
      WEBSSO::select $static::OWA_FORM_BASE_SSO_CFG_NAME
}
   unset req_uri
}

When you modify line 3 to set the forms_sso configuration you created, MAKE SURE to use the full path ("/Common/exchange_forms_sso" instead of "exchange_forms_sso"). We couldn't get to anything further without it configured that way.

Also; using the IE Developer tools, I noticed that the /owa/&reason=0 URI noted on line 8 of the iRule was never presented to us from our Exchange 2010 environment. Therefore, the Forms SSO was never invoked. I changed this value from "/owa/&reason=0" to "/owa/auth" and everything was perfect after that.

To sum up, here's what my iRule looked like after all was said and done:

when RULE_INIT {
   replace exchange_forms_sso here with your forms-based SSO name
   set static::OWA_FORM_BASE_SSO_CFG_NAME "/Common/exchange_forms_sso"
}
when ACCESS_ACL_ALLOWED {
   set req_uri [HTTP::uri]
   selects the forms-based SSO when Outlook Web Access is detected
   if { $req_uri contains "/owa/auth" } {
      WEBSSO::select $static::OWA_FORM_BASE_SSO_CFG_NAME
   }
   unset req_uri
}

Again, I am BRAND NEW to this, so I ask any of the moderators/experts to provide feedback to this answer. While this solution works, I am still concerned that I could be causing more issues downstream that I haven't uncovered yet. For those who are also seeing this issue, I hope this helps you out!

Thanks all, Cory

Hi Cory, thanks for the input. Regarding issues 1 and 2, you are correct. The iApp expects forms auth when using APM, although we have added smart card auth as an option in the next version.

Also, the iApp defaults to a simpler APM configuration than you require; we find this to be sufficient for the majority of customers. We did also add the ability to choose your own APM profile, rather than just accepting the defaults, in hopes of providing a little more flexibility.

About 3: The v1.3.0 iApp should have created an iRule that looked like this:

when ACCESS_ACL_ALLOWED {
    set req_uri [HTTP::uri]
    if { $req_uri contains "/owa/auth" } {
        WEBSSO::select [set foo /Common/exchange_2013.app/exchange_forms_sso]
    }  
    unset req_uri
} 

It looks like the deployment guide is lagging the iApp, and we'll get that corrected. Did the iApp create an iRule like the one from the guide, or was it formatted like the one above?

thanks

Mike

Mike -

You are correct! I went through and created a new App from the ground up, and indeed it created the following:

when ACCESS_ACL_ALLOWED {
    set req_uri [HTTP::uri]
    if { $req_uri contains "/owa/auth" } {
        WEBSSO::select [set foo /Common/THISISATESTAPP.app/exchange_forms_sso]
    }  
    unset req_uri
} 

I think the issue in this case is I started from the 1.2.0 iApp and this time around I had manually created all the AAA/APM related functions out of the Deployment Guide and selected them from the iApp config.

YES; I would definitely appreciate the update to the SSO Select iRule on p78 of that Deployment Guide! While you're in there, I also noticed that the OA Persistence iRule on p82 has a discrepancy between the variables set and leveraged on lines 16 and 17. The ActiveSync Persist iRule also has mixed up variables on p78 in lines 3 and 4.

Sorry to dump all that on you at once, but I already feel like it's Christmas today!! 🙂

Thanks Mike for all your help!

-Cory