To enable network security, an Authentication Mechanism that corresponds to one of the mechanisms configured on the gateway by a system administrator must be specified, and other parameters such as password and username must be passed from the client application through network security. Table 28 summarizes the authentication mechanisms.
|
Authentication Mechanism |
Name |
Client/Servers |
Description |
|
Teradata 2 |
TD2 |
All |
The Teradata 2 (TD2) mechanism provides authentication using a Teradata Database username and password. The difference between Teradata 1 and Teradata 2 is that the Teradata 2 encryption key offers a higher degree of security. Encryption: When the Teradata 2 (TD2) mechanism is selected, both logon string and data are encrypted. Availability: The Teradata 2 mechanism is available on all supported client and server platforms. Username and Password: A valid Teradata username and password are always required. |
|
TDNEGO |
TDNEGO |
All |
A security mechanism that automatically determines the actual mechanism required, based on policy, without user's involvement. The actual mechanism is determined by the TDGSS server configuration and by the security policy's mechanism restrictions. This simplifies user logons, because the user does not need to specify which logon mechanism to use. It also provides better ease of use and improved support for applications and tools which do not support specification of logon mechanisms. The Client and Server versions of TDNEGO automatically negotiate and select an appropriate TDGSS security mechanism to use. Encryption: Depends based on the chosen mechanism. Availability: The TDNEGO mechanism is available on all supported client and server platforms. Username and Password: Depends based on the chosen mechanism. |
|
LDAP |
LDAP |
All w/LDAPv3 Library |
When the LDAP authentication mechanism is employed, the server authenticates by binding to the LDAP directory using the username and password. Encryption: When LDAP is selected, both the logon string and data are encrypted. Availability: The LDAP mechanism is available on all supported client and server platforms, which provide an LDAPv3 compliant library. Username and Password: The application supplies a username, password, and domain or realm. When the user has been authenticated, an implicit logon will proceed using a Teradata username derived from the directory. The gateway directory maps the username to a specific Teradata username or to the system-defined username EXTUSER. If the directory maps the username to a specific Teradata username, then that user must have previously been granted the logon with null password privilege. If the directory maps to EXTUSER, then the characteristics of the user (role, rights, space, and so forth) are determined from settings in the directory. |
|
Kerberos |
KRB5 |
Windows Linux |
Once the identity of the user has been verified by Kerberos (KRB5), the KRB5 mechanism implicit logon proceeds using the same username as the Teradata username. Encryption: When KRB5 is selected, both the logon string and data are encrypted. Availability: The KRB5 mechanism is available on Windows and Linux clients and servers. Username, Password, Domain and Realm: The application supplies a username, password, and domain or realm. The username must have previously been granted the logon with null password privilege. Single Sign On: The Kerberos (KRB5) mechanism supports SSO where no username and password are provided explicitly by the application, but both are derived from the security context of the application. For KRB5 authentication, ODBC Driver for Teradata performs reverse DNS lookup and must succeed. The reverse lookup result must be the FQDN of the Teradata Database node. |
|
Kerberos Compatibility |
KRB5C |
Windows Linux |
The Kerberos Compatibility (KRB5C) mechanism uses the security credentials associated with the current client session. Encryption: When KRB5C is selected, the logon string is encrypted, but there is no data encryption. Availability: The KRB5C mechanism is available on Windows clients and servers. It is only provided for compatibility. Username, Password and Domain: No username, password, or domain is supplied. Single Sign On: The KRB5C mechanism supports SSO. |
|
NTLM |
NTLM |
Windows |
When using the NTLM authentication mechanism, once the user's identity has been verified by NTLM, an implicit logon will proceed using the same username as the Teradata username. Encryption: When NTLM is selected, both the logon string and data are encrypted. Availability: The NTLM mechanism is available on Windows clients and servers. Username and Password: The application supplies a username, password, and domain. The username must have previously been granted the logon with null password privilege. Single Sign On: NTLM supports SSO. |
|
NTLM Compatibility |
NTLMC |
Windows |
The NTLMC authentication mechanism uses the security credentials associated with the current Windows client session. Encryption: When NTLMC is selected, the logon string is encrypted, but there is no data encryption. Availability: NTLMC is only available on Windows clients and servers and is only provided for compatibility. Username and Password: No username, password, or domain is supplied. Single Sign On: NTLMC supports SSO. |
|
Other |
To be determined |
All |
Users can define other authentication mechanisms. Encryption: A user-defined mechanism can also provide logon and data encryption. Username and Password: Input to a mechanism will be the username, password, and possibly authentication information specific for the particular mechanism. |