- 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
Setting | Description |
---|---|
Authentication Mechanism | Set to Trusted. |
Username | Set to the proxy user name. |
Password | Set to the password for proxy user. |
TD2
Setting | Description |
---|---|
Authentication Mechanism | Set to TD2. |
Username | Set to the authorization user name. |
Password | Set to the password for the authorized user. |
LDAP
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
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.
- 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
- 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
- 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.