Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 28 subscribers
  • Views 5571 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

Captive Portal NTLM Authentication IPv6

benny4982

Hi,

we try to get the NTLM Authentication for the clientless captive portal working.
For IPv4 it runs pretty well. So if we goto a website with only IPv4 enabled no authentication page is presented and the user is logged in via NTLM.

But if we open a IPv6 site, for example www.google.com we get the captive portal login page.
When entering the credentials everything works as expected and the IPv6 Adress is shown in Liveusers.

But it seems NTLM is not working.

So why ? :)



This thread was automatically locked due to age.
Parents
  • 0
    Don't worry, LuCar - I'm a fan of NTLM.  :)
    We do not regularly test NTLM in an IPv6 environment, though we did last July.  It should work.
     
    First thing to note is the IPv6 wireshark that you posted appears to be going to Microsoft.  Depending on how you are configured, the default Web Exception for policy checks means that you can go there without authentication.  Or you might already have been authenticated.  In either case, there was no authentication performed (NTLM or Captive Portal).
     
    Lets back up and briefly explain how it works:
    With NTLM when there is no currently logged in user it will authenticate the first request.  It then caches that user for four minutes, after which it will try to authenticate again.
     
    If you are trying to capture the authentication:
    Close all browsers/tabs except one (ideally one that does no background traffic, such as www.example.com).
    Under WebAdmin, Current Activities, Live Users, Disconnect the current user on that IP.
    On the browser perform a full refresh (eg no load from cache)
     
    What you should see is what you posted in the first.
    www.ard.de does a 307 redirect to 192.168.168.1/ntlmauth.html
      Note: By default it uses the IPv4 address of the first non-WAN interface.  If there are no IPv4 interfaces it uses the first IPv6 interface.
    There is a three message handshake.
    After success it does a 307 redirect to the original site again.
    If it fails it does a redirect to the captive portal (using the same IP in the URL as it did for NTLM).

    In IPv6 this does not change.  You can be using an IPv6 client and try to load an IPv6 web page.  You will be redirected to an IPv4 address hosted on the firewall, do authentication, and be redirected back to the original site.
    If you are seeing a captive portal page, I can think of one of three issues:
    1) It did not even try NTLM, instead going directly to Captive Portal.
    2) If tried to redirect to NTLM but could not resolve or had some error.
    3) It tried NTLM, failed to authenticate with the username/password, and redirected to Captive Portal.
     
    One issue with NTLM (possibly one of the things that irks LuCar) is that depending on what process did the web request, sometimes it tries to log in with the system account, not the logged in users account, which fails.
     
    Can you carefully (as above) try to do a capture of the request in IPv6, including it sending to the captive portal?
Reply
  • 0
    Don't worry, LuCar - I'm a fan of NTLM.  :)
    We do not regularly test NTLM in an IPv6 environment, though we did last July.  It should work.
     
    First thing to note is the IPv6 wireshark that you posted appears to be going to Microsoft.  Depending on how you are configured, the default Web Exception for policy checks means that you can go there without authentication.  Or you might already have been authenticated.  In either case, there was no authentication performed (NTLM or Captive Portal).
     
    Lets back up and briefly explain how it works:
    With NTLM when there is no currently logged in user it will authenticate the first request.  It then caches that user for four minutes, after which it will try to authenticate again.
     
    If you are trying to capture the authentication:
    Close all browsers/tabs except one (ideally one that does no background traffic, such as www.example.com).
    Under WebAdmin, Current Activities, Live Users, Disconnect the current user on that IP.
    On the browser perform a full refresh (eg no load from cache)
     
    What you should see is what you posted in the first.
    www.ard.de does a 307 redirect to 192.168.168.1/ntlmauth.html
      Note: By default it uses the IPv4 address of the first non-WAN interface.  If there are no IPv4 interfaces it uses the first IPv6 interface.
    There is a three message handshake.
    After success it does a 307 redirect to the original site again.
    If it fails it does a redirect to the captive portal (using the same IP in the URL as it did for NTLM).

    In IPv6 this does not change.  You can be using an IPv6 client and try to load an IPv6 web page.  You will be redirected to an IPv4 address hosted on the firewall, do authentication, and be redirected back to the original site.
    If you are seeing a captive portal page, I can think of one of three issues:
    1) It did not even try NTLM, instead going directly to Captive Portal.
    2) If tried to redirect to NTLM but could not resolve or had some error.
    3) It tried NTLM, failed to authenticate with the username/password, and redirected to Captive Portal.
     
    One issue with NTLM (possibly one of the things that irks LuCar) is that depending on what process did the web request, sometimes it tries to log in with the system account, not the logged in users account, which fails.
     
    Can you carefully (as above) try to do a capture of the request in IPv6, including it sending to the captive portal?
