管理の手引き


DB2 (Windows NT 版) での DB2 ユーザー認証

Windows NT ユーザーの場合、オペレーティング・システムの認証の方法が原因で、 ユーザーの認証に問題の生じることがあります。 この節では、 DB2 (Windows NT 版) でのユーザー認証に関する考慮事項について取り上げます。

ユーザー名とグループ名の制約

Windows NT 環境では、次のような制約があります。

DB2 (Windows NT 版) 機密保護サービス

DB2 ユニバーサル・データベースでは、 ユーザー名とパスワードの認証が DB2 システム・コントローラーに統合されています。 機密保護サービスが必要になるのは、 認証 CLIENT 用に構成されたサーバーにクライアントが接続するときだけです。

DB2 のバックアップ・ドメイン・コントローラーへのインストール

Windows NT 環境では、 ユーザーの認証をプライマリー・コントローラーとバックアップ・コントローラーのどちらでも行えます。 この機能は、 どのサイトにも 1 つの中央プライマリー・ドメイン・コントローラー (PDC) と、 1 つまたは複数のバックアップ・ドメイン・コントローラー (BDC) とが配置されているような大規模な分散 LAN では非常に重要です。 ユーザーは認証のためにプライマリー・ドメイン・コントローラーを呼び出さなくても、 現在のサイトにあるバックアップ・ドメイン・コントローラーで認証を行えます。

この場合、バックアップ・ドメイン・コントローラーを設けることの利点は、 ユーザーの認証を短時間で行えることと、 BDC がない場合よりも LAN が混雑しないで済むということです。

以下の条件にあてはまる場合、認証は BDC で行うことができます。

DB2DMNBCKCTLR プロファイル・レジストリー変数が設定されていない場合、 あるいはブランクに設定されている場合、 DB2 (Windows NT 版) は認証をプライマリー・ドメイン・コントローラーで実行します。

DB2DMNBCKCTLR に有効な宣言設定は"?"またはドメイン名だけです。

DB2DMNBCKCTLR プロファイル・レジストリー変数が疑問符に設定されていて (DB2DMNBCKCTLR=?)、 かつ以下の条件にあてはまる場合、 DB2 (Windows NT 版) は認証をバックアップ・ドメイン・コントローラーで実行します。

通常の状態であれば DB2DMNBCKCTLR=? 設定はたいてい正常に機能しますが、 あらゆる環境で正常に機能することが保証されているわけではありません。 ドメイン上のサーバーについて提供される情報は動的であるため、 コンピューター・ブラウザーを実行して、 この情報を常に正確かつ最新のものに保つ必要があります。 大規模な LAN ではコンピューター・ブラウザーを実行できないことがあるため、 サーバー・マネージャーの情報が最新のものではなくなる場合もあります。 この場合、 DB2 (Windows NT 版) に認証をバックアップ・ドメイン・コントローラーで実行させる別の方法があります。 それは、DB2DMNBCKCTLR=xxx を設定することです (xxx は DB2 サーバーの Windows NT ドメイン名)。 この設定がなされている場合、 以下の条件を満たしていれば、認証がバックアップ・ドメイン・コントローラーで行われます。

グループおよびドメイン機密保護を使った認証

DB2 (Windows NT 版) は、以下のタイプのグループをサポートします。

DB2 (Windows NT 版) でドメイン機密保護を有効にするためには、 権限と特権をローカル・グループに授与する必要があります。 ローカル・グループ内のユーザー名とグローバル・グループ内のユーザー名は、 ローカル・グループまたはグローバル・グループと同じドメインで定義しないと正常に認証を行えません。

DB2_GRP_LOOKUP プロファイル・レジストリー変数がローカルに設定されている場合、 DB2 はローカル・マシンでしかユーザーを探そうとしません。 そのユーザーがローカル・マシンで見つからなかった場合や、 そのユーザーがローカルまたはグローバル・グループのメンバーとして定義されていない場合、 認証は失敗します。 DB2 は、 同じドメインの他のマシンやドメイン・コントローラーからユーザーを探そうとはしません

