Supported Mechanisms - Call-Level Interface Version 2

Teradata® Call-Level Interface Version 2 Reference for Workstation-Attached Systems

Product
Call-Level Interface Version 2
Release Number
16.20
Published
September 2019
Language
English (United States)
Last Update
2019-10-12
dita:mapPath
uny1527114222311.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-2418
lifecycle
previous
Product Category
Teradata Tools and Utilities

In general, mechanisms which perform authentication or validation do not require that a Teradata Database username and password be included as part of the logon string. If these items are supplied in conjunction with such a mechanism, they will effectively be ignored.

The following mechanisms are supported:

Kerberos

In all environments that support Kerberos, the user may supply a userid, password, domain (or a realm), and password. The domain or realm must be supplied separately as mechanism data. After the user’s identity has been verified by Kerberos, an implicit logon will proceed using the tendered userid as the Teradata username.

.logmech KRB5
.logdata joe@domain1@@mypassword
.logon mydbs/

For single-domain environments, the gateway can be configured so that the domain or realm need not be indicated (this is discussed in the relevant gateway documentation).

.logmech KRB5
.logdata joe@@mypassword
.logon mydbs/

Alternatively, a Kerberos-mediated SSO-style logon can be used by omitting the userid, password, and domain or realm, and password. In this case, Kerberos uses the security credentials associated with the current client session.

.logmech KRB5
.logon mydbs/

If required, the user may include Teradata accounting information as part of .logon command as follows:

.logmech KRB5
.logdata joe@domain1@@mypassword
.logon mydbs/,,2345889909

or

.logmech KRB5
.logdata joe@@mypassword
.logon mydbs/,,2345889909

or

.logmech KRB5
.logon mydbs/,,2345889909

In all of the above cases, there must exist a Teradata username defined in the target database that matches the actual or derived userid and, further, that username must have previously been granted the logon with null password privilege. The special “dbc” username cannot be used with this mechanism because “dbc” cannot be granted the logon with null password privilege (the DBS will return error 3790 in this case).

KRB5C

This mechanism is maintained for compatibility purposes only (TTU 8.0 and above communicating with Teradata Database pre-V2R6 that supports SSO or logon encryption) and should not generally be specified directly by the user. The teraSSO library will automatically determine the appropriate mechanism when interfacing to such a DBS, using the same logic as employed in TTU 7.1. Windows clients will use NTLMC or KRB5C for SSO (direct or third-party), TD1 otherwise; non-Windows clients will use TD1. In the event a user manually selects an incompatible mechanism, TERASSO_SECPKGMATCH_FAIL will be returned.

SPNEGO

Teradata Database employs the Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) to provide confidentiality and integrity while supporting non-LDAP external authentication for users logging on to Teradata Database through Windows .NET applications. The SPNEGO mechanism functions almost identically to the KRB5 mechanism, except that KRB5 cannot be used in a Windows .Net environment. See Kerberos.

NTLM

Windows to Windows environments only. The user may supply a userid, password, and domain. After the user’s identity has been verified by NTLM, an implicit logon will proceed using the tendered userid as the Teradata username.

.logmech NTLM
.logdata joe@domain1@@mypasswordjoe
.logon mydbs/

For single-domain environments, the gateway can be configured so that the domain or realm need not be indicated (this is discussed in the relevant gateway documentation).

.logmech NTLM
.logdata joe@@mypasswordjoe
.logon mydbs/

Alternatively, an NTLM-mediated SSO-style logon can be used by omitting the userid, domain, and password.omitting the userid, password, and domain or realm. In this case, NTLM uses the security credentials associated with the current client session.

.logmech NTLM
.logon mydbs/

If required, the user may include Teradata accounting information as part of .logon command as follows:

.logmech NTLM
.logdata joe@domain1@@mypasswordjoe
.logon mydbs/,,2345889909

or

.logmech NTLM
.logdata joe@@mypasswordjoe
.logon mydbs/,,2345889909

or

.logmech NTLM
.logon mydbs/,,2345889909

