In general, mechanisms which perform authentication or validation do not require that a 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 previous 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 database will return error 3790 in this case).
SPNEGO
The 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 the 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.
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 following samples 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 database 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 database 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.
BROWSER
The BROWSER mechanism allows a user to be authenticated using a federated identity provider that supports the OpenID Connect protocol. Browser authentication is supported on Windows and Mac OS only. The database must be configured with Identity Provider information for Federated Authentication. This task is covered in the reference Teradata Vantage™ - Analytics Database Security Administration, B035-1100.
The application should not provide username, password, or logon mechanism data when using browser authentication. Instead, CLI will launch the default browser and direct the user to the logon page for the identity provider.
.set logmech BROWSER
.logon mydbs/
UserId:
Password:
In the previous example using interactive BTEQ, when prompted for UserId and Password, hit Enter. The default browser will launch and prompt the user for a UserId and Password. Once authenticated, the logon process will complete successfully.
TD2
TD2 represents the Teradata mechanism. It does not perform any authentication. Rather, it facilitates encryption/decryption for sessions connected absent the mediation of extended security. Therefore, a valid Teradata username and password are always required.
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