Description

After generating a trace log and then attempting to download it via the KWTS 6.1 web interface, it fails with an error if the trace log is more than 1GB (one gigabyte).

The error is duplicated on different devices in different browsers: Mozilla, Chrome, Edge.

• In Mozilla, the download stops with "Failed to download file"
• Chrome goes into an endless download attempt, the download is interrupted at 1GB, after which the speed drops to 0kb/s and the download starts all over again.

How to solve

To resolve the problem with downloading a large trace log, follow this procedure:

1) Connect to the Kaspersky Web Traffic Security node via SSH to access the technical support mode. If SSH access has not been previously configured, you must first log into the web interface as a local administrator and configure access by uploading the SSH public key.

2) Go to the /etc/nginx/conf.d directory, make a backup copy of the kwts_webapi.conf and kwts_controlapi.conf files if you have not done so before:

cd /etc/nginx/conf.d
cp -p kwts_webapi.conf kwts_webapi.conf.backup
cp -p kwts_controlapi.conf kwts_controlapi.conf.backup

3) Open the /etc/nginx/conf.d/kwts_webapi.conf file for editing and add the line marked below in green to the location /web/api block:

location /web/api {
    ...
    uwsgi_max_temp_file_size 0;
    include uwsgi_params; 
    ...

}

4) Open the /etc/nginx/conf.d/kwts_controlapi.conf file for editing and add the line marked below in green to the location /ctl/v1 block:

location /ctl/v1 {
    ...
    uwsgi_max_temp_file_size 0;
    include uwsgi_params;
}

5) Restart nginx using the command

systemctl restart nginx

6) Check the status of the nginx service, it should be running.

systemctl status nginx

The described steps must be repeated on each node of the Kaspersky Web Traffic Security cluster.

After completing the procedure, restart your web browser and reconnect to the Kaspersky Web Traffic Security 6.1 web interface.

Description

You can face an issue like this on Events page in KWTS:

Sometimes the search on the Events page works correctly. Sometimes not.. If you collect har-file (HOW TO) from Events page with reproduced issue you will see an error also in it:

Also you can find an error in diagnostic_info\logs\var\log\kaspersky\kwts\extra\webapi.log:

Then you should check Maximum event log size (https://support.kaspersky.com/KWTS/6.1/en-US/174773.htm) in settings here: diagnostic_info\klinfo\worker_settings.xml

Maximum event log size set to 10 GB. 

How to solve a problem

You should set it to 9 GB. The KWTS architecture is not designed for a large event database size.

Descriptrion

You can see an issue like this:

You can also find log entries like this in diagnostic_info\logs\var\log\kwts-traces.log

Or like this

How to solve a problem 

It means that the problematic node could not resolve activation service. 

1. Check an access to activation services from the problematic node
   curl -v https://activation-v2.kaspersky.com/ --cacert activation-v2.kaspersky.crt
2. And if there is no success connection, open an access to
   https://activation-v2.kaspersky.com
   https://activation-v2.kaspersky.com/ActivationService/ActivationService.svc
3. And check a page with configuring network access - https://support.kaspersky.com/KWTS/6.1/en-US/189764.htm

There are 2 types of installer within:https://www.kaspersky.com/small-to-medium-business-security/downloads/internet-gateway?icid=gl_sup-site_trd_ona_oth__onl_b2b_klsupport_tri-dl____gateway___ 

1. Version 6.1.0.4762 | Red Hat Enterprise Linux | Localization package
2. Version 6.1.0.4762 | Red Hat Enterprise Linux | Distributive

What' the difference between these two packages?

Localization package is something you install additionally after installing distributive (application package) to get the local language (for example, Japanese).
You can see the order here:
https://support.kaspersky.com/KWTS/6.1/ja-JP/174936.htm
There is no help page for "Installing the localization package" but it's just 'rpm -i'.

How to connect to KWTS via SSH or receive the files via SCP?

Below are the examples of using Putty and WinSCP tools.

In the puttygen utility (from the Putty package):

1. Type of the key to generate: RSA.
2. Generate the key.
3. Protect the key with a password (key passphrase).
4. Save the private key.
5. Copy the public key from the field "Public key for pasting into OpenSSH authorized_keys file"

 In the KWTS web interface:

1. Paste the copied public key into the SSH key field https://support.kaspersky.com/KWTS/6.1/en-US/183526.htm

In Putty:

1. Specify the KWTS address for connection.
2. In the "Category" field on the left, open: Connection - SSH - Auth.
3. Click "Browse" and select the .ppk file of the private key.
4. Connect to the KWTS node.
5. Specify root user account.
6. Enter the password for the key from step 1. 

In WinSCP:

1. Specify the KWTS address for connection.
2. In the "Advanced..." drop-down list, select Advanced.
3. In the left frame, select Authentication in the "SSH" section.
4. In the "Authentication parameters» section, specify the .ppk of the private key in the "Private key file" field.
5. Click OK. Connect to the KWTS node.
6. Specify root user account.
7. Enter the password for the key from step 1. 

Description and cautions

Sometimes you may need KWTS to write syslog messages to different log's name or/and path.

We're talking about this setting:

By default it's set to local1, and depending on OS KWTS writes syslog messages to:

1) CentOS > /var/log/messages

