Since many years it's possible to authenticate users and administrators of SecureTrack via LDAP Server. This method is different to the others using TACACS+ or RADIUS. Here, a user needs to be defined. In this profile, the authentication method is selected: Local, TACACS+ or RADIUS.

Authentication using LDAP is a little different. First of all attaching a LDAP Server to SecureTrack needs to be done by Menu > Configuration > External Authentication > LDAP

Testing if the authentication of SecureTrack at the LDAP Server with LDAP Bind password isn't possible yet.

The "Administrators group DN" includes a group of AD users that are entitled to have administrative rights in SecureTrack. "Users" with restricted rights are located in the "Users group DN".
These users are not listed in Menu > Configuration > Users until their first login, they don't need to be imported.

When a LDAP user logs in to SecureTrack the first time, SecureTrack will check his name and credentials using LDAP. Depending in which group the user is found he will geht the corresponding rights.

  • Administrators group:
    User gets full administrative rights, if a Multi-Domain environment is configured, the right will be "Super-Admin"

  • Users group:
    User has restricted rights as "user", if a Multi-Domain environment is configured the right will be "Multi-Domain Users". But with the first login no device is showed to the user. This right has to be configured manually by an administrator after first login of the users.

 Besides this, the user is shown in the list of configured users in SecureTrack with Authentication method LDAP.

 Each time such a user authenticates, the password is checked against the LDAP server.

 

 

 

 

Licensing in Tufin Orchestration Suite is done centrally in SecureTrack. Even if SecureChange / SecureApp is run on a separate server, licenses are stored in SecureTrack and published to the other machine. If a license is installed, it needs to be activated. This is quite easy using the "Generate" button. When getting the activated license, it should be installed in SecureTrack so it's bound to this system.

When switching from an Eval license to a permanent license (and vice versa) it might happen that the newly installed license isn't recognized correctly. In this case, some CLI commands regarding the database are useful.

 

Before you continue, create a BACKUP of your installation of SecureTrack!
It includes all configuration and also the license. Be careful when you use the commands below - without license Tufin Orchestration Suite will not work at all!

 

For getting further information or deleting licenses CLI access to SecureTrack is necessary.
As usual for Tufin commands, this needs to be done as root or using the sudo command.

Next steps could be:

Show the currently installed licenses
[root@TufinOS ~]# psql securetrack -Upostgres -c "select * from st_licenses"

 

Delete all licenses of type "full", i.e. "real" licenses
[root@TufinOS ~]# psql securetrack -Upostgres -c "delete from st_licenses where license_type='full'"

Delete all licenses of type "evaluation"
[root@TufinOS ~]# psql securetrack -Upostgres -c "delete from st_licenses where license_type='evaluation'"

Delete all licenses of both types, i.e. "full" and "evaluation"
[root@TufinOS ~]# psql securetrack -Upostgres -c "delete from st_licenses"

 

As written above, be careful with these commands and use them only when a current Backup is done!

 

 

 

 

 

 

Tufin points out that a vulnerability has been found in Tufin SecureTrack.

It's a XXE (XML External Entity) vulnerability described in Top 10-2017 A4-XML External Entities (XXE) which alows attackers to exploit vulnerable XML processors. They can upload XML or include hostile content in a XML document.

Tufin has provided a first fix to address this issue:

TOS 17-3 HF 4.1

For these versions fixes will be available and included, respectively:

TOS 18-1 HF 3  - scheduled to be published on September 5th, 2018

TOS 18-2 GA - Fix will be included in GA scheduled for release on August 22nd, 2018

Due to Tufin's policy regarding earlier versions no fix will be published for them. So if you use an older version, please do an upgrade to a supported version.

 

 

 

 

It's quite a good feature that reports in SecureTrack can be generated automatically and sent by E-Mail to recipients.
Sometimes the time mentioned in the reports seems to be wrong, even if following time settings are correct and all the same:

  • PC of the user  
  • SecureTrack Server
  • Monitored Device reported on

Even if all these time settings are ok, it might happen that e.g. the report is sent at 16:40 while the time in the report itself shows 17:40.

The reason for this behaviour is that PostgreSQL has another time zone configured. By default the time zone in TufinOS is "Israel".
This can be changed using these steps: 

Stop services

  • # service crond stop
  • # service tufin-jobs stop
  • # service jms stop
  • # service postgresql-9.4 stop

Edit configuration file

  • Backup and edit the file /var/lib/pgsql/9.4/data/postgresql.conf
    find the settings for
         log_timezone ='Israel'    
         timezone
    = 'Israel'
    and change them to your time zone, e.g. 'UTC' or 'Europe/Berlin' (the timezone needs to be listed in /usr/share/zoneinfo)

Start services

  • # service postgresql-9.4 start
  • # service jms start
  • # service tufin-jobs start
  • # service crond start
  • # service tomcat restart

After the services are started again in the correct order, the time used in reports should be correct. Restarting tomcat is necessary because otherwise the time of ticket creation in SecureChange isn't correct.

Hint: If the postresql service doesn't start, check the correct spelling of the time zone configured.

 

 

 

 

 

Working with SecureTrack mainly means to work with a Browser connected to the SecureTrack Server. If nothing is done, an automatic logout is initiated by the system. The time untli this logout happens, can be configured.

Sometimes a logout from the WebUI happens while the administrator works. This should not happen and seems to be a "feature" of versions up to and including 17-2.
With 17-3 and subsequent versions Tufin has changed the authentication method to Keycloak. These versions don't show this effect any more.

If there is a problem with automatic logout while working with the WebUI, an upgrade to 17-3 or newer is recommended.

 

 

 

When using Check Point Management R80.x besides the "normal" OPSEC connections a connect to the Check Point Management API is necessary.

How to connect Tufin SecureTrack with Check Point Management R80 is described here.

Even if the connection to the Check Point Management is ok, an error might be displayed: 
Checkpoint API client error

Testing the connection from SecureTrack using
Menu > Settings > Monitoring > Check Point Management R80 > Test Connectivity

seems successful, but the status icon of the device is yellow in SecureTrack. In Menu > Settings > Administration > Status > Check Point Management R80 > Status the error is shown and no new revisions are imported to SecureTrack.

Background information: "Test Connectivity" checks currently the OPSEC channel (used in R77.x) only. The second channel is the Management API which is necessary when monitoring R80.x.

Some troubleshooting might solve this issue. You can try one or more of the following things before restart monitoring the device:

  • Check that the Check Point Management monitored is really Version R80.x and not still Check Point R77.30. If that's the case, the device needs to be deleted and new defined as Check Point Management R77.30. There is no way to change the Check Point Version from R80.x back to the old one.
  • Check that Tufin SecureTrack is able to connect to Check Point management Server using port 443/tcp. Maybe a Firewall is blocking this traffic.
  • Check the credentials configured for the Tufin user at the Check Point Management Server.


  • Check the permissions of the Tufin user at the Check Point Management Server. This user needs rw even if there is no provisioning configured or planned.


  • Check the Expiration Date of the account, sometimes it's not the default value ending in 2030.
  • If all these measures don't help, try to restart the Management API at the Check Point Management Server. This can be done as "expert" using the command api restart.

 

If you have further ideas or if these items didn't help, please don't hesitate to contact us.