Overview

Description Error looks like this: You can't download trace log. But there is free space on the disk: Cause You will see this error if free disk space less than 10G. KWTS is not in sizing 200 GB of hard drive space, which includes: 25 GB for temporary file storage 25 GB for log file storage How to solve a problem Bring disk sizing to minimum hardware requirements

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.

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 Line 1538367: Jan 11 18:12:33 kwts2 KWTS Licenser[1154]: 1241 INF httpcli#011Req 0x7fecd003b9d0 CURL: Could not resolve host: activate.activation-v2.kaspersky.com Line 1538460: Jan 11 18:12:33 kwts2 KWTS EventLogger[1062]: 1102 DBG APP: void lms::event_logger::LoggerHelperProcFrontend::SendCommand(const lms::event_logger::HelperProcCommand&, const string&)message is: license error: Could not resolve host Or like this Line 4667143: Nov 18 16:02:12 32-vs-kwts02 KWTS Licenser[1675]: 35735 DBG APP: virtual result_t lms::licenser::utils::RequestCompleteEvent::OnRequestComplete(licensing::facade::product::ILicensing*, licensing::facade::product::activation_action::Type, const ActivationCode&, result_t, licensing::facade::product::IActivationContent*) actionType = 0, activationCode = AW65R-BZ8CG-KBQ18-ANNZ2, result = 0xa0430005 Line 4667349: Nov 18 16:02:12 32-vs-kwts02 KWTS EventLogger[1552]: 1592 DBG APP: void lms::event_logger::Journalist::Write(const lms::event_logger::JournalRecord&) JournalRecordData(dateTime.dt: 133132501328539280, type: 9, person: kluser, result: 1, description: license error: Could not resolve host, details: { "name": "LicenseErrorEvent", "data": {#012 "reason": -1608777683#012} }) How to solve a problem It means that the problematic node could not resolve activation service. Check an access to activation services from the problematic node curl -v https://activation-v2.kaspersky.com/ --cacert activation-v2.kaspersky.crt And if there is no success connection, open an access to https://activation-v2.kaspersky.com https://activation-v2.kaspersky.com/ActivationService/ActivationService.svc And check a page with configuring network access - https://support.kaspersky.com/KWTS/6.1/en-US/189764.htm

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: celery.backends.base.SoftTimeLimitExceeded: SoftTimeLimitExceeded(True,) 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.