2) Ubuntu > /var/log/syslog

Details

So here's how to change default behavior:

• Change value on web interface to, for instance, local0

• Modify /var/opt/kaspersky/kwts/postgresql/postgresql.conf , so it should look like this:

• Modify files like this:

         -For CentOS /etc/rsyslog.conf

         -For Ubuntu /etc/rsyslog.d/50-default.conf (actually it could be different name, but this one is default for clean installation of Ubuntu)

• Configure rotation for your /var/log/kwts-syslog.log (name it as you wish)

         -For CentOS /etc/logrotate.d/syslog, you can just append it to current rotation settings

         or configure your own parameters (refer to online documentation)

      -For Ubuntu /etc/logrotate.d/syslog (you can create your own param eters as well)

• Reboot OS and finally check that KWTS writes syslog messages to your new log with cat /var/log/kwts-syslog.log command.

Description and cautions

Here's how to configure export only detects from KWTS to external syslog server, which accepts TCP stream on facility local1.

Details

1. Create file /etc/rsyslog.d/kwts-detects.conf with contents as per below (replace SERVER:PORT by your external syslog server, @SERVER:PORT if UDP is in use instead of TCP) 

   $ActionQueueFileName KWTSDetects $ActionQueueType LinkedList $ActionQueueMaxDiskSpace 1g $ActionResumeRetryCount -1 $ActionQueueSaveOnShutdown on   if ($syslogfacility-text == 'local1' and (       $msg contains 'av-status="Detected' or       $msg contains 'encrypted="Detected' or       $msg contains 'macros="Detected' or       $msg contains 'ap-status="Detected' or       $msg contains 'mlf-status="Detected' or       $msg contains 'kata-alert="Detected'     )) then {     @@SERVER:PORT   }

2. Restart rsyslog service like this: 

   systemctl restart rsyslog

To use HAProxy as a load balancer in front of KWTS (iso installation and built-in proxy used) we recommend the following:

1. HAProxy configuration:

   global     log         127.0.0.1 local2     chroot      /var/lib/haproxy     pidfile     /var/run/haproxy.pid     maxconn     4000     user        haproxy     group       haproxy     daemon     stats socket /var/lib/haproxy/stats   defaults     mode                tcp     log                 global     retries             3     timeout queue       1m     timeout connect     10s     timeout client      1m     timeout server      1m     timeout check       10s     maxconn             30000   frontend kwts_proxy     bind *:3128     mode tcp     default_backend kwts_proxy_pool   backend kwts_proxy_pool     balance leastconn     mode tcp     server kwts_node1 10.10.1.42:3128 check send-proxy     server kwts_node2 10.10.1.43:3128 check send-proxy

   where 10.10.1.42 and 10.10.1.43 are KWTS IP addresses;
   3128 is the port where KWTS built-in proxy is listening (Settings → Built-in proxy server → Common → Port);
   8080 is the port of the load balancer.

2. Configure KWTS to use PROXY protocol header (Settings → Built-in proxy server → Common → Load balancing → Mode);
3. Make sure HAProxy IP address is in trusted list on KWTS (Settings → Built-in proxy server → Common → Load balancing → Trusted load balancers);
4. If Kerberos proxy authentication is used, make sure keytab contains SPN record of FQDN address of the load balancer;
5. Make sure that browser is configured to use FQDN and port of load balancer.

General information

Kaspersky Web Traffic Security does not have a regular function of integration with external services via the ICAP protocol, however, it can be added by manually changing the configuration files of the built-in proxy server from the technical support mode.

