Set up Kerberos in v18?

Is there any additional configuration needed to enable Kerberos authentication in v18?  I got a failure message on upgrade startup in the log viewer: Cannot initialize Kerberos authentication with domain." but have not been able to figure out how to troubleshoot it further.  Documentation doesn't seem to mention anything.  Thanks in advance.

  • Bill,

    Which steps did you perform?

  • Actually Kerberos will perfom a Auto Join if "everything is setup correctly". 

    You need to: 

    Have a Request Route from XG to your AD.

    AD Server setup properly.

    AD SSO enabled in the Zone of Client.

    XG Hostname needs to be resolvable on your AD (example: Hostname "XG". Domain "test.com". XG.test.com needs to point to the XG.) 

     

    Here is a Thread in EAP Forum: https://community.sophos.com/products/xg-firewall/sfos-eap/sfos-v18-early-access-program/f/feedback-and-issues/118421/ntlm-kerberos-authentication

  • In reply to LuCar Toni:

    Hi LuCar, thanks for that.

    So I verifed that XG "joined" the AD automatically, and if I do a SetSPN query I see the two entries as Michael Dunn stated should be there.  XG hostname is resolvable in points to the XG.  AD SSO is enabled on the zone.  NTLM is successful.  Still, XG log viewer reports an error with Kerberos.  Unfortunately it doesn't provide anything in the way of useful information (maybe in version 26 the log viewer will be useful).  

  • In reply to Bill Roland:

    Could you show us the Screenshot of the Log viewer? Plus please the advanced View in Logviewer. 

  • In reply to Bill Roland:

    Bill Roland
    Hi LuCar, thanks for that.

    Still, XG log viewer reports an error with Kerberos.  Unfortunately it doesn't provide anything in the way of useful information (maybe in version 26 the log viewer will be useful).  

    I agree with Bill. The other day I was getting mad to find why XG was blocking traffic and even the advanced shell did not help.

    Logging needs to be improved a lot.

    Bill do you see any logs from advanced shell?

    Tail - f /log/*.log

  • In reply to lferrara:

    Maybe  can help here? 

  • In reply to Bill Roland:

    Bill,

    do you find some useful log inside /log/access_server.log ?

    If not, try to put the access_server service in debug mode, perform the authentication attempt while tail -f /log/access_server.log is going...

    Let us know.

    Michael Dunn is the best person to help for this issue.

  • In reply to Bill Roland:

    We got very little feedback about AD SSO in the v18 EAP, which we hope means that there are few problems with it. :)

    I have not seen that particular error before.
    It is curious that you get an error but the SPN are created.

    Did you get any other authentication configuration messages?
    Is it repeatedly putting the error in the log or just once?
    Do clients attempt to do AD SSO? They might skip AD SSO and go to Captive Portal if the system thinks it is not correctly configured.
    What is logged in Log Viewer when clients try to authenticate?

    The relevant log file for AD SSO (NTLM and Kerberos) is /log/nasm.log and not /log/access_server.log.

    If you want I can look at your box yourself to see if I can determine the cause. We need access to your box using a support tunnel. This will grant us secure access to WebAdmin and command line. It does not expose your box to the internet.

    Please go to Diagnostics > Support access and turn on. After a moment the page will refresh with an Access ID. You can change how long until the support tunnel is automatically closed, however it is recommended to have open a week or more. You can always disable yourself when the issue is resolved. Please send me the Access ID.

  • In reply to Michael Dunn:

    Michael Dunn

    The relevant log file for AD SSO (NTLM and Kerberos) is /log/nasm.log and not /log/access_server.log.

    Thanks Michael.

  • In reply to lferrara:

    nasm looks at AD configuration and joins the AD domain for Kerberos and sets up a communication channel for NTLM, then sends a message to awarrenhttp and snort (DPI) that AD SSO is available.
    awarrenhttp or snort (DPI) determines that a connection should be authenticated with AD SSO and forwards to port 8091
    port 8091 is always handled by awarrenhttp, which asks for NTLM/Kerberos credentials
    awarrenhttp takes the credentials from and sends them to nasm.
    nasm will validate the kerberos ticket or 3-way NTLM messages with the AD server
    nasm tells awarrenhttp that the connection is authenticated with a specific user
    awarrenhttp tells access_server that a user is authenticated and asks if the user is authorized
    access_server says the user is authorized, and now associates that IP with that user

    With AD SSO, awarrenhttp is responsible for the communication with the client, nasm is responsible for communication with the AD server, and access_server is responsible for seeing if user has permission to log in and tracking who is logged in.

     

    In this case, if nasm does not think it is configured to AD properly it won't tell the rest of the system that AD SSO is available and the rest won't occur.

  • In reply to Michael Dunn:

    Looking at this, it appears that the problem is caused by a missing keytab?

    XG135_XN02_SFOS 18.0.0 GA-Build321# grep kerberos /log/nasm.log
    Feb 18 13:45:43.359438 [nasm] initialize_kerberos(): realm = BEYERSFHC.COM
    Feb 18 13:45:43.431084 [nasm] initialize_kerberos(): gss_acquire_cred HOST/SOPHOS-XG135-OB@BEYERSFHC.COM: Key table file '/etc/krb5.keytab' not found
    Feb 18 13:45:43.431443 [nasm] setup_channel(): unable to initialize kerberos
    Feb 19 16:15:51.059327 [nasm] close_kerberos
    Feb 19 16:15:51.059343 [nasm] close_kerberos(): deinitialized kerberos successfully
    Feb 19 16:16:04.348699 [nasm] initialize_kerberos(): realm = BEYERSFHC.COM
    Feb 19 16:16:04.355489 [nasm] initialize_kerberos(): gss_acquire_cred HOST/FW-XG135-OBO@BEYERSFHC.COM: Key table file '/etc/krb5.keytab' not found
    Feb 19 16:16:04.355575 [nasm] setup_channel(): unable to initialize kerberos
    Feb 20 09:25:31.691544 [nasm] close_kerberos
    Feb 20 09:25:31.691561 [nasm] close_kerberos(): deinitialized kerberos successfully
    Feb 20 09:25:36.837904 [nasm] initialize_kerberos(): realm = BEYERSFHC.COM
    Feb 20 09:25:36.844966 [nasm] initialize_kerberos(): gss_acquire_cred HOST/FW-XG135-OBO@BEYERSFHC.COM: Key table file '/etc/krb5.keytab' not found
    Feb 20 09:25:36.845049 [nasm] setup_channel(): unable to initialize kerberos
    Feb 20 09:26:17.718182 [nasm] close_kerberos
    Feb 20 09:26:17.718199 [nasm] close_kerberos(): deinitialized kerberos successfully
    Feb 20 09:26:22.494141 [nasm] initialize_kerberos(): realm = BEYERSFHC.COM
    Feb 20 09:26:22.500884 [nasm] initialize_kerberos(): gss_acquire_cred HOST/FW-XG135-OBO@BEYERSFHC.COM: Key table file '/etc/krb5.keytab' not found
    Feb 20 09:26:22.500956 [nasm] setup_channel(): unable to initialize kerberos
    Feb 20 12:29:28.630370 [nasm] close_kerberos
    Feb 20 12:29:28.630386 [nasm] close_kerberos(): deinitialized kerberos successfully
    Feb 20 12:29:33.824849 [nasm] initialize_kerberos(): realm = BEYERSFHC.COM
    Feb 20 12:29:33.831286 [nasm] initialize_kerberos(): gss_acquire_cred HOST/FW-XG135-OBO@BEYERSFHC.COM: Key table file '/etc/krb5.keytab' not found
    Feb 20 12:29:33.831376 [nasm] setup_channel(): unable to initialize kerberos

  • In reply to Bill Roland:

    Hi  

    This appears to be a bug.

    Herewith is a workaround that you can try.  Please do let us know if it fixes your issue:

    Stop the NASM service: service nasm:stop -ds nosync

    Remove file /content/nasm: rm -rf /content/nasm

    Start the NASM service: service nasm:start -ds nosync

    Thanks!

  • In reply to KingChris:

    KingChris

    Hi  

    This appears to be a bug.

    Herewith is a workaround that you can try.  Please do let us know if it fixes your issue:

    Stop the NASM service: service nasm:stop -ds nosync

    Remove file /content/nasm: rm -rf /content/nasm

    Start the NASM service: service nasm:start -ds nosync

    Thanks!

     

    This worked, thanks!

     

    messageid="17945" log_type="Event" log_component="AD SSO" log_subtype="Authentication" status="Successful" user="" user_group="" client_used="" auth_mechanism="" reason="" src_ip="10.1.10.4" message="Kerberos authentication initialized successfully with BeyersFHC" name="" src_mac=""

  • In reply to Bill Roland:

    Hi  

    That is great news.

    There will be someone reaching out to you to gather details on the history of this device so that development can properly investigate the issue.

    Thanks for the feedback!