TCP/IP ネットワークでのクライアントのセキュリティー

接続性のシナリオが異なれば、異なるレベルの認証を使用することが求められます。したがって、管理者は、サーバーへ接続するときに、より望ましい認証方式フィールドを各 RDB ディレクトリー項目に設定することにより、クライアントで必要な最低のセキュリティー認証方式を設定できます。

さらに管理者は、より低いセキュリティー認証方式を許可するよう選択することにより、認証方式についての決定をサーバーと折衝することを可能にできます。この場合、より望ましい認証方式は試行中になりますが、サーバーがより望ましい方式を受け入れられない場合、システムのセキュリティー設定や、暗号化サポートの可用性などの他の要因に応じ、より低い方式を使用できます。たとえば、2 つのシステムが物理的に保護されていない環境にある場合、管理者は、より低いセキュリティー認証方式を許可せずに Kerberos 認証を必須とするよう選択できます。

暗号化サーバー認証方式を RDB ディレクトリー項目で使用する場合は、オプションで、RDB ディレクトリー項目の追加 (ADDRDBDIRE) コマンドまたは RDB ディレクトリー項目の変更 (CHGRDBDIRE) コマンドに *DES 暗号化アルゴリズムまたは *AES 暗号化アルゴリズムを指定することができます。ENCALG(*DES) または ENCALG(*AES) は、ユーザー ID またはパスワードの暗号化のためにクライアントから要求される暗号化アルゴリズムを決定します。DDM ファイルでも、DDM ファイル作成 (CRTDDMF) コマンドまたは　DDM ファイル変更 (CHGDDMF) コマンドの RMTLOCNAME キーワードに *RDB 値を指定して DDM ファイルを作成し、RDB キーワードに RDB を指定することにより、*AES 暗号化を利用することができます。すべてのデータを暗号化する場合には、SSL を使用すると、ネットワークを介するすべてのデータが暗号化され、さまざまな暗号化タイプがサポートされます。

以下の設定は、暗号化認証方式のためにクライアントから要求される暗号化アルゴリズムを設定するのに使用できます。

ENCALG(*AES)
Advanced Encryption Standard (AES) 暗号化アルゴリズムが要求されます。
ENCALG(*DES)
Data Encryption Standard (DES) 暗号化アルゴリズムが要求されます。これはデフォルトです。

クライアント・サイドでは、2 つの方式のいずれかを使用して、DRDA® TCP/IP 接続要求でユーザー ID と共にパスワードを送信することができます。これらの 2 つの方式のいずれも使用しない場合、SQL CONNECT ステートメントは、この接続試行でユーザー ID のみを送信します。

1 番目のパスワードの送信方式は、以下の対話式 SQL 環境の例のように、SQL CONNECT ステートメントの USER/USING 形式を使用するというものです。

CONNECT TO rdbname USER userid USING 'password'

組み込み SQL を使用したプログラムでは、ユーザー ID とパスワードの値は USER/USING データベースのホスト変数に含められます。

CLI を使用するプログラムで、DRDA クライアントに対し、ユーザー ID とパスワードをホスト変数で表す方法は、次の例で示します。

SQLConnect(hdbc,sysname,SQL_NTS,					/*do the connect to the server */
			  uid,SQL_NTS,pwd,SQL_NTS);

2 番目の方式はサーバー認証項目です。TCP/IP を使用した接続要求で送信するユーザー ID とパスワードを定義します。サーバー認証項目リストは、システム上のすべてのユーザー・プロファイル、グループ・プロファイル、または補足グループ・プロファイルに関連付けられています。デフォルトでこのリストは空ですが、サーバー認証項目の追加 (ADDSVRAUTE) コマンドを使用して項目を追加できます。

権限の要件: ADDSVRAUTE コマンドを使用するには、以下の権限が必要です。

セキュリティー管理者 (*SECADM) ユーザー特殊権限
オブジェクト管理 (*OBJMGT) ユーザー特殊権限
サーバー認証項目が追加される、またはサーバー認証のサインオンに使用される、ユーザー・プロファイルに対する使用 (*USE) 権限

ADDSVRAUTE コマンドを使用してパスワードを保管するには、QRETSVRSEC システム値を '1' に設定する必要があります。デフォルトでは、この値は '0' です。この値を変更するには、次のコマンドを入力してください。

CHGSYSVAL QRETSVRSEC VALUE('1')