Important: ICAP integration works in synchronous mode - data transfer is suspended until the ICAP server processes the request. This may introduce additional delays in the processing of user traffic, thus reducing the performance of the proxy server. The external ICAP service must be able to process a sufficient number of concurrent requests and be designed for the target load according to the manufacturer's recommendations.

Integration options

Below are several configuration options depending on which data streams you want to pass through an external ICAP service. To reduce the load, additional filtering of requests using ACL rules is possible. The configuration fragment for the selected integration option must be added to the built-in proxy server configuration file template according to the instructions at the end of the article.

In the examples, the chain of ICAP services is built in such a way that first the request is sent to an external ICAP, and secondly it is checked against KWTS. If necessary, the order can be changed by changing the adaptation_service_chain directive accordingly.

The address of the ICAP service and the method of interaction with it are determined by the icap_service directive:

icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/PATH

bypass - determines how the proxy server will behave when the service is unavailable:

• bypass=0 - the service is required and if it is unavailable, the user will see an error instead of the requested page
• bypass=1 - if the service is unavailable, it will be skipped

icap://IPADDRESS:PORT/PATH - ICAP service address:

• IPADDRESS - service IP address (domain name cannot be specified)
• PORT - TCP port number
• PATH - path to the service (check the value in the documentation for the service)

Option 1. Sending only HTTP requests to external ICAP (REQMOD stream)

The option of sending only HTTP requests to an external ICAP service can be used when integrating with external DLP systems (for example, Infowatch Traffic Monitor).

1. Transferring all HTTP requests to an external ICAP service
   
   icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH
adaptation_service_chain is_req_chain is_ext_req is_kav_req
adaptation_access is_req_chain allow all
    
2. Transfering HTTP requests to an external ICAP service with POST and PUT methods only
   
   icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH
adaptation_service_chain is_req_chain is_ext_req is_kav_req
acl acl_inspect_methods method POST PUT
adaptation_access is_req_chain deny !acl_inspect_methods
adaptation_access is_req_chain allow all
    
3. Similar to previous point + additional filter - do not send requests from certain accounts (username starts with svc_)
   
   icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH
adaptation_service_chain is_req_chain is_ext_req is_kav_req
acl acl_inspect_methods method POST PUT
adaptation_access is_req_chain deny !acl_inspect_methods
acl acl_bypass_users proxy_auth_regex -i svc_.*
adaptation_access is_req_chain deny acl_bypass_users
adaptation_access is_req_chain allow all
    
4. Similar to option 1 point 2 + additional filter - do not send requests when accessing certain URLs from the /etc/squid/bypass_urls.txt file
   
   icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH
adaptation_service_chain is_req_chain is_ext_req is_kav_req
acl acl_inspect_methods method POST PUT
adaptation_access is_req_chain deny !acl_inspect_methods
acl acl_bypass_urls url_regex "/etc/squid/bypass_urls.txt"
adaptation_access is_req_chain deny acl_bypass_urls
adaptation_access is_req_chain allow all

Option 2: Send only HTTP responses to external ICAP (RESPMOD stream)

The option of sending only HTTP requests to an external ICAP service can be used when integrating with external incoming traffic analysis systems, such as Kaspersky Anti Targeted Attack Platform.

1. Sending all HTTP responses to an external ICAP service
   
   icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH
adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp
adaptation_access is_resp_chain allow all
    
2. Similar to previous point + additional filter - do not send requests from certain accounts (username starts with svc_)
   
   icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH
adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp
acl acl_bypass_users proxy_auth_regex -i svc_.*
adaptation_access is_resp_chain deny acl_bypass_users
adaptation_access is_resp_chain allow all
3. Similar to option 2 point 1 + additional filter - do not send requests when accessing certain URLs from the /etc/squid/bypass_urls.txt file
   
   icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH
adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp
acl acl_bypass_urls url_regex "/etc/squid/bypass_urls.txt"
adaptation_access is_resp_chain deny acl_bypass_urls
adaptation_access is_resp_chain allow all

Option 3. Sending both HTTP requests and HTTP responses to external ICAP (REQMOD and RESPMOD streams)

The option of sending HTTP requests/responses to an external ICAP can be used when integrating with external web traffic analysis systems that require both data streams, or when combining two external services according to options 1 and 2.

1. Transferring all HTTP requests/responses to an external ICAP service
   
   icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH
icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH
adaptation_service_chain is_req_chain is_ext_req is_kav_req
adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp
adaptation_access is_req_chain allow all
adaptation_access is_resp_chain allow all
    
