Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

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

Environment

Exchange 2010 Org

Published Via TMG 2010

 

Exchange 2013 Org

Published via BIGIP VE LTM+APM

 

Outlook anywhere is configured for basic authentication on the CAS servers and iAPP

I'm currently trying to get exchange federation working between an Exchange 2010 org and an Exchange 2013 org.

The federation works fine if using LTM mode but not when using LTM+APM.

From the 2010 exchange cas server I am seeing 401 errors coming from the availability service when it trys to query free/busy data on the 2013 org.

I've used an irule to try and disable APM from authenticating  the connections similar to what is used for ADFS proxy endpoints, it is as follows(we do something similar with the TMG server to allow connections to authenticate directly with the cas servers)

 

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]"
}
}
}
 
I've placed the irule above _apm_combined_pool_irule7 and _sys_APM_ExchangeSupport_OA_BasicAuth
I am seeing the logs indicating the irule is getting hit but it doesn't seem to want to work.
 
Whats strange is that if I replace the _sys_APM_ExchangeSupport_OA_BasicAuth irule with _sys_APM_ExchangeSupport_OA_NtlmAuth the federation will start working but of course Outlook Anywhere will stop working.
 
I've configured the iAPP using the f5.microsoft_exchange_2010_2013_cas.v1.2.0rc1 template and Outlook Anywhere was set to basic authentication.
 
Anyone else got Exchange federation working via LTM+APM?
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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. :)
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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)
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Yes your right it still works when I remove ACCESS::disable from the modified irule and only have the return statement
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

Office365: Useragent: ASProxy/CrossForest/EmailDomain/*

Good Luck

wiesmann

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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
0