DB2_GRP_LOOKUP プロファイル・レジストリー変数が設定されていない場合、 以下のことが行われます。

  1. DB2 は最初に同じマシンからユーザーを探そうとします。
  2. ユーザー名がローカルで定義されている場合、 そのユーザーの認証はローカルで行われます。
  3. ユーザーがローカルで見つからなかった場合、 DB2 は同じドメインからユーザー名を探そうとし、 それでも見つからない場合は、信頼されている他のドメインから探そうとします。

以下の例は、 DB2 (Windows NT 版) がドメイン機密保護をどのようにサポートするかを示しています。 最初の例では、 ユーザー名とローカル・グループが同じドメイン上にあるため、接続は機能します。 2 番目の例では、 ユーザー名とローカルまたはグローバル・グループが異なるドメイン上にあるため、 接続は機能しません。

接続が成功する例: 以下のシナリオでは、ユーザー名とローカルまたはグローバル・グループが同じドメイン上にあるため、 接続は機能します。

必ずしもユーザー名とローカルまたはグローバル・グループを、 データベース・サーバーが実行されているドメインに定義する必要はありません。しかし、 ユーザー名とローカルまたはグローバル・グループを同じドメインに定義する必要はあります。

表 96. ドメイン・コントローラーによって接続が正常に確立される例
Domain1 Domain2
Domain2 との間に信頼関係が存在している。
  • Domain1 との間に信頼関係が存在している。
  • ローカルまたはグローバル・グループ grp2 が定義されている。
  • ユーザー名 id2 が定義されている。
  • ユーザー名 id2grp2のメンバーとなっている。

DB2 サーバーがこのドメインで実行されている。 以下の DB2 コマンドがこのサーバーから発行される。

   REVOKE CONNECT ON db FROM public
   GRANT CONNECT ON db TO GROUP grp2
   CONNECT TO db USER id2
ローカルまたはグローバル・ドメインがスキャンされるが、 id2 は見つからない。 ドメイン機密保護がスキャンされる。
ユーザー名 id2 がこのドメインで見つかる。 DB2 は、このユーザー名についての追加情報 (つまり、 このユーザー名がグループ grp2 のメンバーであるということ) を入手する。
ユーザー名とローカルまたはグローバル・グループが同じドメイン上にあるため、 接続は機能する。

接続が失敗する例: 以下のシナリオでは、 ユーザー名がローカルまたはグローバル・グループとは異なるドメインで定義されているため、 接続は機能しません。

表 97. ドメイン・コントローラーによって接続が確立されない例
Domain1 Domain2
Domain2 との間に信頼関係が存在している。
  • Domain1 との間に信頼関係が存在している。
  • ローカルまたはグローバル・グループ grp2 が定義されている。

  • グローバル・グループ grp1 が定義されている。
  • ユーザー名 id1 が定義されている。
  • ユーザー名 id1grp1 のメンバーとなっている。

Domain1\grp1grp2 のメンバーとなっている。
DB2 サーバーがこのドメインで実行されている。 以下の DB2 コマンドがこのサーバーから発行される。

   REVOKE CONNECT ON db FROM public
   GRANT CONNECT ON db TO GROUP grp2
   CONNECT TO db USER id2
ローカルまたはグローバルがスキャンされ、id1 が見つかる。 DB2 は、このユーザー名についての情報 (つまり、 ユーザー名 id1grp1 のメンバーであり、 グループ grp1 は Domain2\grp2 のメンバーであるということ) を入手する。
グループ grp2 がこのドメインに存在している。
ローカルまたはグローバル・グループは Domain2 に存在しているが、 実際のユーザー名は Domain1 で定義されているため、接続は機能しない。

GRANT CONNECT ON db TO GROUP grp1 コマンドが発行されていれば、 接続は機能するはずである。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]