2. Similar to previous point + additional filter - do not send requests from certain accounts (username starts with svc_)
   
   icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH
icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH
adaptation_service_chain is_req_chain is_ext_req is_kav_req
adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp
acl acl_bypass_users proxy_auth_regex -i svc_.*
adaptation_access is_req_chain deny acl_bypass_users
adaptation_access is_resp_chain deny acl_bypass_users
adaptation_access is_req_chain allow all
adaptation_access is_resp_chain allow all
    
3. Similar to option 3 point 1 + additional filter - do not send requests when accessing certain URLs from the /etc/squid/bypass_urls.txt file
   
   icap_service is_ext_req reqmod_precache bypass=0 icap://IPADDRESS:PORT/REQMODPATH
icap_service is_ext_resp respmod_precache bypass=0 icap://IPADDRESS:PORT/RESPMODPATH
adaptation_service_chain is_req_chain is_ext_req is_kav_req
adaptation_service_chain is_resp_chain is_ext_resp is_kav_resp
acl acl_bypass_urls url_regex "/etc/squid/bypass_urls.txt"
adaptation_access is_req_chain deny acl_bypass_urls
adaptation_access is_resp_chain deny acl_bypass_urls
adaptation_access is_req_chain allow all
adaptation_access is_resp_chain allow all

Making changes to the built-in proxy server configuration

The option of sending only HTTP requests to an external ICAP service can be used when integrating with external incoming traffic analysis systems, such as Kaspersky Anti Targeted Attack Platform.

1. Connect to the cluster node via SSH to access the technical support mode.
    
2. If the selected configuration option requires an external file with access lists (for example, bypass_urls.txt for options 1.4, 2.3, 3.3), place it in the /etc/squid directory. This must be done before any changes are made to the built-in proxy configuration template.
    
3. Change to the directory where the built-in proxy configuration file templates are located:
   
   cd /opt/kaspersky/kwts-appliance-addon/share/templates
    
4. Make a backup copy of the squid.conf.template file if you haven't already:
   
   cp -p squid.conf.template squid.conf.template.backup
    
5. Open the squid.conf.template file for editing using a text editor:
   
   vim squid.conf.template
6. Go to the end of the file, paste the configuration fragment for integration with an external ICAP service in the place indicated below (existing lines are marked in black, they do not need to be modified in any way, green is the lines to be added)
   
   adaptation_send_client_ip on
adaptation_send_username on
icap_enable on
icap_service is_kav_req reqmod_precache icap://127.0.0.1:1344/av/reqmod
icap_service is_kav_resp respmod_precache icap://127.0.0.1:1344/av/respmod
### --> put your external ICAP configuration here <-- ###
adaptation_access is_kav_req allow all
adaptation_access is_kav_resp allow all
icap_service_failure_limit -1
   
   An example of inserting a configuration fragment (for option 1.2):
   
   adaptation_send_client_ip on
adaptation_send_username on
icap_enable on
icap_service is_kav_req reqmod_precache icap://127.0.0.1:1344/av/reqmod
icap_service is_kav_resp respmod_precache icap://127.0.0.1:1344/av/respmod
### External ICAP configuration begin ###
icap_service is_ext_req reqmod_precache bypass=0 icap://x.x.x.x/reqmod
adaptation_service_chain is_req_chain is_ext_req is_kav_req
acl acl_inspect_methods method POST PUT
adaptation_access is_req_chain deny !acl_inspect_methods
adaptation_access is_req_chain allow all
### External ICAP configuration end ###
adaptation_access is_kav_req allow all
adaptation_access is_kav_resp allow all
icap_service_failure_limit -1
7. Save changes to squid.conf.template
    
8. In order for the changes in the template to be applied, change some setting of the built-in proxy server through the web interface. For example, you can turn off logging (Settings - Built-in proxy server - Log), save the changes, and then return the previous value back.
    
9. Check that the changes have made their way into the main configuration file of the built-in proxy server:
   less /etc/squid/squid.conf
    
10. Check the status of the squid service, it should be running:
    systemctl status squid

This completes the procedure. The described actions must be repeated on each node of the Kaspersky Web Traffic Security cluster.

Introduction

Often problems with Kerberos are difficult to diagnose but they occur if you're deploying KWTS for the first time. There are three functional places in the product where Kerberos authentication can be used:

1. Proxy authentication
   This is needed for users to authenticate on the proxy server automatically without login prompt. If login prompt pops-up, then Kerberos authentication failed.
