Issue with Exchange 2010+ federation on BIGIP VE LTM+APM

Have you determined exactly which URL is causing a 401 auth? Another option is to copy _sys_APM_ExchangeSupport_OA_BasicAuth iRule into a custom iRule, assign that iRule to your virtual, and try to log URIs there for which it sends 401, and add ACCESS::disable for those URIs accordingly.

Yes the Exchange server provides the following log which identifies the URL that it is trying to access.

 

Process 53124: ProxyWebRequest FederatedCrossForest from S-1-5-21-2546138925-1139648620-3264887618-5569 to https://mail.domain/ews/exchange.asmx/wssecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The request failed with HTTP status 401: Unauthorized.

 

If I try to access to url externally I do get an authentication prompt rather than the APM landing page which makes me think it is trying to bypass the apm.

 

No, it is not trying to bypass APM - APM is generating a 401 authentication for that request - that is part of the _sys_APM_ExchangeSupport_OA_BasicAuth logic.

 

 

Try to make a copy of that iRule, assign to the virtual, and modify it as follows: find the HTTP_REQUEST event and the switch that looks for different paths, and add the logic from your irule to the paths that you want to bypass, have the following two commands execute upon that detection:

 

 

ACCESS::disable

 

return

 

 

Then see what is going to happen.

Thanks for the help Michael,

 

 

I've tried your suggestion and it's confused me more.

 

I tried adding the following to the irule above the ews uri path.

 

"/ews/exchange.asmx/wssecurity" {

 

ACCESS::disable

 

log local0. "Disabled APM enforcement for EWS HTTP path: [HTTP::path]"

 

return

 

}

 

 

Which didn't work and it looked like it caused the uri to break and produce the following log on the cas server

 

Process 53124: ProxyWebRequest FederatedCrossForest from S-1-5-21-2546138925-1139648620-3264887618-5569 to https://mail.pod101.cstack.co.nz/ews/exchange.asmx/wssecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

 

 

Then I made a few changes and accidently forgot to remove the original bypass irule I had in place and free/busy started working. :/

 

 

So what I've got now is the previous irule I mentioned in my first post assigned to the virtual and also the above entry in a modified APM_ExchangeSupport_OA_BasicAuth irule.

 

If I remove either the original irule I used or the additional lines I added to the OA_basicauth irule it stops working. Yet they do the same thing.

 

 

I'd really like to have an understanding on why its behaving the way it is as it seems a bit crazy.

I am a bit confused - you are saying you need to have both iRules applied to get this working, but reading your post, it implied that when you made the original change, it didn't work because you had both irules assigned? Can you please clarify exactly what was not working before and what is working now? Also, what is the order in which the iRules appear assigned to the virtual server?

 

 

Still, looks like we got the main problem resolved, it's just more of a cleanup now. :)

 

Yea sorry I didn't explain that very well.

 

 

I removed the custom bypass rule from the virtual and then modified the OA_basicauth rule with what you suggested and added that to the virtual. Free/busy didn't work.

 

 

I then readded the custom bypass rule and free/busy started working.

 

 

I then removed the modification to the OA_basicauth rule and it stopped working. Then readded it, it started working.

 

Then removed the custom rule to double check and it stopped working.

 

 

So when both the custom rule and the modified to the OA_basicauth rule are applied to the virtual free/busy works. But if I remove either it will stop working.

 

 

Hence why I'm confused as to why it even works.

 

 

As far as rule order, I have

 

1. Owa_redirect (default rule)

 

2. Bypass rule (custom)

 

3. APM-owa-session irule(deployment guide custom rule)

 

4. mod_APM_ExchangeSupport_OA_BasicAuth (modified rule)

 

5. _apm_combined_pool_irule7 (default rule)

 

6._Select_sso_irule7 (default rule)

 

I see. I have an idea now... I think the fact that first iRule triggers, and you call ACCESS::disable from there, which effectively SHOULD disable calls to all ACCESS events that are in the modified _sys iRule. So when the desired request gets to the mod_sys iRule, you trap it there and exit out of HTTP_REQUEST event, and all other events don't fire due to APM being disabled before. That's my guess - I will try to verify it. Do you mind removing ACCESS::disable command from the modified iRule and see if it will still work with both iRules assigned? If it does, I think it will confirm my theory.

Yes your right it still works when I remove ACCESS::disable from the modified irule and only have the return statement

Dear all, Please make sure you are aware of the new Useragent Microsoft O365 is using.

 

Office365: Useragent: ASProxy/CrossForest/EmailDomain/*

 

Good Luck

 

wiesmann

 

I was running into the same issue. Here is what I did to fix it:

First, I copied the iRule from OP (above) and called it Exchange2013_Federation:

when HTTP_REQUEST {
   Check the requested HTTP path 
   switch -glob [string tolower [HTTP::path]] {
      "/ews/mrsproxy.svc" -
      "/ews/exchange.asmx/wssecurity" -
      "/autodiscover/autodiscover.svc/wssecurity" -
      "/autodiscover/autodiscover.svc" {
      Disable APM for these paths
      pool Exchange2013_oa_pool7
      ACCESS::disable
      log local0. "Disabled APM enforcement for HTTP path: [HTTP::path]"
      }
   }
}

My iApp-generated configuration was using the Exchange profile in APM. My understanding is that the Exchange profile is just an easier-to-configure replacement for the _sys_APM_ExchangeSupport_OA_* iRules. I didn't know how to modify the Exchange profile so I replaced it with a modified iRule. I copied the _sys_APM_ExchangeSupport_OA_BasicAuth iRule and modified the copy to include these lines before the pre-existing "/ews/*" match:

     "/ews/mrsproxy.svc" {
         log local0. "OA_BasicAuth trigger for [IP::client_addr]:[TCP::client_port] -> [HTTP::path]"
         return
     } 
     "/ews/exchange.asmx/wssecurity" {
         log local0. "OA_BasicAuth trigger for [IP::client_addr]:[TCP::client_port] -> [HTTP::path]
         return
     } 
     "/ews/*/exchange.asmx/wssecurity" {
         log local0. "OA_BasicAuth trigger for [IP::client_addr]:[TCP::client_port] -> [HTTP::path]"
         return
     } 
     "/ews/*" {     pre-existing

I then added this new iRule to my VS and removed the Exchange profile in the access policy.

iRules attached to VS:

Exchange2013_AppCache  recommended by iApp
Exchange2013_OWA_redirect
Exchange2013_Federation  new from OP
mod_APM_ExchangeSupport_OA_BasicAuth  modified sys rule
Exchange2013_session_timeout  recommended bu iApp
Exchange2013_APM_combined  iApp original
Exchange2013_select_SSO  iApp originial
Exchange2013_MAPI  recommended by iApp