Teradata Initiator Connector | Security and User Sessions | Teradata Fabric - Teradata Initiator Connector Security and User Sessions - Teradata Fabric

Teradata® Fabric - Installation and User Guide - 3.11

Product
Teradata Fabric
Release Number
3.11
Published
August 2026
ft:locale
en-US
ft:lastEdition
2026-08-15
dita:mapPath
svw1780362788070.ditamap
dita:ditavalPath
ezw1784752870623.ditaval
dita:id
lxg1591800469257

The Teradata initiator connector has a mechanism in the foreign server definition called an authorization object, which contains the authenticating username and password for the remote system. This works for either a one-to-one user mapping or a many-to-one user mapping (used for trusted users or service accounts).

For more information, see Teradata® Database SQL Data Definition Language - Detailed Topics, B035-1184.

Teradata Fabric also provides a user mapping mechanism associated with the foreign server definition that permits the mapping of user names. This permits users to be mapped for data centers that do not use a common user identification across all systems. You can configure the user mapping table in the Teradata Fabric portlet.

User mapping allows users logged on to the initiating system to be mapped to another user on the remote system.

For user mapping, set up the Teradata initiator connector with DEFINER authorization.

Teradata provides a user configurable mechanism for authenticating to Kerberos. The user and password is used to obtain a ticket from the KDC when attempting to connect to a remote Kerberized Teradata.

Session Settings

Session settings are passed from the initiating Teradata system to the target Teradata system.
  • ANSI and TERA mode affect transaction semantics.
  • QueryBand can be used for workload management to map TASM rules from the local to the target system or to help associate child queries with the initiating Teradata query for monitoring purposes. Teradata Fabric appends the following name-value pairs (NVPs) to the QueryBand of the target Teradata session with values from the initiating Teradata session. If a query traverses through more than one Teradata-Teradata link, each system appends its session attributes to these NVPs delimited by a colon.
    • QG_UUID
    • TD_HOSTID
    • TD_QUERYID
    • TD_REQUEST
    • TD_SESSION
    • TD_USER
    The following example shows three systems, A, B, and C, with the query initiated on System A.
    Select * from foreign table(select * from tab@systemC)@systemB as dt
    [QueryBand] System A session = ‘name1=value;’
    [QueryBand] System B session = ‘name1=value;QG_UUID=<uuid1>;TD_HOSTID=<hostA>;TD_QUERYID=<queryidA>;TD_REQUEST=<requestA>;TD_SESSION=<sessionA>;’
    [QueryBand] System C session = 'name1=value;QG_UUID=<uuid1>:<uuid2>;TD_HOSTID=<hostA>:<hostB>;TD_QUERYID=<queryidA>:<queryidB>;TD_REQUEST=<requestA>:<requestB>;TD_SESSION=<sessionA>:<sessionB>;’