Some feedback on correctly assessing your Satellite Connectors to ensure that you communicate the correct requirements to clients and can specify the correct framework to InfoSec and related departments.
TL;DR: If you have network segregation between your production and non-production environments, the single Satellite Connector provided as part of your PAoC subscription can only service one environment. Purchase additional connectors, one for each segmented environment.
At most of our customers, the production, QA, DEV (and possibly other environments are separated) i.e Network Segmentation or Environment Segmentation.
Essentially each environment cannot communicate with another and no traffic passes between them. This is purely a network level risk mitigation strategy to avoid any number of issues like someone in the development environment impacting a production system through code or other actions.
From a compliance point of view you may encounter terms like PCI-DSS, ISO-27001 or NIST.
With customers that have implemented this approach, typically financial institutions, pharma etc. etc. you need to consider that each environment requires its own SC installation.
Consider the diagram below:
PAoC environments are Production and Non-Production.
With the standard PAoC subscription you are given on Satellite Connector as part of the implementation.
The Satellite Connector can be configured with many end-points BUT where an endpoint needs to traverse into another environment e.g. Non-Prod, the standard single Satellite Connector implementation will not work. You will need to purchase additional Satellite Connectors for the other environments.
Essentially then you need to deploy something similar to the below assuming only one non-production environment:
Please consider this carefully especially at the outset of the project when sizing the environments and having those pre-sales discussions.
Getting this aspect right can save some very awkward discussions with clients later when additional funding for these connectors is needed.
Thanks to @Bill Primerano, @SAMI EL CHEIKH, @GERALD COON and @SATU HELIN for the call to discuss and clarify the above.
------------------------------
George Tonkin
Business Partner
MCI Consultants
Johannesburg
------------------------------
Original Message:
Sent: Tue July 22, 2025 10:17 AM
From: George Tonkin
Subject: MS SQL Server Windows authentication not supported for Satellite Connector when adding an SQL Server data source
Some feedback after some testing:
NB!!! If you are using SQL Server Driver 17, by default "Encrypt" is not ticked and thus traffic is unencrypted/unsecure.
I could not get confirmation that username and password are visible as clear text though.
You need to log a ticket to get this and any other settings updated.
Only settings that have been set can be interrogate. If a default value applies, you will not see the property value when querying the endpoint and would need to go through the ODBC manager on a local machine to see the possible options/properties/settings that you may need to change e.g. Encrypt=YES
A TI script with a parameter for the endpoint and leveraging some Powershell outputs the driver configuration/settings e.g.
Based on what you observe in the output file, you can then validate that changes have been made and/or changes to the default settings.
You may also want to upload SQL Server Driver 18 and log a ticket for IBM to install this so that you can use it instead of an older version.
By default in Driver 18, Encrypt is set to Mandatory but can also be set to Strict or Optional.
Hope this helps and please review your encryption settings if you are using an older SQL Server ODBC driver (or other driver) that needs encryption explicitly set.
(Thanks to Andy for sharing the original Powershell code and idea)
------------------------------
George Tonkin
Business Partner
MCI Consultants
Johannesburg
Original Message:
Sent: Thu July 17, 2025 02:39 AM
From: George Tonkin
Subject: MS SQL Server Windows authentication not supported for Satellite Connector when adding an SQL Server data source
We are configuring some endpoints on Satellite Connector for a PAoC instance for a financial services client with strict controls on authentication, firewalls etc.
Connection seems fine through the firewalls and proxies but seems to be failing to authenticate on SQL.
The SQL server we are connecting to only allows for windows authentication, no native/local logins.
IBM Support are saying not supported and reference this document which refers to Secure Gateway, not Satellite Connector.
Has anyone solved this issue? If not, what workarounds have you employed and were you forced to allow native/local logins?
Edit: Firewall blocks any calls where credentials being passed from TI are unencrypted. Looks like running the process or doing a preview is passing unencrypted credentials when testing native/local login. Passing no credentials assuming that it should use the service account credentials on the agent still fails as the firewall sees unencrypted requests.
------------------------------
George Tonkin
Business Partner
MCI Consultants
Johannesburg
------------------------------