In all of the above cases, there must exist a Teradata username defined in the target DBS that matches the actual or derived userid and, further, that username must have previously been granted the logon with null password privilege. The special “dbc” username cannot be used with this mechanism because “dbc” cannot be granted the logon with null password privilege (the DBS will return error 3790 in this case).

For compatibility purposes, this is equivalent to the existing SSO feature. The existing third-party sign-on variant of SSO (NTLM only) will be supported for compatibility purposes. However, it is recommended that new applications use the logmech_name, logmech_data_ptr, and logmech_data_len fields in DBCAREA instead.

NTLMC

This mechanism is maintained for compatibility purposes only (TTU 8.0 and above communicating with Teradata Database pre-V2R6 that supports SSO or logon encryption) and should not generally be specified directly by the user. The teraSSO library will automatically determine the appropriate mechanism when interfacing to such a DBS, using the same logic as employed in TTU 7.1. Windows clients will use NTLMC or KRB5C for SSO (direct or third-party), TD1 otherwise; non-Windows clients will use TD1. In the event a user manually selects an incompatible mechanism, TERASSO_SECPKGMATCH_FAIL will be returned.

LDAP

The LDAP mechanism allows a user to be authenticated through LDAP and, optionally, to assume a role or user identity other than his or her own, as allowed by the appropriate directory settings.

The user may supply a userid, password, and domain or realm. The exact contents of the LDAP .logdata information necessarily depends largely upon how the site is using LDAP, how LDAP has been configured, etc. The samples below are only generic examples. After the user’s identity has been verified by LDAP, an implicit logon will proceed using the userid as the Teradata username. Brackets denote optional fields and commands.

.logmech LDAP
.logdata authcid=joe password=password [realm=myrealm]
.logon mydbs/

.logmech LDAP
.logdata joe[@myrealm]@@password
.logon mydbs/

.logmech LDAP
[.logdata realm=myrealm]
.logon mydbs/joe,password

If required, the user may include Teradata accounting information as part of .logon command as follows:

.logmech LDAP
.logdata authcid=joe password=password realm=myrealm
.logon mydbs/,,2345889909

If the directory maps the userid to a specific Teradata username, that username must be defined in the target DBS and must have previously been granted the logon with null password privilege. After the user’s identity has been verified by LDAP, an implicit logon will proceed using the tendered userid as the Teradata username. The special “dbc” username cannot be used with this mechanism because “dbc” cannot be granted the logon with null password privilege (the DBS will return error 3790 in this case).

If the directory does not map the userid to a specific Teradata username, a generic username will be used and a role assigned. The role will be derived from information contained in the directory. Logon will be by extended logon.

TD1 and TD2

TD1 and TD2 represent the Teradata mechanisms. They do not perform any authentication. Rather, they facilitate encryption/decryption for sessions connected absent the mediation of extended security. Therefore, a valid Teradata username and password are always required.

Only TD1 is used by TTU 7.1. TD2 is used by TTU 8.0 and above for Teradata Database V2R6; TD1 is used by TTU 8.0 and above for Teradata Database V2R5.1. The difference between the two mechanisms is that the encryption key for TD2 is longer (and, therefore, offers a higher degree of security) than that of TD1. For TD2, there should be no .logdata parameter; if one is passed to CLIv2, it will be ignored.

TD2 is shipped as the default mechanism for the server-based XML config file.

.logmech TD2
.logon mydbs/joe,password

TD1

TD1 is a deprecated mechanism used by TTU 7.1. It will also be used by TTU 8.0 and above when communicating with Teradata Database V2R5.x.

This mechanism is maintained for compatibility purposes only (TTU 8.0 and above communicating with Teradata Database V2R5.x) and should not generally be specified directly by the user. The teraSSO library will automatically determine the appropriate mechanism when interfacing to Teradata Database V2R5.x, using the same logic as used in TTU 7.1. Windows clients will use NTLMC or KRB5C for SSO (direct or third-party), TD1 otherwise. In the event a user manually selects an incompatible mechanism, TERASSO_SECPKGMATCH_FAIL will be returned.