以下の例は、RDB ディレクトリー項目を使用する際の ADDSVRAUTE コマンドの構文を示しています。

ADDSVRAUTE USRPRF(user-profile) SERVER(rdbname) USRID(userid) PASSWORD(password)

USRPRF パラメーターは、クライアント・ジョブが実行されるユーザー・プロファイルを指定します。通常、SERVER パラメーターには、RDB DDM ファイルによる接続または DRDA 接続のために接続する RDB または QDDMDRDASERVER の名前を指定します。ただし、RDB ディレクトリーを使用するように作成されていない非 RDB DDM ファイルを使用する場合は、SERVER パラメーターに QDDMDRDASERVER または QDDMSERVER を指定する必要があります。SERVER パラメーターに指定する値は、大文字でなければなりません。USRID パラメーターは、サーバー・ジョブが実行されるユーザー・プロファイルを指定します。 PASSWORD パラメーターは、ユーザー・プロファイルのパスワードを指定します。

USRPRF パラメーターを省略すると、ADDSVRAUTE コマンドの実行に使用されたユーザー・プロファイルがデフォルトで使用されます。USRID パラメーターを省略すると、USRPRF パラメーターの値がデフォルト値として使われます。 PASSWORD パラメーターを省略したり、QRETSVRSEC 値を 0 に設定すると、項目にパスワードは保管されません。そして、その項目を使用した接続が試みられると、試行されるセキュリティー機構はユーザー ID だけになります。

サーバー認証リストにどの認証項目が追加されているかは、サーバー認証項目の表示 (DSPSVRAUTE) コマンドを使用して確認できます。ユーザー作成プログラムのサーバー認証項目の取得 (QsyRetrieveServerEntries) (QSYRTVSE) API も使用できます。

サーバー認証項目は、サーバー権限項目の除去 (RMVSVRAUTE) コマンドを使用して除去できます。サーバー認証項目は、サーバー権限項目の変更 (CHGSVRAUTE) コマンドを使用して変更できます。

リレーショナル・データベース (RDB) でサーバー認証項目が存在していて、接続要求でユーザー ID とパスワードが渡される場合には、渡されるユーザー ID とパスワードがサーバーの認証項目より優先されます。

DRDA および DDM によってサポートされている、特殊サーバー認証項目 ADDSVRAUTE コマンドの、2 つの SERVER パラメーター値は以下のとおりです。

ADDSVRAUTE コマンドの SERVER パラメーターの QDDMDRDASERVER 特殊値を DDM 接続および DRDA 接続に使用すると、管理者は、TCP/IP ネットワーク上のすべてのシステムに対して可能なすべての DDM 接続または DRDA 接続を、共通のユーザー ID とパスワードを介してユーザーが操作できるように構成できます。この特殊値を特定のユーザーに構成すると、リレーショナル・データベース・ディレクトリーにシステムが追加されても、そのユーザーに対する追加の変更は必要ありません。ただし、以前と同様に、ユーザーがサーバー認証項目または CONNECT ステートメントに有効なユーザー ID とパスワードを指定しない限り、そのユーザーは DRDA/DDM を使用して接続することはできません。この特殊値は、QDDMSERVER と同じサポートをすべて提供するほか、RDB DDM ファイルによる接続と DRDA 接続もサポートします。

ADDSVRAUTE コマンドの SERVER パラメーターの QDDMSERVER 特殊値を非 RDB DDM 接続に使用すると、管理者は、TCP/IP ネットワーク上のすべてのシステムに対して可能なすべての非 RDB DDM 接続を、共通のユーザー ID とパスワードを介してユーザーが操作できるように構成できます。この特殊値を特定のユーザーに構成すると、新しい非 RDB DDM ファイルが作成されて使用されても、そのユーザーに対する追加の変更は必要ありません。QDDMSERVER の使用の欠点は、この値は、DDM ファイルを使用した接続や DRDA 接続をサポートしないことです。 DDM ファイル、RDB DDM ファイル、および DRDA 接続で、コマンド・ユーザーのユーザー ID とパスワードを必要とするサーバー認証項目を利用する場合は、QDDMDRDASERVER を使用することを推奨します。

