kerberos authentication: who am I?

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. 

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... 

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.

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