通常、認証または検証を実行するメカニズムでは、データベースのユーザー名とパスワードをログオン文字列の一部として含めることは要求されません。 当該メカニズムに従ってこれらの項目が提供される場合、これらは完全に無視されます。
以下のメカニズムがサポートされます。
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
このメカニズムは、互換性を保つことのみを目的として維持されており(SSOまたはログオン暗号化がサポートされているV2R6より前のTeradata Databaseと通信する、TTU 8.0以前のTTU)、通常はユーザーが直接指定してはいけません。teraSSOライブラリは、TTU 7.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
このメカニズムは、互換性を保つことのみを目的として維持されており(SSOまたはログオン暗号化がサポートされているV2R6より前のTeradata Databaseと通信する、TTU 8.0以前のTTU)、通常はユーザーが直接指定してはいけません。teraSSOライブラリは、TTU 7.1で採用されているのと同じロジックを使用して、そのようなデータベースに接続するときに適切なメカニズムを自動的に決定します。Windowsクライアントは、SSO(直接またはサードパーティ)に対してはNTLMCまたはKRB5Cを使用し、それ以外の場合はTD1を使用します。Windows以外のクライアントはTD1を使用します。ユーザーが互換性のないメカニズムを手動で選択した場合は、TERASSO_SECPKGMATCH_FAILが返されます。
LDAP
LDAPメカニズムにより、LDAPを介したユーザー認証を行なうことができます。さらにオプションとして、該当するディレクトリ設定で許可されたとおり、ユーザー自身の認証以外に、ロールやユーザーのIDを仮定することができます。
ユーザーは、ユーザーID、パスワード、およびドメインまたはレルムを指定できます。LDAPの.logdata情報の正確な内容は、サイトでLDAPがどのように使用されているか、LDAPがどのように構成されているかなどによって大きく異なります。次のサンプルは一般的な例にすぎません。ユーザーのIDが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ユーザー名にマップされない場合、ユーザー名の総称が使用され、ロールが割り当てられます。 このロールは、ディレクトリに記載された情報から生じます。 ログオンは、拡張ログオンとなります。
BROWSER
BROWSERメカニズムを使用すると、OpenID ConnectプロトコルをサポートするフェデレーションIDプロバイダーを使用してユーザーを認証できます。ブラウザ認証は、WindowsおよびMacOSでのみサポートされています。データベースは、フェデレーション認証用のIDプロバイダー情報を使用して構成する必要があります。このタスクは、リファレンス<Teradata Vantage™ - Analytics Databaseセキュリティ管理ガイド, B035-1100>で説明されています。
ブラウザ認証を使用する場合、アプリケーションは、ユーザー名、パスワード、またはログオン メカニズムのデータを提供すべきではありません。代わりにCLIは、デフォルトのブラウザを起動し、ユーザーをIDプロバイダーのログオン ページに誘導します。
.set logmech BROWSER
.logon mydbs/
UserId:
Password:
インタラクティブBTEQを使用する前の例では、ユーザーIDとパスワードの入力を求められたら、Enterキーを押します。デフォルトのブラウザが起動し、ユーザーにユーザーIDとパスワードの入力を求めます。認証されると、ログオン プロセスは正常に完了します。
TD1、TD2
TD1とTD2は、Teradataのメカニズムを示します。 これらは認証を実行しません。 むしろ、拡張セキュリティを仲介しないセッションでの暗号化/復号化を可能にします。 したがって、Teradataの有効なユーザー名、パスワードが常に必要です。
TTU 7.1ではTD1のみが使用されます。TTU 8.0以前では、Teradata Database V2R6に対してはTD2が使用され、Teradata Database V2R5.1に対してはTD1が使用されます。これら2つのメカニズムの違いは、TD2の暗号鍵がTD1の暗号鍵よりも長いことです(したがって、より高度なセキュリティが提供されます)。TD2の場合、.logdataパラメータはなく、CLIv2に渡された場合は無視されます。
TD2は、サーバー ベースのXML構成ファイルのデフォルト メカニズムとして出荷されています。
.logmech TD2 .logon mydbs/joe,password
TD1
TD1は、TTU 7.1で使用される非推奨のメカニズムであり、TTU 8.0以前でも、Teradata Database V2R5.xとの通信時に使用されます。
このメカニズムは、互換性を保つことのみを目的として維持されており(V2R5.xのTeradata Databaseと通信する、TTU 8.0以前のTTU)、通常はユーザーが直接指定してはいけません。teraSSOライブラリは、TTU 7.1で採用されているのと同じロジックを使用して、そのようなデータベースに接続するときに適切なメカニズムを自動的に決定します。Windowsクライアントは、SSO(直接またはサードパーティ)に対してはNTLMCまたはKRB5Cを使用し、それ以外の場合はTD1を使用します。ユーザーが互換性のないメカニズムを手動で選択した場合は、TERASSO_SECPKGMATCH_FAILが返されます。