ユーザー ID とパスワードを指定せずに TCP/IP 経由で DRDA 接続を試行すると、DB2® for i クライアント (AR) は、クライアント・ジョブが実行されているユーザー・プロファイルのサーバー認証リストを検査します。CONNECT ステートメントの RDB 名または QDDMDRDASERVER と認証項目の SERVER 名 (どちらも大文字でなければなりません) が一致することが分かれば、項目内の関連する USRID パラメーターが接続ユーザー ID として使用されます。PASSWORD パラメーターが項目内で保管されている場合には、そのパスワードも接続要求で送信されます。

サーバー認証項目は、DDM ファイル入出力操作のために、TCP/IP 経由でパスワードを送信するときにも使用できます。TCP/IP 上で DDM 接続を試みる際には、DB2 for i は、クライアント・ジョブが実行されているところのユーザー・プロファイルを調べるために、サーバー認証リストを検査します。RDB 名 (RDB DDM ファイルが使用された場合) または QDDMSERVER (非 RDB DDM が使用された場合) のいずれかと、認証項目の SERVER 名が一致することが検出された場合、項目内の関連する USRID パラメーターが接続ユーザー ID として使用されます。PASSWORD パラメーターが項目内で保管されている場合には、そのパスワードも接続要求で送信されます。

DRDA 接続要求の場合、システム名を指定するサーバー認証項目が存在しており、CONNECT ステートメントでユーザー ID とパスワードが渡されていない場合は、サーバー認証項目に関連付けられたユーザー ID とパスワードが、QDDMDRDASERVER のサーバー認証項目よりも優先されます。

DRDA 接続要求の場合、システム名を指定するサーバー認証項目が存在しており、CONNECT ステートメントでユーザー ID とパスワードが渡されている場合は、CONNECT ステートメントに関連付けられたユーザー ID とパスワードが、いずれのサーバー認証項目よりも優先されます。

RDB DDM ファイル接続要求の場合、システム名を指定するサーバー認証項目が、QDDMDRDASERVER のサーバー認証項目よりも優先されます。

非 RDB DDM ファイル接続要求の場合、サーバー認証項目 QDDMSERVER が、QDDMDRDASERVER のサーバー認証項目よりも優先されます。

例 1: DRDA 接続に QDDMDRDASERVER を使用する

環境: 3 つのシステム (SYSA、SYSB、SYSC)

SYSA はアプリケーション・リクエスター (AR) です。SYSB と SYSC は、アプリケーション・サーバー (AS) です。

SYSA で、以下を指定します。

ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
STRSQL
CONNECT TO SYSB
CONNECT TO SYSC

この時点では、サーバー認証項目の特殊値 QDDMDRDASERVER で指定したユーザー ID「youruid」とパスワード「yourpwd」を使用した、2 つの DRDA 接続が確立されます。

例 2: DRDA 接続に QDDMDRDASERVER ではなくシステム名を使用する

環境: 3 つのシステム (SYSA、SYSB、SYSC)

SYSA はアプリケーション・リクエスター (AR) です。SYSB と SYSC は、アプリケーション・サーバー (AS) です。

SYSA で、以下を指定します。

ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSB) USRID(yourotheruid) PASSWORD(yourotherpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSC) USRID(yourotheruid) PASSWORD(yourotherpwd)
STRSQL
CONNECT TO SYSB
CONNECT TO SYSC

この時点では、ユーザー ID 「yourotheruid」とパスワード「yourotherpwd」を使用した 2 つの DRDA 接続が確立されます。これは、システム名を指定するサーバー認証項目が、QDDMDRDASERVER を指定するサーバー認証項目よりも優先されるためです。

例 3: DRDA 接続にシステム名と QDDMDRDASERVER を混用する

環境: 3 つのシステム (SYSA、SYSB、SYSC)

SYSA はアプリケーション・リクエスター (AR) です。SYSB と SYSC は、アプリケーション・サーバー (AS) です。

SYSA で、以下を指定します。

ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSB) USRID(yourotheruid) PASSWORD(yourotherpwd)
STRSQL
CONNECT TO SYSB user testuserid using 'testpassword'
CONNECT TO SYSC

この時点では、2 つの DRDA 接続が確立されます。SYSB への接続は、ユーザー ID「testuserid」とパスワード「testpassword」を使用して行われます。これは、CONNECT ステートメントに指定したユーザー ID とパスワードが、サーバー認証項目よりも優先されるためです。SYSC への接続には、システム名を指定するサーバー認証項目が他に存在しない場合に、QDDMDRDASERVER 認証項目が使用されるため、SYSC への接続は、ユーザー ID「youruid」とパスワード「yourpwd」を使用して行われます。

