Forum Discussion

Terrence's avatar
Terrence
Icon for Nimbostratus rankNimbostratus
Jun 15, 2012

Exchange OWA Enhanced login timeout

So this is my second post on this topic, and I am starting another post, because the earilier post has much information that was no longer relavent.

 

 

We are currently in the deployment stages of a new Exchange 2010 sp2 environment. We have a redundant pair of LTMs internally fronting rpc,autodiscover and ews. This is all functioning as expected.

 

 

We Then have an Edge gateway in our dmz which is fronting OWA and activesync.

 

 

All of our F5 gear is running 11.2 HF2, and we are using the f5.microsoft_exchange_2010_cas.2012_04_06 template and corresponding design guide.

 

 

A few weeks back our Administrators pointed out that OWA via the Edge gateway would never timeout, after doing some testing, this proved to be true.

 

 

A little bit of googling turned up this kb from Microsoft http://support.microsoft.com/kb/2478286

 

 

It seems that the Exchange template doesn't account for this. In my original post regarding this article, I thought I had found a solution as listed below

 

 

when ACCESS_ACL_ALLOWED {

 

set mrhsession [HTTP::cookie value "LastMRH_Session"]

 

if { [table lookup $mrhsession] == "EXCHANGE_LOGOUT" } {

 

set user_logon [ACCESS::session data get "session.logon.last.username"]

 

set sessionid [ACCESS::session data get "session.user.sessionid"]

 

log local0.warn "OWA Exchange Initiated timeout - Session: $sessionid, User: $user_logon"

 

ACCESS::session remove

 

table delete $mrhsession

 

}

 

}

 

 

when HTTP_REQUEST {

 

set mrhsession [HTTP::cookie value "LastMRH_Session"]

 

}

 

 

when HTTP_RESPONSE {

 

if { [HTTP::status] == 440 } {

 

log local0.warn "OWA Exchange Initiated Timeout"

 

if { $mrhsession != ""} {

 

table set $mrhsession "EXCHANGE_LOGOUT"

 

log local0.warn "OWA Exchange Initiated Timeout - MRHSession: $mrhsession"

 

}

 

 

}

 

unset mrhsession

 

}

 

 

 

So for a week I was convinced that this rule resolved the issues. To Which I found that i was incorrect, and upon further investigation discovered that OWA uses the 440 response code quite liberally. Some users would log in via APM and get ejected almost instantly. So I modified the rule.

 

 

 

when ACCESS_ACL_ALLOWED {

 

set apm_mrhsession [HTTP::cookie value "MRHSession"]

 

if { [table lookup $apm_mrhsession] == "EXCHANGE_LOGOUT" } {

 

set user_logon [ACCESS::session data get "session.logon.last.username"]

 

set sessionid [ACCESS::session data get "session.user.sessionid"]

 

log local0.warn "OWA Exchange Initiated timeout - Session: $sessionid, User: $user_logon, MRHSession: $apm_mrhsession"

 

ACCESS::session remove

 

table delete $apm_mrhsession

 

unset user_logon

 

unset sessionid

 

}

 

unset apm_mrhsession

 

}

 

 

when HTTP_REQUEST {

 

 

set isset 0

 

set request_uri [HTTP::uri]

 

if { [HTTP::uri] contains "UA=0" } {

 

set mrhsession [HTTP::cookie value "MRHSession"]

 

set isset 1

 

}

 

}

 

 

 

when HTTP_RESPONSE {

 

if { $isset == 1 } {

 

if { $mrhsession != "" && [HTTP::status] == 440 } {

 

table set $mrhsession "EXCHANGE_LOGOUT"

 

log local0.warn "OWA Exchange Initiated Timeout $request_uri- MRHSession: $mrhsession"

 

unset mrhsession

 

unset request_uri

 

return

 

}

 

unset isset

 

unset mrhsession

 

}

 

if { [HTTP::status] == 440 } {

 

log local0.warn "OWA Exchange Liberal Use of STATUS 440: $request_uri"

 

}

 

unset request_uri

 

 

 

}

 

 

 

I am really surprised that noone else is seeing this issue? How are other people resolving this issue? Is there perhaps an easier way that I am not aware of? Did I miss something in the deployment guide? Depending on the response I might open a ticket with F5 with the issue.

 

 

 

