Tufin.club
  • www.tufin.club
  • imprint
  • data privacy statement

Admin Management

(Safe) Snapshot / Reboot for TOS

Details
Admin Management
Last Updated: 14 September 2025

Running the Tufin Orchestration Suite (TOS) not only means to have a system running Linux, but also a Kubernetes Cluster is running on the system. If a system restart is necessary, it's not sufficient to simply enter the "reboot" command at the command line. Even if a snapshot needs to be created from a virtual machine, measures must be taken beforehand—otherwise, a snapshot might be available, but it will not be suitable for restoring the system. 

To shut down the system running TOS these steps should be taken: 

  • Stop TOS and wait for the message that TOS has been stopped
    # tos stop -d 

  • The Pods are still terminating, wait until all Pods have been stopped successfully, then resume the command using Ctrl-C
    # watch kubectl get pods

  • The Kubernetes Cluster should also be stopped and disabled
    # systemctl stop k3s.service
    # systemctl disable k3s.service

  • The result should be checked using the commands
    # systemctl is-active k3s
    # systemcll is-enabled k3s

Now it's safe to shutdown or restart the system. Creating a snapshot is now also possible safely.
After a restart or restore of the system, neither k3s nor tos will start automatically.
This might be uncomfortable, but it should be done this way. If not, problems migth arise due to open data bases, open files, etc. 

To start the system, these steps should be carried out: 

  • Start, enable and check k3s Service. This needs to be done first since TOS requires a running Kubernetes Cluster
    # systemctl start k3s.serice
    # systemctl enable k3s service
    # systemctl is-enabled k3s.service
    # systemctl status k3s.service

  •  Start TOS and wait for the message that TOS has been started successfully
    # tos start -d 

  • The Pods are still starting even if the command states that the start has been successully done.
    Check that all Pods have been started, leave the command afterwards using CTRL-C
    # watch kubectl get pods

This method appears to be complex, but it's recommended regarding data security and keep the system running without issues. 

 

 

Tufin License Usage Reports

Details
Admin Management
Last Updated: 14 September 2025

Since some versions of the Tufin Orchestration Suite (TOS) licensing and its enforcement is a bit more flexible as in earlier times. 

If e.g. 20 devices had been licensed some time ago, adding another device resulted in problems. Now, it's more flexible and you have the possibility to add some devices more than you have licensed. This results in the need of "license usage reports" for Tufin to find out the number of licenses used. 

Working with versions up to 24-2, these reports are required, but not really enforced. The license is shown in SecureTrack via Menu > Admin > Administrator > Licenses. At the bottom of the screen License Management the section License Usage is shown.

If the option "Send automatic usage reports" is turned on and the system has Internet access, everything is fine. If it's not turned on or connected to the Internet, a manual download of the usage report is recommended. The resulting JSON file is uploaded to the Tufin Portal then. 

Starting with 25-1, the license usage reports are enforced. The screen shown above has changed to this: 

It's now necessary to upload the license usage report to the Tufin Portal - and to get the confirmation code that will be sent by E-Mail after the upload. After having uploaded the code shown in the E-Mail to TOS, a message is displayed that the licenses used has been verified. 

Not following Tufin's guidelines of today, some restrictions regarding the TOS will occur because no Information about Site Usage Monitoring has been supplied: 

  • Not providing Reports for 6 Months:
    There is no possibility to upgrade TOS

  • Not providing Reports for 12 Months: 
    No further use of TOS is possible, even if a valid subscription has been purchased

So the flexibility regarding licenses requires a mandatory upload of License Usage Reports to the Tufin Portal now. It's done here via My Account > Available Licenses > Manual Usage Upload - or if TOS is connected to the Internet, via the automatic upload process. 

 

 

 

 

Backup status "IMPAIRED"

Details
Admin Management
Last Updated: 14 September 2025

There are various status messages when backing up the Tufin Orchestration Suite. One of them is 
     IMPAIRED
If any backup is in this status, it's no longer possible to continue working with the data backup.

The reason for this status is a component in the Kubernetes cluster that is not working correctly when the backup has been created. 

To solve the problem, all backups with this status should first be deleted. Then ensure that the TOS cluster is in a good state. No problems should be reported when calling the “tos status” command. Then the backup will work as desired again.

 

 

 

TOS status: "checker failure"

Details
Admin Management
Last Updated: 14 September 2025

The message "checker failure" might occur when checking the status of the Tufin Orchestration Suite. 

When looking at Tufin's knowledge base, this message is mentioned as "known bug" that is fixed in R24-1 PHF4.1.0 and R24-2 PHF1.0.0, respectively. If you cannot upgrade or get still the message, this procedure might help: 

  • Find as root the pod that is responsible for this message by using the command
    # kubectl get pods -owide | grep node-exporter
    tos-prometheus-node-exporter-zddqg                    2/2     Running     0 …

  • Check this pod, e.g. if it's running (can be skipped)
    # kubectl describe pod tos-prometheus-node-exporter-zddqg
    ...
  • Restarting the pod helps to return to a normal status
    # kubectl delete pod tos-prometheus-node-exporter-zddqg

