Forum Discussion

Jett2015_206058's avatar
Jett2015_206058
Icon for Nimbostratus rankNimbostratus
Jun 10, 2015

Need some expert advice F5 - 401 access denide - Exchange 2010

I need some help and am hoping someone can give me some direction.

 

We have an application running on a Windows server (Server A) that needs to synch information to an end user's calendar in Exchange 2010 via Autodiscover and EWS. The Exchange, F5, and "Server A" are all on the same subnet. We use an active directory account with elevated permissions on "Server A" with the impersonation role in Exchange to synch data to the end user mailboxes. We can get this to work to two other Exchange sites but not to our main Exchange site. The difference with the site that is not working is that it (2 mailbox servers/2 cas servers in a DAG) sits behind a F5 hlb. The F5 is running 11.4.1 hotfix 5 and we have a single vip with source-ip persistence that all Exchange traffic is being passed through. No SSL offloading being done on the HLB.

 

Outlook clients work fine (no issues there) but I cannot synch any calendar information from the application on Server A to the end user mailboxes if I am passing through the F5 HLB. I see a 401 access denied error in the logs. I know the AD account being used is correct and that the password is correct because I can get the application to synch to mailboxes on other Exchange sites (single servers with all exchange roles installed - no f5). The only way I have been able to get the application to synch is having our Exchange admin change the internal URL (for autodiscover and ews virtual directories) on the Exchange CAS server from the vip URL to the FQDN of the cas server. Obviously this is not want we want to do because it defeats the purpose of having load balancing and failover capability.

 

application delivery
BIG-IP Access Policy Manager (APM)
BIG-IQ
devops
exchange 2010
f5
iRules
security
  • Chase_Abbott's avatar
    Chase_Abbott
    Icon for Employee rankEmployee
    Jun 10, 2015

    We do something similar with a calendar application through 11.4 using EWS services; and it works but because we're SSL bridging so we can apply proper persistence to the different traffic patterns.

     

    RPC traffic behaves differently from EWS web traffic, which behaves differently from ActiveSync so when using the Exchange iApp or even just following a deployment guide, different profiles are applied to ensure the client receives the proper methodology for connectivity. If you're not decrypting the packets, the HLB is only operating at half effectiveness. I can only suspect that either the authentication is not making it all the way back, or we are seeing session resets as the vIP is designed for RPC traffic. You'll need to find out how the BigIP was setup, then probably we'll need to TCP dump the session at the BigIP and also at front end servers. From there, you can use Wireshark and the Exchange cert/key pair to decrypt and inspect the sessions.

     

    One trick is to disable one CAS pool member from the virtual IP so all session traffic goes to one box. This will A) make it easier to capture the tcpdump and B) would show us if it's a session issue bouncing between CAS servers.

     

    If the URL is publicly available, you can also see what testconnectivity.com shows for failure.