Children
  • 0 in reply to Michael Dunn

    I should mention Administration \ Admin Settings \ Admin console and end-user interaction.

    This will display the IPv/IPv6 that it will redirect to for NTLM and Captive Portal.  For debugging right now, leave it at using the IP - however you can force it to use a specific IP or a hostname (which you are then responsible for resolving to the IP4/6 you want).

  • 0 in reply to Michael Dunn

    Hi Michael,

    thanks for the response.
    I give it a try and do some troubleshooting.
    We are on Firmware 17.1.3 - so the enduser interaction ist not visible on the webinterface.
    But we have done the configuration on the commandline, so it redirects to the hostname of the firewall.
    The necessary records A and AAAA are in place.
    Let me know if we should upgrade to 17.5 for further testing.

    Best regards

    Benny

  • 0 in reply to benny4982

    Update:

    As far as i can see Internet Explorer does not even try to do ntlm on IPv6 Websites.
    (No NTLM Packages in Wireshark)
    Already checked the security settings in Internet Explorer, did not see any special settings for IPv6. For IPv4 it is working.
    The first Interface has a IPv6 and IPv4 Adress , both of them are reachable.

  • 0 in reply to benny4982

    benny4982 said:

    Update:

    As far as i can see Internet Explorer does not even try to do ntlm on IPv6 Websites.
    (No NTLM Packages in Wireshark)
    Already checked the security settings in Internet Explorer, did not see any special settings for IPv6. For IPv4 it is working.
    The first Interface has a IPv6 and IPv4 Adress , both of them are reachable.

    First of all, IE does not do any NTLM against websites (eg far servers) at all, whether the server is IPv4 or IPv6.

    IE gets redirected to the local XG (using hostname as you have configured it) and will connect via IPv6 or IPv4 according to how you have your DNS resolution.

     

    Therefore you could be going to an IPv4 website, need to be authenticated, be redirected to the XG, resolve that to an IPv6 address, and then do NTLM with IPv6.

    Whether the destination website (eg google.com) uses IPv4 or IPv6 does not matter.  How it connects to XG matters.

     

    Next, if NTLM fails or is skipped then you should see a Captive Portal.  If you are not seeing a Captive Portal that means that either a) NTLM worked or b) you did not need to be authenticated.  You only need to be authenticated every four minutes, you can disconnect the user in WebAdmin Live Connections to force it to authenticate.

  • 0 in reply to Michael Dunn

    OK, perhaps i have expressed myself incorrectly.

    What i mean was enable NTLM authentication in IE:
    https://community.sophos.com/kb/en-us/123362

    To sum up whats happening at the moment:

    We have an internal hostname (firewall.domain.de) which resolves to IPv4 and IPv6 internal address of the XG.

    if i open IE on a computer with the following startpage: www.ard.de (which only resolves to IPv4)
    the redirect happens and the local users is authenticated with ntlm.

    Now i change the startpage to www.example.com (which resolves also to IPv6)  and close the browser.
    After that i disconnect the user on the XG (only see the IPv4 address on the live users).

    When i open the browser it redirects me to the captive portal, no ntlm is happening.
    Entering an IPv4 only domain (www.ard.de) ntlm is happening and no captive portal is displayed.
    Entering www.example.com , captive portal is displayed, even if ntlm has happend for the IPv4 site.

    So if i understand you clearly it should be no difference if i call an IPv4 or IPv6 site.
    Because the magic happens only internal.

    So finally i don't understand why it is not working when i call Websites who have an AAAA Record. Especially in this case no redirect happens in the tcpdump.

     

    Update 10:47:

    After Reboot of both XG i get the following screen when opening a website which has AAAA Records:

  • 0 in reply to benny4982

    Thanks for the details reply, it is very helpful.  I was sure there was some miscommunication going on.

     

    Can I get a packet capture of the failing case?  Live Connections has nobody.  Open example.com.  End with either the Captive Portal or too many redirects.

    In addition, on the XG can you tell me the contents of:

    cat /cfs/proxy/skein/localinterfaces

    And tell me what the A and AAAA records are for the XG.

    You can PM me the details, no need to post them all here.