You can check the status of this pod by using the first command shown above. Please give the pod to start (and to show a status "ok") about two minutes. Checking "tos status" before will still deliver "checker failure" because the pod is still not running well. 

 

 

 

Single Sign On for SecureTrack/SecureChange

Details
Admin Management
Last Updated: 30 May 2023

Since TOS Aurora 22-1, there is an option to use a Single Sign On (SSO) for SecureTrack and SecureChange / SecureApp. In new installations, this feature is enabled by default, but in upgraded installations, this feature needs to be enabled manually. This is quite easy, following Tufin Knowledge Base. If SSO is turned on, there is no additional authentication required if a user changes from e.g. SecureTrack to SecureChange.

Enable SSO

To activate SSO access to the command line is necessary. Additionally, administrative permissions are needed (e.g. root or the use of sudo). This command enables SSO:

[Tufin]$ sudo tos config set -p tos.sso.enabled=true

After this action, SSO is active and the login screen shows "Tufin Orchestration Suite".

Sometimes it's useful, to disable SSO (see below).

Disable SSO

Disabling the optional SSO is done using this command with administrative permissions at the CLI (e.g. root or the use of sudo):

[Tufin]$ sudo tos config set -p tos.sso.enabled=false

After this command, a separate login screen is shown for SecureTrack and/or SecureChange - as it has been before for many years.

 