Issue: Some log files in KWTS take up a lot of disk space. Log rotation for these files does not work For example: Information Information about logs sizing and rotation you can find in files in /etc/logrotate.d folder on the KWTS server. The size of log files should be no more than: Log file In what file it described Size of a log file should be no more than: All files in /var/log/kaspersky/kwts/extra/ /etc/logrotate.d/kwts 100 MB /var/log/kwts-messages /etc/logrotate.d/kwts-syslog 500 MB /var/log/kwts-important /etc/logrotate.d/kwts-syslog 50 MB /var/log/kwts-traces /etc/logrotate.d/kwts-syslog 500 MB /var/log/nginx/access.log /etc/logrotate.d/nginx 100 MB /var/log/nginx/error.log /etc/logrotate.d/nginx 20 MB /var/log/squid/icap.log /etc/logrotate.d/squid 100 MB /var/log/squid/ssl.log /etc/logrotate.d/squid 100 MB /var/log/squid/squid.out /etc/logrotate.d/squid 10 MB /var/log/squid/cache.log /etc/logrotate.d/squid 500 MB /var/log/squid/access.log /etc/logrotate.d/squid 500 MB /var/log/messages /etc/logrotate.d/syslog 100 MB /var/log/cron /etc/logrotate.d/syslog 10 MB /var/log/maillog /etc/logrotate.d/syslog 10 MB /var/log/secure /etc/logrotate.d/syslog 20 MB /var/log/spooler /etc/logrotate.d/syslog 1MB How to fix Actual result kwts-traces log-file has frown to 4 GB: Expected result kwts-traces file no more than 500 mb How to fix Be prepared that you will need to reboot the server and it will not process traffic while it is rebooting. And you need ssh-access to the KWTS server - https://support.kaspersky.com/KWTS/6.1/en-US/183526.htm Make sure that trace lever is in "Error" mode - https://support.kaspersky.com/KWTS/6.1/en-US/174877.htm Delete the largest log-files (in our case it is /var/log/kwts-traces) . If you need to clear additional disk space, you can delete large archive files if you are sure that you do not need the information in them Reboot the KWTS server and make sure that the deleted large files (/var/log/kwts-traces) are recreated Find out in table above in what file we can find information about kwts-traces rotation . It is kwts-syslog Execute following command logrotate -f -v /etc/logrotate.d/kwts-syslog &> logrotatef.log Make sure that all log-files which described in /etc/logrotate.d/kwts-syslog file were rotated. (You can see which log files are described in this file in the table above) What's next Kindly monitor that previously broken files (kwts-traces) do not exceed 500-600 MB. If it continues to grow and is already 700 MB or more, then run the command /usr/sbin/logrotate -v -s /var/lib/logrotate/logrotate.status /etc/logrotate.conf &> logrotatestatus.log And send logrotatef.log file from step 6 and logrotatestatus.log file to Kaspersky Support. And also send diagnostic info in "Debug" level. Do not forget to change it back to "Error" level - https://support.kaspersky.com/KWTS/6.1/en-US/174877.htm

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). 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 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 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 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. 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 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 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. 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 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 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. Connect to the cluster node via SSH to access the technical support mode. 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. Change to the directory where the built-in proxy configuration file templates are located: cd /opt/kaspersky/kwts-appliance-addon/share/templates Make a backup copy of the squid.conf.template file if you haven't already: cp -p squid.conf.template squid.conf.template.backup Open the squid.conf.template file for editing using a text editor: vim squid.conf.template 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 Save changes to squid.conf.template 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. Check that the changes have made their way into the main configuration file of the built-in proxy server: less /etc/squid/squid.conf 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.

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 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 } Restart rsyslog service like this: systemctl restart rsyslog

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: Steps below were performed on Centos 7+ x64 and Ubuntu 20.04/22.04 x64 KWTS 6.1 NOT ISO 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.

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___ Version 6.1.0.4762 | Red Hat Enterprise Linux | Localization package 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): Type of the key to generate: RSA. Generate the key. Protect the key with a password (key passphrase). Save the private key. Copy the public key from the field "Public key for pasting into OpenSSH authorized_keys file" In the KWTS web interface: Paste the copied public key into the SSH key field https://support.kaspersky.com/KWTS/6.1/en-US/183526.htm In Putty: Specify the KWTS address for connection. In the "Category" field on the left, open: Connection - SSH - Auth. Click "Browse" and select the .ppk file of the private key. Connect to the KWTS node. Specify root user account. Enter the password for the key from step 1. In WinSCP: Specify the KWTS address for connection. In the "Advanced..." drop-down list, select Advanced. In the left frame, select Authentication in the "SSH" section. In the "Authentication parameters» section, specify the .ppk of the private key in the "Private key file" field. Click OK. Connect to the KWTS node. Specify root user account. Enter the password for the key from step 1.