4 Replies

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Hi Terry, thanks for bringing this to our attention. We hadn't seen this before, and to my knowledge you're the first user to mention it. Currently there's no way other than an iRule to end a session based on a combination of URI and response header. We'll do some testing and we may include this as a workaround in the next update to the solution.

     

     

    I'd like to request that you open a ticket with F5 about this, to help us track the issue.

     

    thanks

     

    Mike
  • We are having trouble getting this iRule to work properly. We too are on 11.2 HF1, the only difference is that we are running only a single LTM/APM. We are not using Edge Gateway. All HTTPS services (OA,AS,AD,OWA,EWS, etc.) are combined into a single VS.

     

     

    First off, this is my version of the iRule:

     

     

    when ACCESS_ACL_ALLOWED {

     

    set apm_mrhsession [HTTP::cookie value "MRHSession"]

     

    if { [table lookup $apm_mrhsession] == "EXCHANGE_LOGOUT" } {

     

    ACCESS::session remove

     

    table delete $apm_mrhsession

     

    HTTP::redirect "https://[HTTP::host]/vdesk/hangup.php3"

     

    }

     

    unset apm_mrhsession

     

    }

     

     

    when HTTP_REQUEST {

     

    Reads the custom session variable set when a user has a 2007 homeMDB attribute

     

    set session_Exchange [ACCESS::session data get "session.Exchange"]

     

    set isset 0

     

    set request_uri [HTTP::uri]

     

     

    User has a 2010 mbx and goes to 2010 OWA CAS Pool

     

    if { [HTTP::uri] contains "UA=0" } {

     

    set mrhsession [HTTP::cookie value "MRHSession"]

     

    set isset 1

     

    }

     

     

    User has a 2007 mbx and goes to 2007 OWA CAS Pool

     

    if { $session_Exchange equals "2007" && [HTTP::uri] contains "ev.owa"} {

     

    log local0. "2007 User isset to 1"

     

    set mrhsession [HTTP::cookie value "MRHSession"]

     

    set isset 1

     

    }

     

     

    unset session_Exchange

     

    }

     

     

    when HTTP_RESPONSE {

     

    if { $isset == 1 } {

     

    if { $mrhsession != "" && [HTTP::status] == 440 } {

     

    table set $mrhsession "EXCHANGE_LOGOUT"

     

    unset mrhsession

     

    unset request_uri

     

    return

     

    }

     

    unset isset

     

    unset mrhsession

     

    }

     

    if { [ info exists request_uri ] } {

     

    unset request_uri

     

    }

     

    }

     

     

    Without the edits above, OWA would simply hang upon signout. The page would go blank, and just continuously process. We wanted a cleaner experience for our users, so we decided to combine the redirect and ACCESS::session remove into a single function: HTTP::redirect "https://[HTTP::host]/vdesk/hangup.php3". We then had to add the final [info exists request_uri] section because we were getting LTM errors that the variable could not be unset because it did not exist.

     

     

    This does not appear to be working as it should. We occasionally get these LTM errors: http_process_state_header_xfer - Invalid action EV_SINK_HEADER during ST_HTTP_XFER_HEADERS

     

     

    Since the APM Session Remove action is bundled with the redirect, if the redirect does not work, the session is never removed. I know I can just add the ACCESS::session remove back, but we have customized APM Logon to fit out branding and would really like to use the Logout page to inform users their session has ended.

     

     

    Any thoughts?

     

     

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    hi jlarosa, we didn't experience the hanging issue when testing this rule. I'm curious if something else is happening in the response that's causing the page to hang. Did you deploy Exchange using the iApp template, and if so, which version? Did you follow the post-configuration steps from the deployment guide?

     

    thanks

     

  • We used the most recent iApp to configure, 2012_04_06. I did follow the post steps in v2.7 DG.

     

     

    We do have additional modifications though. We are using the VPE to do an attribute lookup (homeMDB) and set a session variable. This variable is read by the persist iRule to direct to the proper pool (2007 or 2010) for OWA, EWS, and ActiveSync.

     

     

    Additionally, we have heavily modified the HTML code for the APM logon page itself. Mostly just to add our standard headers/footers, background, etc. But it is modified. It may be worth trying a base APM to see if that works any better.

     

     

    UPDATE:

     

    We just modified the top section of code to read as follows:

     

     

    when ACCESS_ACL_ALLOWED {

     

    set apm_mrhsession [HTTP::cookie value "MRHSession"]

     

    if { [table lookup $apm_mrhsession] == "EXCHANGE_LOGOUT" } {

     

    ACCESS::session remove

     

    table delete $apm_mrhsession

     

    HTTP::redirect "https://[HTTP::host]/vdesk/hangup.php3"

     

    }

     

    unset apm_mrhsession

     

    }

     

     

    Instead of making the iRule redirect, we are simply removing the session and deleting the value from the session table. This seems to be working so far. Not sure why it wasn't working before and we tried to go the redirect route, but so far so good.

     

     

    I will update if anything pops up.