Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 28 subscribers
  • Views 14920 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Outlook Anywhere & NTLM Authentication

Shaun Raven

Hi everyone,

I'm currently evaluating XG and I've run into a big problem - I just CAN'T get Outlook Anywhere with NTLM authentication to work through WAF.  I have OWA and Autodiscover working fine, but I'm not able to establish a connection using Outlook.  If I just DNAT all HTTPS traffic to the Exchange, everything is fine - if I then switch the rules over, outlook is STILL fine (so existing connections are ok, it's just establishing the RPC connection that causes the problem).

 

I've had this working with the Network Guy's method as described at https://networkguy.de/?p=998, but I can't seem to translate that to XG.  Changing the authentication method is not an option.

 

Has anyone managed to do this successfully?



This thread was automatically locked due to age.
Parents Reply
  • 0 in reply to FloSupport

    Hi,

    Yes, I've tried the various methods mentioned - the best I can get is everything except Outlook Anywhere working.

    When I was setting up our UTM's the network guys post I mentioned before was the only thing that really worked for us, so I've tried to focus on replicating that.  I currently have one rule for publising autodiscover, one rule for everything else.  Enclosed is a PDF of the settings I'm using.  As before, everything APART from Outlook Anywhere works fine.  Can anyone see anything odd?

     

      6712.exchange.pdf

     

Children
  • 0 in reply to Shaun Raven

    Ok - I've narrowed down the problem - and I think it's to do with autodiscover.

     

    If I just pass everything through, autodiscover works fine.  if I try to publish autodiscover, it fails.  When I try and create the rule, I often get...

     

    The certificate is a self-signed one with multiple SA's, that works fine with TMG/UTM publishing, and obviously works if the exchange server is published via DNAT. 

     

    Why would the rule argue about the certificate?

  • 0 in reply to Shaun Raven

    Hey Shaun,

    From your initial post, you mentioned that Autodiscover was working, did something change in your configuration? I noticed from your rule configuration, that you had 2 separate rules (rule ID 4 and 5) covering the same 443 port? Your rule ID 5 may not be matching to any traffic as the other rule may be taking precedence. What are you able to observe using the Packet Capture tool when testing Autodiscover? Please feel free to PM me if you would like to share any information or screenshots that would not like to post publicly.

    Regards,

    FloSupport | Community Support Engineer

  • 0 in reply to FloSupport

    Hi,

    I think I was mistaken when I thought it was working.

    What I've done now is to remove all rules and just concentrate on getting autodiscover to work.  I therefore have just the one rule at present, and that's the rule that causes my problem.  I've tried using the predefined autodiscover rule (with authentication set to none), and my own custom one which has no path mapping - each one gives me the same error with the certificate.  I'm assuming that the rule breaks the SSL connection because it argues about the autodiscover part of the certificate.

    My user's email address would be test1@xxx.yyy.com

    I'm using xxx.yyyy.com as the domain, so I have that in the certificate plus autodiscover.xxx.yyyy.com.

     

    Interesting what you said about multiple rules on the same port.  Does that mean that the best way to work with exchange on one IP is to have one rule then?

  • 0 in reply to Shaun Raven

    Ok - I'm almost certain this is down to XG rejecting the certificate - I just don't understand why.

     

    If I create the rule from scratch, I get no warning.  If I then try and change the rule, I get the warning that the domain will not be covered by the certificate - what gives????

  • +1 in reply to Shaun Raven

    OK, after submitting this problem to support, and almost 4 months of escalations, we finally have this working in our test environment.

    The problem is basically in 2 parts.  The first part is the inability of XG to use certificates in firewall rules that have mixed case strings.  As most of us know, when Exchange creates a certificate request it creates a subject alternative name that usually includes "AutoDiscover.(...).com".  In XG, if you try and use a certificate like this, the "Autodiscover" entry is rejected by the reverseproxy publishing, so your Autodiscover site is not published.  As of 17.0.6 MR6 this is still an issue, but the workround is to create a certificate on XG with the autodiscover name in lower case.  This does work, but you have to trust the XG as a full Certificate Authority.  I'm going to try it on the latest firmare today, and let you know what happens.

    The second part is down to TLS handshaking.  Outlook uses WINHTTPS as it's method to talk to Exchange.  In Windows 7, this uses TLS v1.0 which XG REALLY doesn't like.  This causes the TLS handshake to fail.  Windows 10 uses TLS v1.2 (which XG supports) and so the TLS handshake works.  The answer then, is to...

    A) Either switch to using windows 10 on your client PCs

    b) Change your Windows 7 client to use TLS v1.1 or higher when using WINHTTP.  You can use the steps at https://blogs.technet.microsoft.com/schrimsher/2016/07/08/enabling-tls-1-1-and-1-2-in-outlook-on-windows-7/ to do this, but essentially it's just a case of making sure you have a particular patch installed and some registry keys entered.  EXchange supports TLS 1.0 through to TLS 1.2 at least, so you shoudln't have to change anything there.

     

    That's it - hope this helps someone.

  • 0 in reply to Shaun Raven

    Well ...

    Mechanism to downgrade automatically from TLS 1.2 down to TLS 1.0 when need be have been documented for at least a decade now.  Softwares should handle it.  Users should never be involved in that process.

    What you propose may work, but it is not a solution, it is a workaround.

  • 0 in reply to Big_Buck

    Indeed.  XG should be able to handle it - UTM can, and does.