Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 40 subscribers
  • Views 799 views
  • Users 0 members are here
Options
Suggested

AD SSO over Kerberos not working

Brazzo

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 



Added TAGs
[edited by: Raphael Alganes at 9:06 AM (GMT -7) on 18 Jun 2024]
Parents
  • +1

    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

Reply
  • +1

    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

Children
No Data
Unfiltered HTML