Exchange 2013 co-exsting with Exchange 2007 Prompting Clients for Authentication

Are you doing pre-auth on the f5? And what is the current config for your VS

No, there is no pre-auth happening on the F5. What specifically are you looking for regarding our current VS config?

Run Tmsh list ltm vitual vs_****

And all the profiles attached to the vs usually some of these problem occur as a result of a optimization profile

Hi, which version of the Exchange iApp did you use to set up your deployment? Are you getting the prompts for both 2007 and 2013 users?

thanks

Mike - We used f5.microsoft_exchange_2010_2013_cas.v1.4.0 as the Exchange iApp version. We are getting this for both 2007 and 2013 users.

OK. You'll need to do a tcpdump or Wireshark capture on the server side to determine which requests are causing the prompts. Should be relatively easy since you're offloading SSL and don't need to decrypt those connections.

What specifically are you looking for? We used Fiddler on the client side and saw a lot of 401's coming back for Autodiscover.

Can you post the headers for that request and response here? What auth scheme is your Autodiscover configured to use? Are the 401s coming from the same CAS that the original request went to, or a different one?

There's a section of the pool assignment iRule created by the iApp that works around repeated auth prompts for Outlook clients by disabling OneConnect and the NTLM profile. I'm wondering if it could apply in your case, with a change of criteria:

when HTTP_RESPONSE {
    if { [string tolower [HTTP::header values "WWW-Authenticate"]] contains "negotiate"} {
        ONECONNECT::reuse disable
        ONECONNECT::detach disable
        NTLM::disable
    }
        if {[HTTP::header exists "Transfer-Encoding"]} {
        HTTP::payload rechunk
    }
} 

We have this exact code within our iRule already. Here is the information contained in the headers (1st two are the 401's and the last one is the 200) for autodiscover. The auth scheme for autodiscover is Basic, Windows Auth and oAuth.

(1) ------------------------------

HTTP/1.1 401 Unauthorized

Cache Cache-Control:private Date:Mon, 24 Nov 2014 17:59 GMT

Cookies / Login Proxy-Support: Session-Based-Authentication WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic real="autodiscover13.yyyyyy.com"

Entity Content-Length: 0

Miscellaneous request-id: fd058829-34ca-44fa-93d4-33f2d4294a7 Server: Microsoft-IIS/8.5 X-AspNet-Version: 4.0.30319 X-CasErrorCode: UnauthenticatedRequest X-FEServer: CAS01 X-Powered-By: ASP.NET

(2) ------------------------------

HTTP/1.1 401 Unauthorized

Cache Date:Mon, 24 Nov 2014 17:59 GMT

Cookies / Login Proxy-Support: Session-Based-Authentication WWW-Authenticate: Negotiate <> WWW-Authenticate: NTLM WWW-Authenticate: Basic real="autodiscover13.yyyyyy.com"

Entity Content-Length: 0

Miscellaneous request-id: 5080f396-3446-4740-9396-f166529dc15b Server: Microsoft-IIS/8.5 X-FEServer: CAS03 X-Powered-By: ASP.NET

(3) ------------------------------

HTTP/1.1 200 OK

Cache Cache-Control:private Date:Mon, 24 Nov 2014 17:59 GMT Vary: Accept-Encoding

Cookies / Login Persistent-Auth: true Set-Cookie: X-BackEndCookie=<>;path=/Autodiscover; HttpOnly

Entity Content-Length: 4552 Content-Type: text/xml; charset=utf-8

Miscellaneous request-id: 0d4a2df9-9085-4dd0-b16d-44df3cfad488 Server: Microsoft-IIS/8.5 X-AspNet-Version: 4.0.30319 X-BEServer: CAS08 X-CalculatedBETarget: CAS09 X-DiagInfo: CAS08 X-FEServer: CAS03 X-Powered-By: ASP.NET

OK, we're seeing the Negotiate auth header, so that iRule should kill OneConnect for the connection.

If you disable all but one CAS in the Autodiscover pool, do you still get the 401s?