kerberos authentication: who am I?

So I'm not a big fan of STAS, NTML, SSO or heartbeat authentication. What can I say, I'm a hater. Anyway - kerberos has been introduced in this version but I don't really know how to "get it going". I've enabled the AD SSO authentication, enabled SSO under device access for LAN, disabled the STAS service on my DC and then done some testing. So far it just looks like NTLM standard browser authentication that only works in IE.

What's new, what should I expect from the new kerberos stuff?

Parents
  • The HowTo is quite simple:

     

    Create DNS Record on your DNS Server. 

    Create a DNS Request Route to your DNS Server

    (Windows: DNS Manager - DNS - Your Server - Forward Lookup Zones - Your Domain - Create new Host(A) XG(Hostname) XG Interface IP).

    Activate AD SSO in your Zones. 

    Activate AD SSO in Services - Web Authentication. 

    Create the AD Server on XG with Administrator Rights (or at least rights to read Kerberos and Add a Machine to AD). 

    Simply "save" the AD Server, if the server was already in place. 

     

    You should be able to resolve the hostname of XG (for example your XG Hostname is "XG"). XG needs to be able to do it. Try the Diagnostic DNS Lookup, put XG.domain.local and it should give you a lookup. 

     

    (At this time, the XG should self join the AD).

     

     

    Most of those steps are already done on most setups. 

     

    Maybe disable NTLM on the AD SSO Zone. 

    __________________________________________________________________________________________________________________

Reply
  • The HowTo is quite simple:

     

    Create DNS Record on your DNS Server. 

    Create a DNS Request Route to your DNS Server

    (Windows: DNS Manager - DNS - Your Server - Forward Lookup Zones - Your Domain - Create new Host(A) XG(Hostname) XG Interface IP).

    Activate AD SSO in your Zones. 

    Activate AD SSO in Services - Web Authentication. 

    Create the AD Server on XG with Administrator Rights (or at least rights to read Kerberos and Add a Machine to AD). 

    Simply "save" the AD Server, if the server was already in place. 

     

    You should be able to resolve the hostname of XG (for example your XG Hostname is "XG"). XG needs to be able to do it. Try the Diagnostic DNS Lookup, put XG.domain.local and it should give you a lookup. 

     

    (At this time, the XG should self join the AD).

     

     

    Most of those steps are already done on most setups. 

     

    Maybe disable NTLM on the AD SSO Zone. 

    __________________________________________________________________________________________________________________

