AD SSO over Kerberos not working

Question

Hello, 
 I have done a setup with a clsuet of 3300 appliances. 
 For authentication I have configured an active directory domain controler, joined the domain, imported the groups and activated AD SSO on the zones. 
 In Auth-Log the NTLM and Kerberos channel are successfuly shown but when a client tries to go to an webpage, the authentication windows appears for authentication over NTLM. No clients can authenticate over kerberos. 
 On the domain controller I run wireshark and I see the requests from firewall to the dc. But the answer of the domain controller is the following 
 KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG 
 The udp packet lenght is between 188 and 295 byte. I'm sure, that is not too big. I was hoping that the problem could be resolved by increasing the value for the max packet size for kerberos like on this page but it did not help. 
 Does anybody know a solution for this? 
 
 Thanks

Michael Dunn · Accepted Answer

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&rdquo; 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

Vishal_R · Answer

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!

Michael Dunn · Answer

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.

AD SSO over Kerberos not working

Top Replies