Forum Discussion

Vsevolod_Petrov's avatar
Vsevolod_Petrov
Icon for Cirrostratus rankCirrostratus
Oct 14, 2014

Exchange 2013 session affinity. Once again.

Hello!

There are two CAS servers and BIG-IP 11.5.1 HF5 on the front of them.
I'm using an iApp for MS Exchange 2010 and 2013 version 1.4.0 (LTM only, No APM).

I've already read the deployment guide along and across, but still have a problem with Outlook Web App clients.

Exchange 2013 doesn't require any persistence even if deployed with L7 load balancer.
But when the client goes to mail.example.com/owa and inputs a username and password he is being redirected /owa/auth/logon.aspx again and again.

In my setup both CAS servers have the same SSL certificates installed. SAN (Subject Alternative Name) corresponds to the hostname of each CAS server.

Client SSL profile uses the same SSL certificate and key as CAS servers.
Server SSL profile was built from default serverssl without any changes.

What am I missing? 

If I put persistence profile on the VS everything works fine but it's not necessary.
Maybe something wrong with Exchange setup?

Please, help me, I much appreciate your support!
APM
application delivery
deployment
devops
iApps
LTM
microsoft
security

11 Replies

Sort By
  • PeteWhite's avatar
    PeteWhite
    Icon for Employee rankEmployee
    Oct 14, 2014
    I'm confused as to why you say that you don't need a persistence profile. My understanding is that for OWA the user authenticates to the server via either forms or NTLM and accesses their mailbox from that server - login details are not shared between CAS servers as far as I understand. Have you tried doing a tcpdump to see what is actually happening? If not then it might be worthwhile. I should imagine that what is happening is that, with no persistence, the user is starting a session and authenticating to a server, then being loadbalanced to a different server on the next session and is asked to sign in again.
  • Vsevolod_Petrov's avatar
    Vsevolod_Petrov
    Icon for Cirrostratus rankCirrostratus
    Oct 14, 2014

    Hi Pete,

    Thanks for response!

    I've considered that persistence profile is not necessary for Exchange 2013 from this technet article. 

    Unlike previous versions of Exchange, Exchange 2013 no longer requires session affinity at the load balancing layer.

    Exchange 2013 could be load balanced at Layer 7 as well as at Layer 4.

    There is also an iRule in the deployment guide for the 2013 that doesn't apply persistence unlike the 2010 one. 
    2013:
"/owa*" {
  Outlook Web Access
 pool owa_pool_name
 return
 }

2010:     
 "/owa*" {
  Outlook Web Access
 if { [HTTP::header exists "APM_session"] } {
 persist uie [HTTP::header "APM_session"] 7200
 } else {
 persist cookie insert timeout 0
 }
 pool owa_pool_name
 return
 }

    So, it makes me thinking that there is no need in persistence profile.

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Oct 14, 2014

    Hi zup, you are correct that persistence is not required for Exchange 2013.

     

    When you say "SAN (Subject Alternative Name) corresponds to the hostname of each CAS server", you also have the load-balanced FQDN added to the SAN list as well, correct? This would be the same FQDN you have defined for the external/internal URL in OWA virtual directory settings.

     

    I would like to see the request and response from your login attempt.

     

    thanks

     

  • Vsevolod_Petrov's avatar
    Vsevolod_Petrov
    Icon for Cirrostratus rankCirrostratus
    Oct 14, 2014

    Hello mikeshimkus,

     

    There're the following SAN records in the SSL certificate:

     

    * DNS:mail.example.com

     

    * DNS:cas1.example.com

     

    * DNS:cas2.example.com

     

    This certificate is installed on both CAS servers and I use it in the Client SSL Profile as well.

     

    I'll get back to you with request and response shortly.

     

    Thanks!

     

  • Vsevolod_Petrov's avatar
    Vsevolod_Petrov
    Icon for Cirrostratus rankCirrostratus
    Oct 14, 2014

    While fiddlering those requests and responses I've found the following:

     

    For "POST https://mail.example.com/owa/auth.owa HTTP/1.1" (with username, password and so on)

     

    I receive "HTTP/1.1 302 Found" that redirects me to https://mail.example.com/owa/ (with X-FEServer: CAS1)

     

    But instead of /owa/ and useful content I get "HTTP/1.1 302 Found" to https://mail.example.com/owa/auth/logon.aspx?url=https%3a%2f%2fmail.example.com%2fowa%2f&reason=0 (with X-FEServer: CAS2)

     

    So, I've got responses from different CAS servers.

     

    Don't know why...

     

    • mikeshimkus_111's avatar
      mikeshimkus_111
      Historic F5 Account
      Oct 14, 2014
      Assuming you're using the same cert for IIS services on both CAS, which you say you are, I'm not sure what could be going on here. It's as if the servers don't know that they are part of the same Exchange deployment. This post explains why persistence is not required: http://theucguy.net/exchange-server-2013-load-balancing/ "The user connection is authenticated by any one of the 2013 CAS servers. The CAS issues an authentication token (cookie) with session keys and other info and the cookie gets encrypted using the public key of the SAN cert on the CAS server. The OWA client hands the cookie to the server with any new requests. In this case, it doesn’t matter if the new request is handled by a different CAS server, as that server is capable of decrypting the cookie with it’s private key, as all CAS servers have the same certificate. As the authentication cookie is successfully decrypted irrespective of which CAS 2013 server it hits, the user or client is not challenged to authenticate again with an FBA page." Your CAS both have an identical private key that corresponds to the cert you're using for IIS services, correct?
  • Vsevolod_Petrov's avatar
    Vsevolod_Petrov
    Icon for Cirrostratus rankCirrostratus
    Oct 16, 2014

    Yes, correct about certs and keys.

     

    I've spent an hour with our Exchange guy and we concluded that the possible reason is wrong authentication setup on the CAS servers.

     

    So, decided to proceed with this article http://technet.microsoft.com/en-us/library/ff808312(v=exchg.150).aspx again.

     

    Thanks mikeshimkus, I'll be back with results.

     

  • Vsevolod_Petrov's avatar
    Vsevolod_Petrov
    Icon for Cirrostratus rankCirrostratus
    Nov 11, 2014

    It may be helpful for those who have similar issue. Finally the problem was with SSL certificates. I didn't notice the difference in Serial numbers.

     

    Remember, it must be the same SSL cert on all of your CAS servers.

     

    Thanks Mike ;)

     

  • James_Noad's avatar
    James_Noad
    Icon for Nimbostratus rankNimbostratus
    Apr 16, 2018

    Confirming Vsevolod Petrov's solution. We had four CAS backends, one of which had the certificate updated. Thereafter OWA sessions did not work properly - going back to the login screen and including a HTTP "440 Login Timeout" error in the process of getting there.

     

    Test each backend with: echo | openssl s_client -connect cas1:443 | openssl x509 -noout -serial -dates -subject and ensure that the output is identical.