例 4: RDB DDM 接続と非 RDB DDM 接続に QDDMDRDASERVER と QDDMSERVER を混用する

環境: 3 つのシステム (SYSA、SYSB、SYSC)

SYSA はアプリケーション・リクエスター (AR) です。SYSB と SYSC は、アプリケーション・サーバー (AS) です。

SYSA で、以下を指定します。

ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMDRDASERVER) USRID(youruid) PASSWORD(yourpwd)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(QDDMSERVER) USRID(youruid2) PASSWORD(yourpwd2)
ADDSVRAUTE USRPRF(YOURPRF) SERVER(SYSC) USRID(yourotheruid) PASSWORD(yourotherpwd)
CRTDDMF FILE(QTEMP/DDMF) RMTFILE(FILE) RMTLOCNAME(SYSB *IP)
CRTDDMF FILE(QTEMP/DDMF2) RMTFILE(FILE) RMTLOCNAME(*RDB) RDB(SYSB)
CRTDDMF FILE(QTEMP/DDMF3) RMTFILE(FILE) RMTLOCNAME(*RDB) RDB(SYSC)

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF)

SYSB への接続は、ユーザー ID「youruid2」とパスワード「yourpwd2」を使用して行われます。これは、非 RDB DDM ファイルが、接続時にユーザー ID とパスワードに QDDMSERVER を使用するためです。QDDMSERVER が存在しない場合は、QDDMDRDASERVER が使用されます。

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF2)

SYSB への接続は、ユーザー ID 「youruid」とパスワード「yourpwd」を使用して行われます。これは、システム名を指定するサーバー認証項目が存在しない場合に、RDB DDM ファイルが接続時にユーザー ID とパスワードに QDDMDRDASERVER を使用するためです。

SBMRMTCMD CMD('DSPLIB YOURLIB') DDMFILE(QTEMP/DDMF3)

SYSC への接続は、ユーザー ID「yourotheruid」とパスワード「yourotherpwd」を使用して行われます。これは、システム名を指定するサーバー認証項目が存在する場合に、RDB DDM ファイルが接続時にユーザー ID とパスワードに QDDMDRDASERVER を使用しないためです。

グループ・プロファイルを使用した、簡素化された DDM および DRDA のサーバー認証項目管理

DDM と DRDA では、グループ・プロファイル名または補足グループ・プロファイル名でサーバー認証項目に定義されている共通のユーザー ID とパスワードを利用することができるようになりました。グループ・プロファイル名または補足グループ・プロファイル名は、サーバー認証項目追加 (ADDSVRAUTE) コマンドの USRPRF パラメーターで指定します。この機能強化の前では、ユーザー ID とパスワードの認証を必要とするアプリケーション・サーバーへのアクセスにサーバー認証項目を使用する場合に、アクセスを必要とするシステム上のすべてのユーザーに対してサーバー認証項目が必要でした。

サーバー認証項目のシステム管理は、グループ・プロファイルを使用することで、ずっとシンプルになります。グループ・プロファイル・ベースの DDM または DRDA 接続を確立するときは、共通のユーザー ID とパスワードのプロファイルを使用します。リモート接続の機能は、同じグループに属するユーザーを、それらのユーザーのグループ・プロファイルの権限を使用して制御することで管理されます。

例:

CRTUSRPRF USRPRF(TESTTEAM) PASSWORD(*NONE)
CRTUSRPRF USRPRF(JIM) PASSWORD(yourpasswordA) GRPPRF(TESTTEAM)
ADDSVRAUTE USRPRF(TESTTEAM) SERVER(QDDMDRDASERVER or <RDB-name of system-B>) USRID(youruseridB) PASSWORD(yourpasswordB)

Signon to <system-A> with Jim's user profile
STRSQL
CONNECT TO <system-B>
(where <system-B> is a RDB entry defined in the Work with Relational Database Directory Entries (WRKRDBDIRE) command.)

A connection is attempted to <system-B> with userid = youruseridB and password = yourpasswordB.

注: 以下の順序または進行が示すように、グループ・メンバーのサーバー認証項目は、グループ・プロファイルのサーバー認証項目より優先されます。DDM および DRDA サーバー認証項目の検査の進行は、以下の順序で実行されます。接続は、最初に一致した認証項目の設定を使用して試行されます。

