Set up Kerberos in v18?

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

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

Bill Roland said:

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

Maybe Michael Dunn can help here? 

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.

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.

Michael Dunn said:

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

Thanks Michael.

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.

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

Hi Bill Roland 

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!

KingChris said:

Hi Bill Roland 

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!

 

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=""

Hi Bill Roland 

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!

Hi Bill Roland 

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!