Items to consider when using SSO for SecureTrack and SecureChange

  • The login using the portal shown above requires the user to be configured in SecureTrack.
    If a user is configured in SecureChange only (e.g. Approver, Auditor), a successful login is not possible.
    So these users need to be configured in SecureTrack also (but don't need any permission to view any device).

  • If a disclaimer is required, there is only one possibility to configure it (see also here).

  • If external Servers for authentication are used, please be aware of which server is needed and where users need to be configured. (Special AD branches for user/admin used in SecureTrack vs. separate LDAP authentication in SecureChange).

  • The "old" SSO option for SecureChange is no more supported if SSO for SecureTrack/SecureChange is configured.
    So if a portal is used for SecureChange authentication, this needs to be migrated to use SAML-based authentication.

    > added May, 30th, 2023:
    If you want to use SAML, please consider that there is no support for integration with SAML IDP IBM.

 

 

 

 

 

Logging authentication at Tufin

Details
Admin Management
Last Updated: 20 March 2021

Sometimes it is necessary to have logs who tried to logon to TufinOS or TOS. Also, not successful tries need to be recognized and logged. This often is a requirement, esp. if compliance regulations need to be fulfilled. Logging can be done by extracting information from Tufin in a tool like e.g. Splunk. The information is stored in some files described below.

 

TufinOS

Logon to the CLI of TufinOS is recorded automatically since it's based on CentOS. The file in which this information can be found is
     /var/log/secure

Please find an example for an unsuccessful (user123) and successful login (root).

Mar 16 19:38:57 localhost sshd[24880]: Invalid user user123 from 10.0.0.23
Mar 16 19:38:57 localhost sshd[24881]: input_userauth_request: invalid user user123
Mar 16 19:39:01 localhost sshd[24880]: pam_unix(sshd:auth): check pass; user unknown
Mar 16 19:39:01 localhost sshd[24880]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.23
Mar 16 19:39:01 localhost sshd[24880]: pam_succeed_if(sshd:auth): error retrieving information about user user123
Mar 16 19:39:03 localhost sshd[24880]: Failed password for invalid user user123 from 10.0.0.23 port 50025 ssh2
Mar 16 19:39:11 localhost sshd[24881]: Connection closed by 10.0.0.23

Mar 16 19:39:38 localhost sshd[24888]: Accepted password for root from 10.0.0.23 port 50026 ssh2
Mar 16 19:39:38 localhost sshd[24888]: pam_unix(sshd:session): session opened for user root by (uid=0)

 

Tufin SecureTrack

A successful login to the WebUI of SecureTrack is recorded in the database. This information can be checked in the WebUI also. To do so, go to Menu > Settings > Administration > Audit Trail. As shown below, a successful login and logout can be monitored here.

 

 Sometimes this information isn't sufficient since also not successful login attempts need to be documented. This can be done by checking the file
      /var/log/keycloak/server.log

When using local authentication, a non-successful login of a user (user2) looks like this in the file

WARN 2021-03-16 20:41:28,511 [default task-2::o.k.events.onEvent] [user:] type=LOGIN_ERROR, realmId=f93f5360-fa5c-4777-aa14-c91c4730e49a, clientId=st_httpd_10.0.0.20, userId=null, ipAddress=10.0.0.23, error=identity_provider_error, auth_method=openid-connect, auth_type=code, redirect_uri=https://10.0.0.20/protected/redirect_uri, code_id=dcca1e78-7a0f-43f3-a017-772ac8c291fe, username=user2#ovzwk43sge======, authSessionParentId=dcca1e78-7a0f-43f3-a017-772ac8c291fe, authSessionTabId=BXN4R0pwtHU

When LDAP is used for authentication at SecureTrack, some more basic information is delivered (user1).

ERROR 2021-03-16 21:14:53,338 [default task-1::c.t.c.k.a.c.h.d.LoginHandlersDispatcher.handleLogin] [user:] LDAP authentication failed for user:{user1}: java.lang.RuntimeException: LDAP authentication failed for user:{user1}
...
WARN 2021-03-16 21:14:53,340 [default task-1::o.k.events.onEvent] [user:] type=LOGIN_ERROR, realmId=f93f5360-fa5c-4777-aa14-c91c4730e49a, clientId=st_httpd_10.0.0.20, userId=d733890d-f5be-449d-8e8e-efab9972fef1, ipAddress=10.0.0.24, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=https://10.0.0.20/protected/redirect_uri, code_id=1d8576e7-69d5-4549-85a6-e014f2a7c14d, username=user1#ovzwk4rr, authSessionParentId=1d8576e7-69d5-4549-85a6-e014f2a7c14d, authSessionTabId=bFfur4XdKlI

As shown above, a successful authentication can be monitored in "Audit Trail". If necessary, information can also be gathered directly by asking the database.

 

Tufin SecureChange

When trying to log authentication at SecureChange, only a log file at the CLI can be evaluated:
     /var/log/tomcat/securechange.log

A successful login is recorded here, e.g. for a local user (hcarr)

INFO 2021-03-16 21:21:22,066 [catalina-exec-19::c.t.s.s.AdminAuthenticatorHelper.performAuthentication] [user:system] authenticating hcarr
INFO 2021-03-16 21:21:22,072 [catalina-exec-19::c.t.s.s.UsernamePasswordAuthenticator.authenticate] [user:system] User ID: 4, User name: Henry Carr logged in.
...

A successful login is recorded here, e.g. for a user authenticated using an LDAP server (user1)

INFO 2021-03-16 21:24:36,345 [catalina-exec-15::c.t.s.s.AdminAuthenticatorHelper.performAuthentication] [user:system] authenticating user1
INFO 2021-03-16 21:24:36,351 [catalina-exec-15::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] Start authentication of user [user1].
INFO 2021-03-16 21:24:36,362 [catalina-exec-15::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] Successful authentication of user [user1]. The authenticated userName is [user1].
INFO 2021-03-16 21:24:36,369 [catalina-exec-15::c.t.s.s.LdapUserResolver.getLoggedInUserFromDb] [user:system] User user1 found in DB by LDAP ID kBxZxiVaE0uwfM5vdPy5pw==. DB id is 43
INFO 2021-03-16 21:24:36,372 [catalina-exec-15::c.t.s.s.UsernamePasswordAuthenticator.authenticate] [user:system] User ID: 43, User name: user1 logged in.
...

Trying wrong credentials (mleu) delivers

INFO 2021-03-16 21:23:52,088 [catalina-exec-18::c.t.s.s.AdminAuthenticatorHelper.performAuthentication] [user:system] authenticating mleu
INFO 2021-03-16 21:23:52,093 [catalina-exec-18::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] Start authentication of user [mleu].
WARN 2021-03-16 21:23:52,099 [catalina-exec-18::c.t.s.s.LdapUserResolver.authenticateUserByLdap] [user:system] The authentication of the user [mleu] is failed. User [mleu] does not exist when using filter [(&(sAMAccountType=805306368)(|(sAMAccountName=mleu)(userPrincipalName=mleu)))] and baseDN [cn=users,dc=aerasec,dc=labor].
INFO 2021-03-16 21:23:52,105 [catalina-exec-18::c.t.s.c.l.SCLdapServiceImpl.getLdapUser] [user:system] Searching for LDAP user mleu
INFO 2021-03-16 21:23:52,106 [catalina-exec-18::c.t.s.c.l.SCLdapServiceImpl.getLdapUser] [user:system] Searching for LDAP user mleu in LdapConfiguration Lab_AD
INFO 2021-03-16 21:23:52,114 [catalina-exec-18::c.t.s.c.l.SCLdapServiceImpl.findUserInLdap] [user:system] User not found in LDAP by name [mleu].

In any case, these data need to be forwarded to a central reporting tool.
Forwarding the content of these files can be done e.g., by syslog, using a Splunk Forwarder, or any other method.

 

 

 

Page 1 of 2
  • Start
  • Prev
  • 1
  • 2
  • Next
  • End
Bootstrap is a front-end framework of Twitter, Inc. Code licensed under MIT License. Font Awesome font licensed under SIL OFL 1.1.