USRPRF = ユーザー・プロファイル、SERVER = アプリケーション・サーバー名の認証項目を検索します。
USRPRF = ユーザー・プロファイル、SERVER =「QDDMDRDASERVER」の認証項目を検索します。
USRPRF = グループ・プロファイル、SERVER = アプリケーション・サーバー名の認証項目を検索します。
USRPRF = グループ・プロファイル、SERVER =「QDDMDRDASERVER」の認証項目を検索します。
USRPRF = 補足グループ・プロファイル、SERVER = アプリケーション・サーバー名の認証項目を検索します。
USRPRF = 補足グループ・プロファイル、SERVER =「QDDMDRDASERVER」の認証項目を検索します。
上記のすべてのステップで項目が見つからなかった場合は、USERID のみの認証が試行されます。

グループ・プロファイル認証項目を使用する際の DRDA 明示的サーバー名の優先順位

デフォルトにより、グループ・メンバーが QDDMDRDASERVER 特殊サーバー認証項目を使用している場合、そのグループ・メンバーは、DRDA/DDM を使用して接続する際、アプリケーション・サーバー名を明示的に指定する、グループまたは補足グループのサーバー認証項目を使用しません。この理由は、グループ・メンバーの QDDMDRDASERVER には、グループまたは補足グループでの、明示的に指定されたサーバー認証項目より高い優先順位が与えられるためです。環境変数 QIBM_DDMDRDA_SVRNAM_PRIORITY が追加されています。この環境変数により、アプリケーション・サーバー名を明示的に指定する、グループまたは補足グループのサーバー認証項目には、DDM/DRDA 接続を試行している際に QDDMDRDASERVER 特殊サーバー認証項目をグループ・メンバー、グループ、または補足グループのプロファイルで使用した場合より高い優先順位が与えられます。この環境変数を使用するメリットは、グループ・メンバーが QDDMDRDASERVER を指定した場合に、アプリケーション・サーバー名を明示的に指定する、グループまたは補足グループのサーバー認証項目をまだ使用できることです。

システム・レベルで明示的サーバー名の優先順位を有効にするには、以下のようにします。
```
ADDENVVAR ENVVAR(QIBM_DDMDRDA_SVRNAM_PRIORITY) VALUE('Y') LEVEL(*SYS)
```
変更を有効にするには、ジョブを再始動する必要がある可能性があります。
ジョブ・レベルで明示的サーバー名の優先順位を有効にするには、以下のようにします。
```
ADDENVVAR ENVVAR(QIBM_DDMDRDA_SVRNAM_PRIORITY) VALUE('Y') LEVEL(*JOB)
```

例:

ADDENVVAR ENVVAR(QIBM_DDMDRDA_SVRNAM_PRIORITY) VALUE('Y') LEVEL(*JOB)
CRTUSRPRF USRPRF(TESTTEAM) PASSWORD(*NONE)
CRTUSRPRF USRPRF(JIM) PASSWORD(yourpasswordA) GRPPRF(TESTTEAM)
ADDSVRAUTE USRPRF(JIM) SERVER(QDDMDRDASERVER) USRID(youruseridA) PASSWORD(yourpasswordA)
ADDSVRAUTE USRPRF(TESTTEAM) SERVER(<RDB-name for system-B>) USRID(youruseridB) PASSWORD(yourpasswordB)

Signon to <system-A> with Jim's user profile
STRSQL
CONNECT TO <system-B>
(where <system-B> is a RDB entry defined in the Work with Relational Database Directory Entries (WRKRDBDIRE) command.)

A connection is attempted to <system-B> with userid = youruseridB and password = yourpasswordB.
A connection made to any other system will use userid = youruseridA and password = yourpasswordA.

注: 以下の順序または進行が示すように、グループ・メンバーのサーバー認証項目は、グループ・プロファイルのサーバー認証項目より優先されます。DDM および DRDA のサーバー認証項目検査の進行は、環境変数が設定された時に以下の順序で行われます。接続は、最初に一致した認証項目の設定を使用して試行されます。

