Hi Brazzo Any luck with forcing Kerberos to use TCP instead of UDP? If that helps to fix the error related to "KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG"

learn.microsoft.com/.../force-kerberos-use-tcp-instead-udp

Hi. Yes, I already tested this but the problem still occures

Sorry. The error did not occure in wireshark but users are still not authenticated by kerberos

Hi Brazzo Thanks for the latest feedback, now the previous error not there further I would suggest checking the logs on XG As per the below guides:

https://docs.sophos.com/nsg/sophos-firewall/20.0/Help/en-us/webhelp/onlinehelp/index.html?contextId=authentication-ad-sso

https://docs.sophos.com/nsg/sophos-firewall/20.0/help/en-us/webhelp/onlinehelp/AdministratorHelp/Authentication/TroubleshootingAuthentication/index.html#ntlm-and-kerberos-troubleshooting

Sophos Firewall: Kerberos authentication does not work
https://support.sophos.com/support/s/article/KB-000044647?language=en_US

If the above steps do not help or do not give a clue on why Kerberos Auth failing then would suggest opening a support case to investigate it further! 

Thanks. It seems that all is correctly configured. But....... when the ntlm login appears and I authenticate a user, on firewall in "Live Users" that the user is authenticated by AD SSO Kerberos

Can you please tell me why from the firewall kerberos requests with upn SOPHOSC7BFE3$ are coming?

Kerberos authentication does not cause any traffic from the XG to the AD server.  I'm not sure what is causing the error.

What follows is a DRAFT of a possible future KB/documentation/something.

How does Kerberos work

A brief (and not exactly accurate) summary of how Kerberos works.

A computer (XG) joins to the AD domain and registers as "HTTP" (meaning it has a web server). The AD server tells the computer "if anyone wants to send you a encrypted Kerberos ticket, here is a custom way of how to decrypt it" for the HTTP service. The AD server stores an SPN (Service Principal Name) for that computer (using the AD name for the computer) and that service (HOST and HTTP).

A computer (Windows) joins to the AD domain. The AD server tells the computer "Here is a list of SPNs for this domain, including which ones are registered for the HTTP service” as well as instructions on how to encrypt a ticket for each SPN (every SPN has a different encryption).

Now the Windows computer goes to a website, lets say randomcomputer.mycompany.local. The server randomcomputer.mycompany.local says "Please authenticate, I support Kerberos". The window computer says "randomcomputer.mycompany.local is not in my list of HTTP SPNs, therefore the AD server has told me not to use Kerberos on it" and therefore will not do Kerberos authentication.

Now the Windows computer goes to a website, lets say myxg.mycompany.local. The XG says "Please authenticate, I support Kerberos". The window computer says "myxg.mycompany.local is in my list of HTTP SPNs, therefore I will encrypt my ticket with the encryption that is for that server". It sends the encrypted ticket to the XG. The XG decrypts the ticket, and inside the ticket is the name of the user. The XG says "Because I was able to decrypt the ticket using this special encryption I got from the AD server, I know for sure the user connecting is also from this AD server since no one else could encrypt this way". Even though there is no password sent and the XG never checks with the AD server, it knows that the user is who they say they are.

This means that a Windows computer that gets a list of SPNs will only ever authenticate Kerberos to an HTTP service in that SPN list. In fact, the Windows computer cannot even encrypt a ticket for a server not on the SPN list.

In most scenarios, if a browser does not trust enough to send Kerberos (eg no matching SPN) then it looks to see if it trusts to send NTLM. If it does not trust to send NTLM either it will do a browser pop up asking for username and password or it will skip NTLM as well, and the XG sends them to captive portal.

You can Google how Kerberos works for a much more detailed and accurate technical description.

Clients are not choosing to use Kerberos

Assumption: The XG is properly connected to the AD server. Client are currently using NTLM.

In order for for Kerberos to work the HTTP SPN that was created by the AD server is vitally important.
In transparent mode, the redirection url (Administration > Admin and user settings) must be set to match the SPN including capitalization. In direct mode the browser configured proxy must match the SPN.

Find out the SPN that the box has been given by the AD server
On a windows box connected to AD:
setspn -Q HTTP/*

You should only see records that start HTTP mean these are records for HTTP proxies.

You should see an entry like this:

HTTP/myxg.MYCOMPANY.LOCAL

Change the redirection URL or configured proxy to be that value including capitalization.
Make sure that location is dns resolvable by the XG and by clients.

In rare cases (likely some security policy being implemented) Kerberos needs a similar config to NTLM in the browsers.
https://support.sophos.com/support/s/article/KB-000035856?language=en_US
For Edge/Chrome is should be a trusted site.  For Firefox add to network.negotiate-auth.trusted-uris

If you have an HA the primary does a Join with the hostname of the cluster.  The auxiliary does a Join with SOPHOS[random].  After that, the primary sync's the Kerberos ticket to the Aux.

There are known issue with the synchronization, which means during failover you might see SOPHOS[random] being tried and failing.  There will be improvements to this is 20.0 MR2.