通常、認証または検証を実行するメカニズムでは、データベースのユーザー名とパスワードをログオン文字列の一部として含めることは要求されません。 当該メカニズムに従ってこれらの項目が提供される場合、これらは完全に無視されます。
以下のメカニズムがサポートされます。
Kerberos
Kerberosをサポートするすべての環境において、ユーザーはユーザーID、パスワード、ドメイン(または領域)、パスワードを提供できます。 ドメインまたは領域は、メカニズムのデータとして、個別に提供する必要があります。 ユーザーの身元がKerberosによって確認されると、提示されたユーザーIDをTeradataのユーザー名として用い、暗黙のログオンが進められます。
.logmech KRB5 .logdata joe@domain1@@mypassword .logon mydbs/
シングル ドメイン環境の場合、ドメインまたは領域の提示が不要となるよう、ゲートウェイを構成できます(ゲートウェイ関連文書の説明を参照してください)。
.logmech KRB5 .logdata joe@@mypassword .logon mydbs/
別の選択肢として、ユーザーID、パスワード、ドメイン/領域、パスワードを省略することで、Kerberosを利用したSSOスタイルのログオンを使用できます。 この場合、Kerberosは現在のクライアント セッションに関連付けられた、セキュリティ証明を使用します。
.logmech KRB5 .logon mydbs/
ユーザーは必要に応じて、以下のように.logonコマンドの一部としてTeradataのアカウント情報を含めることができます。
.logmech KRB5 .logdata joe@domain1@@mypassword .logon mydbs/,,2345889909
または
.logmech KRB5 .logdata joe@@mypassword .logon mydbs/,,2345889909
または
.logmech KRB5 .logon mydbs/,,2345889909
上記のすべてのケースにおいて、ターゲット データベースで定義されたTeradataユーザー名が存在する必要があります。このユーザー名は、実際または派生のユーザーIDと一致し、さらにNULLパスワード権限を持つログオンが事前に許可されている必要があります。特別なユーザー名「dbc」は、NULLパスワード権限を持つログオンを許可できないため、同メカニズムで用いることはできません(この場合、データベースがエラー3790を返します)。
KRB5C
同メカニズムは、互換性の目的においてのみ維持されており(TTU8.0以降とV2R6以前のTeradata Databaseとの通信で、SSOまたはログオンの暗号化をサポート)、通常はユーザーが直接指定することはできません。teraSSOライブラリは、当該データベースへのインターフェース時、TTU7.1と同一のロジックを用いて、適切なメカニズムを自動的に判定します。Windowsクライアントは、SSOにNTLMCまたはKRB5Cを使用し(ダイレクトまたはサードパーティ)、そうでない場合はTD1を使用します。非WindowsクライアントはTD1を使用します。ユーザーが互換性のないメカニズムを手動で選択した場合、TERASSO_SECPKGMATCH_FAILが返されます。
SPNEGO
データベースでは、Simple and Protected GSSAPI Negotiation Mechanism(SPNEGO)を採用することにより、Windows .NETアプリケーションからデータベースにログオンするユーザーに対して非LDAPの外部認証をサポートしつつ、機密性と保全性を提供しています。KRB5メカニズムはWindows .NET環境で使用できないという点を除いて、SPNEGOメカニズムの機能はKRB5とほぼ同じです。Kerberosを参照してください。
NTLM
Windows間の環境のみで使用します。 ユーザーはユーザーID、パスワード、ドメインを指定できます。 ユーザーの身元がNTLMによって確認されると、提示されたユーザーIDをTeradataのユーザー名として用い、暗黙のログオンが進められます。
.logmech NTLM .logdata joe@domain1@@mypasswordjoe .logon mydbs/
シングル ドメイン環境の場合、ドメインまたは領域の提示が不要となるよう、ゲートウェイを構成できます(ゲートウェイ関連文書の説明を参照してください)。
.logmech NTLM .logdata joe@@mypasswordjoe .logon mydbs/
別の選択肢として、ユーザーID、ドメイン、パスワードを省略することで、NTLMを利用したSSOスタイルのログオンを使用できます。 この場合、NTLMは現在のクライアント セッションに関連付けられた、セキュリティ証明を使用します。
.logmech NTLM .logon mydbs/
ユーザーは必要に応じて、以下のように.logonコマンドの一部としてTeradataのアカウント情報を含めることができます。
.logmech NTLM .logdata joe@domain1@@mypasswordjoe .logon mydbs/,,2345889909
または
.logmech NTLM .logdata joe@@mypasswordjoe .logon mydbs/,,2345889909
または
.logmech NTLM .logon mydbs/,,2345889909
上記のすべてのケースにおいて、ターゲット データベースで定義されたTeradataユーザー名が存在する必要があります。このユーザー名は、実際または派生のユーザーIDと一致し、さらにNULLパスワード権限を持つログオンが事前に許可されている必要があります。特別なユーザー名「dbc」は、NULLパスワード権限を持つログオンを許可できないため、同メカニズムで用いることはできません(この場合、データベースがエラー3790を返します)。
互換性の目的においては、NTLMは既存のSSO機能と等価です。SSOにおけるサードパーティのサインオン バリアントは、互換性のためサポートされます。ただし、ただし、Teradataでは、新規アプリケーションでDBCAREAのlogmech_name、logmech_data_ptr、logmech_data_lenフィールドを代用することを推奨します。
NTLMC
同メカニズムは、互換性の目的においてのみ維持されており(TTU8.0以降とV2R6以前のTeradata Databaseとの通信で、SSOまたはログオンの暗号化をサポート)、通常はユーザーが直接指定することはできません。teraSSOライブラリは、当該データベースへのインターフェース時、TTU7.1と同一のロジックを用いて、適切なメカニズムを自動的に判定します。Windowsクライアントは、SSOにNTLMCまたはKRB5Cを使用し(ダイレクトまたはサードパーティ)、そうでない場合はTD1を使用します。非WindowsクライアントはTD1を使用します。ユーザーが互換性のないメカニズムを手動で選択した場合、TERASSO_SECPKGMATCH_FAILが返されます。
LDAP
LDAPメカニズムにより、LDAPを介したユーザー認証を行なうことができます。さらにオプションとして、該当するディレクトリ設定で許可されたとおり、ユーザー自身の認証以外に、ロールやユーザーのIDを仮定することができます。
ユーザーはユーザーID、パスワード、さらにドメインや領域を指定できます。 LDAP .logdataの正確な中身は、サイトでのLDAPの使用方法や、LDAPの構成方法等によって必然的に異なります。以下のサンプルは、一般例のみを示しています。 ユーザーの身元がLDAPによって確認されると、ユーザーIDをTeradataのユーザー名として用い、暗黙のログオンが進められます。 大括弧は、任意選択のフィールドとコマンドを示します。
.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
ユーザーは必要に応じて、以下のように.logonコマンドの一部としてTeradataのアカウント情報を含めることができます。
.logmech LDAP .logdata authcid=joe password=password realm=myrealm .logon mydbs/,,2345889909
ディレクトリで、ユーザーIDが特定のTeradataユーザー名にマップされる場合、このユーザー名はターゲット データベースで定義され、NULLパスワード権限を持つログオンが事前に付与されている必要があります。ユーザーの身元がLDAPによって確認されると、提示されたユーザーIDをTeradataのユーザー名として用い、暗黙のログオンが進められます。特別なユーザー名「dbc」は、NULLパスワード権限を持つログオンを許可できないため、同メカニズムで用いることはできません(この場合、データベースがエラー3790を返します)。
ディレクトリで、ユーザーIDが特定のTeradataユーザー名にマップされない場合、ユーザー名の総称が使用され、ロールが割り当てられます。 このロールは、ディレクトリに記載された情報から生じます。 ログオンは、拡張ログオンとなります。
TD1、TD2
TD1とTD2は、Teradataのメカニズムを示します。 これらは認証を実行しません。 むしろ、拡張セキュリティを仲介しないセッションでの暗号化/復号化を可能にします。 したがって、Teradataの有効なユーザー名、パスワードが常に必要です。
TD1のみ、TTU 7.1で使用されます。TD2は、Teradata Database V2R6のTTU 8.0以降、TD1はTeradata Database V2R5.1のTTU 8.0以降で使用されます。これらのメカニズムの違いは、TD2の暗号キーがTD1の暗号キーより長いことです(したがって、TD2の方が高レベルのセキュリティを提供します)。 TD2の場合、.logdataパラメータを使用してはならず、同パラメータがCLIv2に渡された場合は無視されます。
TD2は、サーバー ベースのXML構成ファイルのデフォルト メカニズムとして出荷されています。
.logmech TD2 .logon mydbs/joe,password
TD1
TD1は、TTU 7.1で使用される、旧式のメカニズムです。Teradata Database V2R5.xとの通信時には、TTU 8.0以降でも使用されます。
同メカニズムは、互換性の目的においてのみ維持されており(TTU8.0以降とTeradata Database V2R5.xとの通信)、通常はユーザーが直接指定することはできません。teraSSOライブラリは、Teradata Database V2R5.xへのインターフェース時、TTU7.1と同一のロジックを用いて、適切なメカニズムを自動的に判定します。Windowsクライアントは、SSOにNTLMCまたはKRB5Cを使用し(ダイレクトまたはサードパーティ)、そうでない場合はTD1を使用します。ユーザーが互換性のないメカニズムを手動で選択した場合、TERASSO_SECPKGMATCH_FAILが返されます。