USRPRF = ユーザー・プロファイル、SERVER = アプリケーション・サーバー名の認証項目を検索します。
USRPRF = グループ・プロファイル、SERVER = アプリケーション・サーバー名の認証項目を検索します。
USRPRF = 補足グループ・プロファイル、SERVER = アプリケーション・サーバー名の認証項目を検索します。
USRPRF = ユーザー・プロファイル、SERVER =「QDDMDRDASERVER」の認証項目を検索します。
USRPRF = グループ・プロファイル、SERVER =「QDDMDRDASERVER」の認証項目を検索します。
USRPRF = 補足グループ・プロファイル、SERVER =「QDDMDRDASERVER」の認証項目を検索します。
上記のすべてのステップで項目が見つからなかった場合は、USERID のみの認証が試行されます。

ユーザー・プロファイルのパスワードの使用による DRDA および DDM 認証の有効化

この機能拡張は、正式には DRDA/DDM 結合相互認証と呼ばれ、IBM® i から IBM i への接続でのみサポートされ、環境変数 QIBM_CONJOINED_MUT_AUTH を使用して有効化されます。

この機能拡張の前は、Distributed Relational Database Architecture™ (DRDA) または分散データ管理 (DDM) 接続を試行するユーザーは、アプリケーション・サーバーがパスワードを必要とするよう構成されている場合には、SQL CONNECT ステートメント上でパスワードを指定するか、パスワードを含むサーバー認証項目を指定する必要がありました。これにより、ユーザーまたはシステム管理者は、すべてのターゲット・システムのサーバー認証項目を管理するために時間を費やしたり、リモートで接続するときに CONNECT 時間にパスワードを指定したりする必要がありました。SQL CONNECT ステートメント、またはアプリケーション・サーバーのサーバー認証項目にパスワードを指定しない場合、パスワードを必要とするアプリケーション・サーバーへの DRDA/DDM 接続は失敗しました。

この機能拡張を使用すると、アプリケーション・サーバーに対する IBM i から IBM i DRDA への接続または DDM 接続は、現在サインイン済みのユーザー・プロファイルのユーザー ID とパスワードを使用して試行されます。この接続は、環境変数の値が Y に設定されており、パスワードを必要とするよう構成されたアプリケーション・サーバーに対して、SQL CONNECT ステートメントまたはサーバー認証項目でユーザー ID とパスワードを明示的に指定していない場合のみ試行されます。

この機能拡張は、複数のシステム間で同じ組み合わせのユーザー ID とパスワードを使用しているネットワークで有益です。この機能拡張を使用すると、3 部構成の接続にサーバー認証項目を指定する必要はありません。

要件:

アプリケーション・リクエスターとアプリケーション・サーバーは、いずれも v7r2m0 の IBM i でないとサポートされません。この機能拡張は、アプリケーション・リクエスターのジョブが環境変数 QIBM_CONJOINED_MUT_AUTH を追加し、'Y' の値を指定すると有効になります (環境変数を追加するには、環境変数追加 (ADDENVVAR) コマンドを参照してください)。アプリケーション・サーバーは、パスワードを要求するように設定する必要があります (DDM TCP/IP 属性の変更 (CHGDDMTCPA) コマンドの PWDRQD キーワードを参照してください)。いずれのシステムも、接続するには、それぞれのために同じユーザー ID とパスワードが定義されている必要があります。また、いずれのシステムも、システム値 QPWDLVL に同じパスワード・レベルが指定されている必要があります。ユーザーは、パスワードを必要とするよう構成されたアプリケーション・サーバーに対して、SQL CONNECT ステートメントまたはサーバー認証項目にユーザー ID とパスワードを明示的に指定してはなりません。

システム・レベルで結合相互認証を有効にするには、以下のようにします。
```
ADDENVVAR ENVVAR(QIBM_CONJOINED_MUT_AUTH) VALUE('Y') LEVEL(*SYS)
```
変更を有効にするには、ジョブを再始動する必要がある可能性があります。
ジョブ・レベルで結合相互認証を有効にするには、以下のようにします。
```
ADDENVVAR ENVVAR(QIBM_CONJOINED_MUT_AUTH) VALUE('Y') LEVEL(*JOB)
```