Children
  • I appear to have made some positive progress from the notes above, thank you. The only thing that doesn't marry up and would be great - is the option to turn off NTLM, and just have kerberos, passing to captive portal if that fails.

    I don't even know if that makes sense, but if I browse on my domain joined machine, it looks great (with and WITHOUT proxy settings, which is interesting) - however if I browse on my none domain joined machine I'm getting an NTLM prompt , which is ugly, I'd rather the captive portal in this case. There is no option to untick "NTLM" under device access anymore, seems to be bundled with AD SSO.

     

    edit: ahh disable NTLM on the Zone, not the device access... I see. I'll try that in the coming days. Cheers.

    ------------------------------------------------

    worlds number one free ICMP monitoring platform: https://pinescore.com

  • LuCar Toni said:

    Maybe disable NTLM on the AD SSO Zone. 

    "Maybe?" Inside the user guide, nothing is mentioned about how to configure XG and Kerberos. Make sure to document how to configure XG with Kerberos on KB and even on documentation otherwise people get confused.

    Maybe is not the correct answer and it is strange that a feature is there and not even in Sophos they know how to implement it!

    I understand that we are in beta, but certain important features should be documented!

    Thanks

  • Maybe was about if you want to failover to NTLM or not. Depending on the setup. 

    Its like on the UTM, just auto joining. 

    Kerberos comes with the same limitations like on UTM. If you interacting with the XG as DNS(FQDN), it works fine. If you call XG with the IP, it could call NTLM instead of Kerberos. So thats the reason for having both running in the first place. 

     

    And again, i am here as a privat person, i am not even in the responsibility circle for XG V18. 

    You do not need to interpret my posts as "Its Sophos". I am just a somebody, who could spend more time with V18 and test certain thing to explain it to you. 

    Other people here are responsible to pick up your queries and bugs etc. 

    Maybe i should remove my tag... 

    __________________________________________________________________________________________________________________

  • This reply was deleted.
  • As always. Please place a Feedback on XG, that you need a kerberos documentation. 

    I was not aware, there was nothing in place, so i tried to help you. 

    __________________________________________________________________________________________________________________

  • Thans Lucar. I appreciate your help to find out but documentation is needed for both Sophos and US.

    I hope you understand my point and my concerns.

  • Thanks all for the feedback on this thread. I can see we need to revisit the documentation around this before GA.

    To address some of the points on this thread, here's a brief explanation of what our support for Kerberos involves.

    Under the hood, web-based authentication has three steps:

    1. There is the challenge from the firewall to the browser, requesting that the browser provide credentials.

    2. The firewall authenticates those credentials.

    3. If successful, the firewall caches the fact that the authenticated user is associated with that source IP

    This fundamental mechanism has not really changed in v18 from the method called 'NTLM' in v17.x.

    What has changed is in step 1, we support an additional way for the browser to provide the credentials, and in step 2, we can use that method to validate those credentials. In version 17.x, NTLM was the only protocol we supported, and in version 18, we support a hybrid challenge that allows the client to specify either NTLM or Kerberos credentials.

    Because the mechanism called 'NTLM' now supports more than just NTLM we renamed it 'AD SSO'. We also grouped it together with Captive Portal under the heading 'Web Authentication' because all those authentication methods work by capturing and redirecting web traffic and using the browser either transparently or interactively to provide credentials.

    The HTTP-defined method for challenging the browser for Kerberos credentials is via a challenge known as 'Negotiate'. This challenge fundamentally supports a range of different authentication protocols - NTLM, Digest, etc. To disable NTLM authentication, it is way better to disable it in the AD settings. Now that SFOS supports Kerberos, it is possible to do that. In version 17.x, we used a different challenge that was specific to NTLM.

    Configuring AD SSO (including Kerberos)

    1. When you join your XG to the AD server, it will do all it can to ensure that Kerberos will work, including setting a service principal name for itself in the Active Directory system. This does mean that the hostname of the device needs to be properly configured before joining, and the device needs to be configured to use its hostname when redirecting browsers to authentication challenges. This hostname-related stuff is configured in Administration > Admin settings.

    One you've set up the device host name, you can go through the additional steps:

    2. Configure the AD Server in Authentication > Servers

    3. Ensure your AD Server is set as the primary service for Firewall authentication methods under Authentication > Services

    4. Ensure AD SSO is enabled for the relevant zones in Administration > Device access

    5. Ensure that 'Kerberos and NTLM' is selected under Authentication > Web authentication

    Now, any web traffic that matches a firewall rule requiring authentication, and that is not already authenticated by this or another method, will be subject to AD SSO authentication, which will generally use Kerberos for preference.

  • Hi Richard,

    Thanks for the detailed explanation!

    In the UTM, and any kerberos keytab based system I've encountered, the keytab entries could become stale or fail to renew so therefore rejoining the domain is necessary. How is this done without deleting every AD server and remaking them?

    Additionally, does this mean that the user account used in the auth server must be capable of joining devices to the domain (traditionally a domain admin)?

    Follow up, after the domain join "process" has been completed, can the user be changed to a standard user for ldap/ad traversal and authentication only?

    Lastly, where can we observe the keytabs, is it a similar process outline for any linux based system that does kerberos/AD joins?

    I'm thinking of this as an ongoing support for future reference.

    Thanks in advance,

    Emile