2. LDAP authentication 
   This is needed for KWTS to synchronize LDAP cache with LDAP servers (simply put - with domain controllers). This cache is used in Rules creation and if KWTS has user login information for a given session supplied by proxy server, then traffic can be matched against those Rules that are defined by groups in AD for example.

3. SSO
   This is needed to authenticate users on KWTS web administration console itself.

   SSO works only for one domain, as it is for KSMG as well.

Terminology

FQDN - https://en.wikipedia.org/wiki/Fully_qualified_domain_name . In our use cases looks like: kwts.example.com

SPN - Unique ID of the service in the network for authentication over the Kerberos protocol. In our use cases looks like: HTTP/<FQDN>@<realm Active Directory service in the upper case>  or  HTTP/*****@*****.tld

Creating keytabs for multiple nodes

For LDAP, SSO and Proxy authentication you need to create two keytabs:

1. Keytab For LDAP without SPN
2. Keytab for SSO and Proxy with SPN

In this example there are two servers in cluster kwts1.example.com and kwts2.example.com and Realm (Domain) is EXAMPLE.COM.

First you remove any existing kwts users from AD and create new ones *****@*****.tld and *****@*****.tld

Then for LDAP you don't need SPN, so create LDAP keytab like so (replace <password> with user password):

You can now add C:\kwts-ldap.keytab to LDAP settings and force LDAP synchronization.

For SSO and Proxy authentication you then create a first keytab like so (do not use upper case letters in FQDN part kwts1.example.com/kwts2.example.com of SPN, this will not work for SSO):

Then using this keytab you create a new keytab with a second record in it:

If there are more servers, then please add more entries in the same manner.

You can now add C:\kwts-control-2.keytab to SSO settings.

When testing SSO you should use https://kwts1.example.com and https://kwts2.example.com URLs, not IP.

If you are asked for credentials then it means that SSO doesn't work. 

For SSO on Internet Explorer and Chrome it is important that https://kwts1.example.com and https://kwts2.example.com are added to Local Intranet zones in IE settings (refer to https://support.kaspersky.com/ksmg/228052 - article is for KSMG, but fully applicable to KWTS as well):

1. Open Internet Explorer and click the Settings gear icon in the top-right corner. Select Internet options.
2. Select the Security tab.
3. Select the Local Intranet zone and click the Sites button.
4. Make sure that the first two options, Include all local (intranet) sites not listed in other zones and Include all sites that bypass the proxy server are checked.
5. Click Advanced and add the KWTS addresses, one at a time, to the list of websites. In this example add https://kwts1.example.com and https://kwts2.example.com.  Click Close.
6. Click OK to save your configuration changes.

For Firefox:

1. Open the low level Firefox configuration page by loading the about:config page.
2. In the Search text box, enter: network.negotiate-auth.trusted-uris
3. Double-click the network.negotiate-auth.trusted-uris preference and enter KWTS address. Separate multiple addresses with a comma.
4. Click OK.

Now, if SSO works fine you can add the same C:\kwts-control-2.keytab to Proxy authentication settings and test it.

When testing proxy authentication make sure proxy address in browser settings is set to kwts1.example.com or kwts2.example.com. IP address will not work.

Notable differences and restrictions in Kerberos keytab requirements

1. For Proxy and SSO authentication FQDN that is specified in keytab must always match the real and used FQDN. For Proxy authentication the address that is used in browser proxy settings MUST match the FQDN in keytab.
   For SSO, the address in the address bar in the browser that is used to access KWTS web interface MUST match the FQDN in the keytab and MUST match the real FQDN of KWTS and FQDN that is configured in OS. But for LDAP the FQDN in keytab SPN should just have valid records in DNS including PTR record. It is also not necessary for LDAP keytab to have an SPN at all while you must have it for Proxy and SSO;

2. For LDAP authentication it is not possible to have multiple SPN entries in keytab. But in case of Proxy and SSO authentication you can create multiple entries. However for LDAP it is not needed (see 1);
3. You cannot have SPN duplicates. Meaning that you can't create two different keytabs that have duplicate SPN (which includes FQDN);
4. User which was used to create keytab must contain only latin characters in Distinguished Name, so in the entire path to the user in AD there must not have Cyrillic or other characters.

To sum up usually you must create two keytabs:

1. For Proxy and SSO that have all the SPNs with all FQDNs of proxy and secondary nodes (to which fallback if control node fails);
2. For LDAP that doesn't have an SPN or has one that just has an FQDN with valid DNS records but is not duplicate to any SPN in 1.

How KWTS connects to LDAP servers using keytab

There is no ldap server address configuration in KWTS.

It takes the REALM (Domain) from keytab,  for example EXAMPLE.COM, then the following DNS requests of type SRV are sent:

_ldap._tcp.example.com

_kerberos._tcp.example.com

In KWTS console such requests can be reproduced with

There you will see a list of domain controllers, ports, weighs and priorities. For more information on SRV records see https://en.wikipedia.org/wiki/SRV_record

LDAP servers are listed in _ldap._tcp.example.com , default port 389.

_kerberos._tcp.example.com is needed for Kerberos, default port 88.

Connection is tried to each one from the list (one at a time, with a timeout) until a it is successfully established or the list is exhausted.

LDAP+Kerberos diagnostics

To diagnose LDAP synchronization issues first turn on Debug level traces (link). Then reproduce the problem by clicking Synchronize button in LDAP settings.

In 10-20 minutes depending on the size of your domains and number of them you should be able to check traces either directly on the server like so:

or by getting the built-in collect and looking in kwts-traces files by other means (link).

For example, if you see the following errors:

Then make sure you can connect to server.local:389 with telnet and verify that:

1. On KWTS you can resolve server.local by FQDN and resolve PTR for its IP. Domain controller PTR record should be matched to A record otherwise Kerberos will not work and the error will be exactly as in above log;
2. On server.local you can resolve KWTS by FQDN and resolve PTR for its IP;
3. Time on KWTS servers is synchronized properly with an NTP server.

How to use multiple domains in LDAP

1. Create multiple LDAP connections in LDAP settings, one for each domain and use a separate keytab for each;
2. Make sure that a specific DNS server can resolve _kerberos._tcp. and _ldap._tcp. SRV records for each domain.  For that in the main domain DNS server you can create stub DNS zones for each domain;
3. Configure KWTS to use that DNS server.

Proxy authentication diagnostics

Check squid logs:

For example:

Means that keytab was created with AES128 or AES256 encryption but the user with which it was created doesn't have AES128 or AES256 enabled in user settings (Properties → Account → Account Options → This account supports Kerberos AES 128/256 bit encryption).

Trace kinit:

1. Run on KWTS:

   KRB5_TRACE=/tmp/kr.tr kinit -Vkt /etc/squid/auth_krb5.keytab HTTP/FQDN@REALM

   where HTTP/FQDN@REALM is the SPN of used keytab. For standalone (not built-in proxy) instead of /etc/squid/auth_krb5.keytab specify the real path to keytab);

2. Check output of the command AND /tmp/kr.tr file, it should contain detailed trace.

SSO authentication diagnostics

Check logs in /var/log/kaspersky/kwts/extra/

For example in webapi.log if you see

That means that there are two PTR records in DNS for KWTS IP address. Remove one that is not for the FQDN that should be used to access KWTS web interface.

Means there is no SPN record in keytab for the FQDN which was accessed by the web browser.

Means the keytab was created with AES128 or AES256 cryptography but it is not enabled in user settings in AD.

Means keytab was created with wrong user password or password was changed after keytab was created.

Time out sync between KWTS and DC

On KWTS time is far behind DC:

On KWTS time is far ahead DC:

On KWTS time is slightly ahead DC:

Also you can upload the keytab to the server via WinSCP and trace kinit as in proxy authentication diagnostics.

If kinit is successful but browser doesn't authenticate check that web interface FQDN is added to trusted servers in browser settings. See for example: https://docs.cloudera.com/documentation/enterprise/5-12-x/topics/cdh_sg_browser_access_kerberos_protected_url.html

Please note that if the keytab that you are adding does not contain an SPN with FQDN from 'hostnamectl' command output, you will get "Invalid keytab file for the Control node". In that case change hostname to FQDN with:

Useful tricks

Run the following in PowerShell (on DC) to get the list all users for which keytabs were created with SPN that starts with "HTTP/"

A faster way to find if there are duplicates:

This command would remove SPN for a specific user kaspersky:

On Windows workstations you can also get the current list of Kerberos tickets with

Sometimes there might be an incorrect old ticket, in that case you can purge ticket:

You can also request a ticket manually with

Please remember that using commands or recommendations from the articles without a clear understanding of their purpose may result in errors or system inoperability. Please note that some materials presented are not official, so technical support may decline to support a specific unsupported configuration in some instances.

Please also ensure to use the official documentation, found in this link.