注: アプリケーション・リクエスターによってパスワードまたはサーバー認証項目が指定されておらず、サポートが有効な IBM i から IBM i の DRDA または DDM 接続の場合は、接続にパスワードを必要とするアプリケーション・サーバーに対して追加の接続が試行されます。この追加の接続は、暗号化ユーザー ID およびパスワード・セキュリティー・メカニズム (ユーザー ID は接続を行っているユーザー・プロファイルから取得され、パスワードはそのユーザー・プロファイルから取得される) を使用して試行されます。パスワードが一致すると判断されたら、接続は通常どおり許可されます。パスワードが一致しない場合は、セキュリティーの障害があるか上記の要件が満たされておらず、CPF22E2 メッセージがシグナル通知され、PW 監査レコードが書き込まれます。この無効な接続の試行は、ユーザー・プロファイルの 1 回の無効なサインオンの試行としてカウントされます。

監査が有効で、監査レベルが許可の失敗を記録するように構成されている場合は、セキュリティー監査レコードが QSYS/QAUDJRN セキュリティー監査実行記録に書き込まれます。PW 監査レコードは、ユーザー ID とパスワードが接続に失敗した場合に表示されます。

Kerberos ソース構成

分散リレーショナル・データベース体系 (DRDA) と分散データ管理 (DDM) では、それぞれのシステムで Kerberos が構成されている場合は、Kerberos 認証を利用できます。

ジョブのユーザー・プロファイルに有効なチケット許可チケット (TGT) がある場合、 DRDA クライアントはこの TGT を使用して、サービス・チケットを生成し、ユーザーをリモート・システムに認証します。有効な TGT を使用すると、パスワードを直接入力する必要はなくなるため、サーバー認証項目を行う必要性はなくなります。しかし、ジョブのユーザー・プロファイルに有効な TGT がない場合、サーバー認証項目からユーザー ID とパスワードを取り出して、必要な TGT およびサービス・チケットを生成できます。

Kerberos を使用する場合、リモート・ホスト名として、 RDB ディレクトリー項目のリモート・ロケーション (RMTLOCNAME) を入力する必要があります。 Kerberos 認証では、IP アドレスは役立ちません。

Kerberos レルム名が DNS 接尾部名と異なる場合には、正確なレルムにマップする必要があります。これを行うには、Kerberos 構成ファイル (krb5.conf) 内に、各リモート・ホスト名を正しいレルム名にマップする項目がなければなりません。この入力されるホスト名は、リモート・ロケーション名 (RMTLOCNAME) と正確に一致している必要があります。リレーショナル・データベースのディレクトリー項目の表示 (DSPRDBDIRE) コマンドまたは DDM ファイル表示 (DSPDDMF) コマンドによって表示されるリモート・ロケーション・パラメーターは、krb5.conf ファイル内のドメイン名と一致している必要があります。以下の図は、リレーショナル・データベースのディレクトリー項目の表示 (DSPRDBDIRE) コマンドの例を示しています。

                      リレーショナル・データベース項目の詳細の表示

リレーショナル・データベース  . . . . . . :   RCHASXXX             
リモート・ロケーション:
  リモート・ロケーション  . . . . . . . . :   rchasxxx.rchland.ibm.com
    タイプ  . . . . . . . . . . . . . . . :   *IP                  
  ポート番号またはサービス名  . . . . . . :   *DRDA                
  リモート認証方式 :
    所望の方式 . . . . . . . . . . . . .  :   *KERBEROS            
    より低い認証の許可  . . . . . . . . . :   *NOALWLOWER          
  保護接続      . . . . . . . . . . . . . :   *NONE                
  暗号化アルゴリズム      . . . . . . . . :   *DES                 
テキスト  . . . . . . . . . . . . . . . . :                        
                                                          
                                                          
リレーショナル・データベース・タイプ. . . :   *REMOTE
                                                                                              
                                                                                              
                                                                                              
                                                                                              
  続行するには、実行キーを押してください。
   F3= 終了   F12= 取り消し

次に示すのは、対応する krb5.conf ファイルの内容の一部分です。ここには、リモート・ロケーション名と一致するドメイン名が示されています (注: 構成ファイルの内容を表示するために、ファイルの表示 (DSPF) コマンドが使用されています)。

DSPF STMF('/QIBM/UserData/OS400/NetworkAuthentication/krb5.conf')

[domain_realm]
; Convert host names to realm names. Individual host names may be
; specified. Domain suffixes may be specified with a leading period
; and will apply to all host names ending in that suffix.
 rchasxxx.rchland.ibm.com = REALM.RCHLAND.IBM.COM

Kerberos を使用するジョブは、krb5.conf ファイルに対して構成の変更が行われる場合に、再始動する必要があります。