To use HAProxy as a load balancer in front of KWTS (iso installation and built-in proxy used) we recommend the following: 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. Configure KWTS to use PROXY protocol header (Settings → Built-in proxy server → Common → Load balancing → Mode); Make sure HAProxy IP address is in trusted list on KWTS (Settings → Built-in proxy server → Common → Load balancing → Trusted load balancers); If Kerberos proxy authentication is used, make sure keytab contains SPN record of FQDN address of the load balancer; Make sure that browser is configured to use FQDN and port of load balancer.

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: 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. 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. 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. Check the documentation https://support.kaspersky.com/KWTS/6.1/en-US/166491.htm Read Kerberos and LDAP parts. 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: Keytab For LDAP without SPN 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. Please bear in mind that hostname of KWTS node in OS MUST be in lower-case. If it's in upper-case change hostname via command hostnamectl set-hostname kwts1.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): ktpass.exe /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out C:\kwts-ldap.keytab /princ kwts-ldap-user@EXAMPLE.COM /pass <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): ktpass.exe -princ HTTP/kwts1.example.com@EXAMPLE.COM -mapuser kwts-control-user@EXAMPLE.COM -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass <password> -out C:\kwts-control-1.keytab Then using this keytab you create a new keytab with a second record in it: ktpass.exe -princ HTTP/kwts2.example.com@EXAMPLE.COM -mapuser kwts-control-user@EXAMPLE.COM -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass <password> -in C:\kwts-control-1.keytab -out C:\kwts-control-2.keytab -setupn -setpass 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): Open Internet Explorer and click the Settings gear icon in the top-right corner. Select Internet options. Select the Security tab. Select the Local Intranet zone and click the Sites button. 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. 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. Click OK to save your configuration changes. For Firefox: Open the low level Firefox configuration page by loading the about:config page. In the Search text box, enter: network.negotiate-auth.trusted-uris Double-click the network.negotiate-auth.trusted-uris preference and enter KWTS address. Separate multiple addresses with a comma. 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. Creating SSO/Proxy keytabs for two domains (or more) for two nodes and a balancer Users from *both* domains must connect to KWTS via proxy1-kwts.firstdomain.ru FQDN, this is not optional. On domain controller of FIRSTDOMAIN.RU (user: control-user-domain1): C:\Windows\system32\ktpass.exe -princ HTTP/proxy1-kwts.firstdomain.ru@FIRSTDOMAIN.RU -mapuser control-user-domain1@FIRSTDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password1 +dumpsalt -out c:\Temp\1.keytab Assuming we've got salt "FIRSTDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" (salt usually consists of DOMAIN + HTTP + fqdn string, it is case sensitive, and doesn't change in the scope of a single user) C:\Windows\system32\ktpass.exe -princ HTTP/proxy2-kwts.firstdomain.ru@FIRSTDOMAIN.RU -mapuser control-user-domain1@FIRSTDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password1 -in c:\Temp\1.keytab -out c:\Temp\2.keytab -setupn -setpass -rawsalt "FIRSTDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" C:\Windows\system32\ktpass.exe -princ HTTP/balancer-kwts.firstdomain.ru@FIRSTDOMAIN.RU -mapuser control-user-domain1@FIRSTDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password1 -in c:\Temp\2.keytab -out c:\Temp\3.keytab -setupn -setpass -rawsalt "FIRSTDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" On domain controller of SECONDDOMAIN.RU (user: control-user-domain2): Copy c:\Temp\3.keytab from FIRSTDOMAIN.RU domain controller to c:\Temp\3.keytab on SECONDDOMAIN.RU domain controller C:\Windows\system32\ktpass.exe -princ HTTP/proxy1-kwts.firstdomain.ru@SECONDDOMAIN.RU -mapuser control-user-domain2@SECONDDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password2 +dumpsalt -in c:\Temp\3.keytab -out c:\Temp\4.keytab Assuming we've got salt "SECONDDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru". C:\Windows\system32\ktpass.exe -princ HTTP/proxy2-kwts.firstdomain.ru@SECONDDOMAIN.RU -mapuser control-user-domain2@SECONDDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password2 -in c:\Temp\4.keytab -out c:\Temp\5.keytab -setupn -setpass -rawsalt "SECONDDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" C:\Windows\system32\ktpass.exe -princ HTTP/balancer-kwts.firstdomain.ru@SECONDDOMAIN.RU -mapuser control-user-domain2@SECONDDOMAIN.RU -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass password2 -in c:\Temp\5.keytab -out c:\Temp\6.keytab -setupn -setpass -rawsalt "SECONDDOMAIN.RUHTTPproxy1-kwts.firstdomain.ru" Apply 6.keytab in SSO and Built-in proxy kerberos authentication settings. Notable differences and restrictions in Kerberos keytab requirements 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; 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); You cannot have SPN duplicates in the same domain. Meaning that you can't create two different keytabs that have duplicate SPN (which includes FQDN), you must not have SPN duplicates with different mapped users; 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: For Proxy and SSO that have all the SPNs with all FQDNs of proxy and secondary nodes (to which fallback if control node fails); 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 dig srv _ldap._tcp.example.com dig srv _kerberos._tcp.example.com 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: grep LdapC /var/log/kwts-traces | less 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: Sep 29 15:30:01 srv-proxy2 KWTS LdapCache[33227]: 33227 DBG trying to connect ldap://server.local:389 Sep 29 15:30:01 srv-proxy2 KWTS LdapCache[33227]: 33227 WRN Couldn't connect ldap://server.local:389 Sep 29 15:30:01 srv-proxy2 KWTS LdapCache[33227]: 33227 ERR CheckFailedException - LDAP error (-2) : Local error - Cannot perform LDAP SASL interactive bind operation. At /tmp/buildbot/core_ldap_cache-kwts_linux-64/build/source/ldap/connection.cpp(203) Then make sure you can connect to server.local:389 with telnet and verify that: 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; On server.local you can resolve KWTS by FQDN and resolve PTR for its IP; Time on KWTS servers is synchronized properly with an NTP server. How to use multiple domains in LDAP Create multiple LDAP connections in LDAP settings, one for each domain and use a separate keytab for each; 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; Configure KWTS to use that DNS server. Proxy authentication diagnostics Check squid logs: /var/log/squid/cache.log shouldn't contain errors regarding Kerberos or NTLM /var/log/squid/access.log should contain usernames of authenticated users For example: negotiate_kerberos_auth.cc(182) : pid=63851 :2020/06/03 11:28:00| negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. Request ticket server HTTP/kwts.test.local@TEST.LOCAL kvno 2 found in keytab but not with enctype rc4-hmac 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: 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); 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 ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Request ticket server HTTP/*****@*****.tld found in keytab but does not match server principal HTTP/dpc-kwts-01.example.com@', 100005)) [pid: 14648|app: 0|req: 701/53178] 10.199.5.19 () {50 vars in 4127 bytes} [Wed Oct 14 14:12:46 2020] GET /web/api/get-session-info?cb=1602673966446 => generated 224 bytes in 12 msecs (HTTP/1.1 403) 3 headers in 93 bytes (1 switches on core 0) 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. ./celery.log:[2020-06-02 18:00:47,860: ERROR/ForkPoolWorker-1] there are no valid principal for HTTP service on kwts.example.com host in keytab data; <class 'kerberos.KrbError'>: ('Principal not found in keytab', -1) ./webapi.log:ERROR:root:there are no valid principal for HTTP service on kwts.example.com host in keytab data; <class 'kerberos.KrbError'>: ('Principal not found in keytab', -1) Means there is no SPN record in keytab for the FQDN which was accessed by the web browser. ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Request ticket server HTTP/*****@*****.tld kvno 6 found in keytab but not with enctype rc4-hmac', 100005)) Means the keytab was created with AES128 or AES256 cryptography but it is not enabled in user settings in AD. ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Request ticket server HTTP/*****@*****.tld kvno 8 not found in keytab; keytab is likely out of date', 100005)) 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: ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Ticket not yet valid', 100005)) On KWTS time is far ahead DC: ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Ticket expired', 100005)) On KWTS time is slightly ahead DC: ./webapi.log:ERROR:root:GSSError: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Clock skew too great', 100006)) 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: hostnamectl set-hostname FQDN 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/" Get-ADUser -Filter 'UserPrincipalName -like "HTTP/*"' A faster way to find if there are duplicates: setspn -X This command would remove SPN for a specific user kaspersky: setspn -D HTTP/FQDN kaspersky On Windows workstations you can also get the current list of Kerberos tickets with klist Sometimes there might be an incorrect old ticket, in that case you can purge ticket: klist purge You can also request a ticket manually with klist get HTTP/kwts.example.com