Forum Discussion
Terrence
Jun 15, 2012Nimbostratus
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.
- mikeshimkus_111Historic F5 AccountHi 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.
- jlarosa_44289NimbostratusWe 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.
- mikeshimkus_111Historic F5 Accounthi 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?
- jlarosa_44289NimbostratusWe used the most recent iApp to configure, 2012_04_06. I did follow the post steps in v2.7 DG.
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects