When configuring Tufin SecureChange, the corresponding SecureTrack server needs to be connected to the SecureChange server.
So in a first step an administrative user is configured in SecureTrack. This user is for a later authentication of SecureChange at SecureTrack.

  • Hint:
    Don't use reserved words like "Securechange" as username. This user won't be able to authenticate.

So if the user for SecureChange is configured, test it by logging in using the WebUI. If this works, SecureChange also will be able to authenticate.

  • Hint:
    The Authentication of SecureChange at SecureTrack is machine based. Using a certificate is currently not possible.
    So use a very strong password not known to any person for this purpose.

The next step is to log in at SecureChange with permission to configure "Settings". In the menu select "SecureTrack".

This information needs to be provided if SecureTrack isn't configured to run on the same system as SecureChange:

  1. Select "Remote host" and provide the IP address of SecureTrack, SecureChange will connect to.
  2. Provide user name and password as configured in SecureTrack.
  3. optional: "Show link to SecureTrack" - sometimes useful for admins, but maybe confusing end users working with SecureChange. It selected, the IP address configured in (1) will be linked here.
  4. Provide "Internal IP of SecureChange server" means to fill in the IP address SecureTrack uses for connections to SecureChange. This IP address will also be in the link to SecureChange shown in the login screen of SecureTrack.

For (1) as (4) a host name can be configured also, but this name needs to be resolved using DNS.

If the configuration is ready, try the button "Test connection" on the right bottom of the page. This will test the connection and deliver a result. This result can be, that an authentication error has occurred, the connection couldn't be established - or that the connection is ok. If this is the case, press "Save" and the task is finished.

  • Hint:
    The test done checks not only the connection from SecureChange to SecureTrack, but also from SecureTrack to SecureChange. So it might happen that you can connect from SecureChange to SecureTrack using 443/tcp - and the WebUI delivers a connection error. This is because maybe the back connection from SecureTrack to SecureChange isn't possible. In this case, error message might point to other reasons. So it's useful to check the back connection.

Connecting SecureChange to SecureTrack is essential, since the license is held in SecureTrack. Besides this, SecureChange uses features of SecureTrack like e.g. Zones and USP as well as the Topology.