Teradata Target Connector | Security Guidelines | QueryGrid - Teradata Target Connector Security Guidelines - Teradata QueryGrid

QueryGridâ„¢ Installation and User Guide - 3.06

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
Lake
VMware
Product
Teradata QueryGrid
Release Number
3.06
Published
December 2024
ft:locale
en-US
ft:lastEdition
2024-12-07
dita:mapPath
ndp1726122159943.ditamap
dita:ditavalPath
ft:empty
dita:id
lxg1591800469257
Product Category
Analytical Ecosystem
Teradata connectors support Trusted, TD2, LDAP, Kerberos, Kerberos SSO, JWT SSO, and TDNEGO security mechanisms when acting as target connectors. The following considerations apply to each of the security mechanisms:
  • QueryGridâ„¢ Components and Connectors Compatibility Matrix
  • The username and password assigned and communicated from the initiator connector takes precedence over the one defined for the Teradata target connector properties.

    For example, if the Teradata initiator provides an authorization object, it takes precedence over security-related connector property settings. Defining these connector properties is optional. If, however, credentials are not provided by the initiator connector, a username and password must exist in its connector property settings.

  • If changing credentials on the database for a QueryGrid user, you must also change the credentials on the connector. By not updating the connector credentials, old cached connections may allow queries to succeed that will later fail when the connections expire from the cache.
  • An Administrator can define user mappings in the QueryGrid portlet if the initiator end user differs from the remote system end user. This is the user to which you have granted CONNECT THROUGH on the remote system.
  • For user mapping, the local user submitting the query is mapped to the remote user that submits the query. User mapping applies as follows:
    • For a Teradata initiator connector, use user mapping when it is set up with DEFINER authorization provided that the local user submitting the query is the not the same as the authenticating user.
    • For a target connector, user mapping is applicable when set up with TRUSTED authentication mechanism and the remote user is not the same as the authenticating user.
    • For a target connector, user mapping is applicable for TD, TDNEGO, LDAP, or Kerberos authentication mechanisms when the Use Trusted connector property is set to true and the remote user is not the same as the authenticating user.

Trusted

Trusted User or Service Accounts are a proxy user that act on behalf of the local user. You configure trusted sessions by granting CONNECT THROUGH privileges to proxy user or permanent end user. To do this perform the following steps on the remote system:

CREATE USER proxyuser AS PERM = 0 PASSWORD = password;
GRANT CONNECT THROUGH proxyuser TO PERMANENT target_end_user without role;
>> this target_end_user is the user that has access to objects that we will access from local system
The following property settings are required for Teradata target connectors using the Trusted security model.
Setting Description
Authentication Mechanism Set to Trusted.
Username Set to the proxy user name.
Password Set to the password for proxy user.

TD2

The following property settings are required for Teradata target connectors using the TD2 security model.
Setting Description
Authentication Mechanism Set to TD2.
Username Set to the authorization user name.
Password Set to the password for the authorized user.

LDAP

You can configure Teradata target connectors to use LDAP authentication involving a username and password. This means that queries with a Teradata target can be submitted using the LDAP security mechanism to authenticate; for example, the Presto-to-Teradata connection supports LDAP. The following properties must be configured to use LDAP with Teradata target connectors.
Setting Description
Authentication Mechanism Set to LDAP.
Username Set to the LDAP directory user name.
Password Set to the password for the user.

For detailed information about how to configure Teradata target connectors to use LDAP authentication, refer to the Security: User Authentication and Directory Integration Orange Book, 541-0004998.

Kerberos

Teradata Kerberos set up must be completed before configuring QueryGrid. The following property settings are required for Teradata target connectors using the Kerberos security model.
Setting Description
Authentication Mechanism Set to Kerberos.
Username Set to the Kerberos principal name.
Password Set to the password for the Kerberos principal name.

QueryGrid authenticates a principal using a password.

Realm Set to the Kerberos realm.

For more information, see Teradata Connector and Link Properties.

Kerberos SSO

QueryGrid supports the Kerberos single sign-on (SSO) feature using the authentication mechanism, Kerberos SSO, in a Teradata-to-Teradata link. You must complete the Kerberos set-up on the initiator and target systems before configuring QueryGrid. The Kerberos token is carried from the initiator to the target database when establishing a connection. Any Kerberos-related properties such as username, password, and realm are ignored if provided in the connector properties or authorization object.

See Kerberos Single Sign-On for more information.

JWT SSO

QueryGrid supports the JSON Web Token single sign-on (SSO) feature using the JWT SSO authentication mechanism in a Teradata-to-Teradata link. No target credentials are required to be passed in either the connector properties or in the authorization object. Both the initiator and the target systems must be configured with SSO before configuring QueryGrid. The JWT is carried from the initiator to the target database where QueryGrid performs a token exchange to get a new token that works for that target system.

The following considerations apply to JWT SSO:
  • This feature is supported by Teradata Vantage 17.20 and later.
  • Both the initiator and the target systems must be configured with SSO to work with token exchange (either On Behalf Of or Standard Token Exchange).
  • The sign-on from the initiating Teradata system must be using the JWT mechanism.
  • The dbscontrol flag ForwardCredential on the initiating Teradata system must be set to TRUE (default) to enable this feature in the database.
  • The connector diagnostic check is not supported when the authentication mechanism is JWT SSO.
  • The IdP URL provided in the connector properties should be accessible from target driver node.

TDNEGO

When configuring the TDNEGO authentication mechanism, the actual authentication mechanism is automatically determined by TDGSS without user involvement. Teradata recommends this process for the use case where the correct authentication mechanism to use is unknown. Set the authentication mechanism as TDNEGO and provide the credentials either in the authorization object or in the connector properties.
  • TDNEGO Supported Authentication Mechanisms: TD2, LDAP, Kerberos, and Kerberos SSO
  • Availability: On all supported client and server platforms
  • Username and Password: Based on the chosen authentication mechanism

TDNEGO is enabled by default on both the server and client. The order of negotiation with SQLE is the same as the order of authentication mechanisms in the configuration file TdgssUserConfigFile.xml.

Teradata Gateway Encryption

HTTPS/TLS connections are available with the Teradata JDBC driver 17.10.00.07 and compatible with the following databases:
  • SQL Engine 17.10 and later
  • SQL Engine 16.20.53.30 and later

JDBC supports this by default on port 443 when the target Analytics Database is enabled with TLS. If TLS is enabled on a port other than port 443, use the connector properties JDBC Communication over TLS and TLS Port.