Windows NT ユーザーの場合、オペレーティング・システムの認証の方法が原因で、 ユーザーの認証に問題の生じることがあります。 この節では、 DB2 (Windows NT 版) でのユーザー認証に関する考慮事項について取り上げます。
Windows NT 環境では、次のような制約があります。
DB2 ユニバーサル・データベースでは、 ユーザー名とパスワードの認証が DB2 システム・コントローラーに統合されています。 機密保護サービスが必要になるのは、 認証 CLIENT 用に構成されたサーバーにクライアントが接続するときだけです。
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 ユニバーサル・データベースは、 ユーザー・アカウントがどこで見つかったかに関係なく、確実に、 DB2 がインストールされているローカルの Windows NT サーバーでグループが列挙されるようにオーバーライドを行います。 このオーバーライドを実現するには、 以下のコマンドを使用します。
db2set -g DB2_GROUP_LOOKUP=local
db2set -i DB2_GROUP_LOOKUP=local
設定されているすべての DB2 プロファイル変数を表示するには、 次のように入力します。
db2set -all
DB2 (Windows NT 版) でドメイン機密保護を有効にするためには、 権限と特権をローカル・グループに授与する必要があります。 ローカル・グループ内のユーザー名とグローバル・グループ内のユーザー名は、 ローカル・グループまたはグローバル・グループと同じドメインで定義しないと正常に認証を行えません。
DB2_GRP_LOOKUP プロファイル・レジストリー変数がローカルに設定されている場合、 DB2 はローカル・マシンでしかユーザーを探そうとしません。 そのユーザーがローカル・マシンで見つからなかった場合や、 そのユーザーがローカルまたはグローバル・グループのメンバーとして定義されていない場合、 認証は失敗します。 DB2 は、 同じドメインの他のマシンやドメイン・コントローラーからユーザーを探そうとはしません。
DB2_GRP_LOOKUP プロファイル・レジストリー変数が設定されていない場合、 以下のことが行われます。
以下の例は、 DB2 (Windows NT 版) がドメイン機密保護をどのようにサポートするかを示しています。 最初の例では、 ユーザー名とローカル・グループが同じドメイン上にあるため、接続は機能します。 2 番目の例では、 ユーザー名とローカルまたはグローバル・グループが異なるドメイン上にあるため、 接続は機能しません。
接続が成功する例: 以下のシナリオでは、ユーザー名とローカルまたはグローバル・グループが同じドメイン上にあるため、 接続は機能します。
必ずしもユーザー名とローカルまたはグローバル・グループを、
データベース・サーバーが実行されているドメインに定義する必要はありません。しかし、
ユーザー名とローカルまたはグローバル・グループを同じドメインに定義する必要はあります。
表 96. ドメイン・コントローラーによって接続が正常に確立される例
Domain1 | Domain2 |
---|---|
Domain2 との間に信頼関係が存在している。 |
|
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\grp1 が grp2 のメンバーとなっている。 | |
DB2 サーバーがこのドメインで実行されている。
以下の DB2 コマンドがこのサーバーから発行される。
REVOKE CONNECT ON db FROM public GRANT CONNECT ON db TO GROUP grp2 CONNECT TO db USER id2 | |
ローカルまたはグローバルがスキャンされ、id1 が見つかる。 DB2 は、このユーザー名についての情報 (つまり、 ユーザー名 id1 が grp1 のメンバーであり、 グループ grp1 は Domain2\grp2 のメンバーであるということ) を入手する。 | |
グループ grp2 がこのドメインに存在している。 | |
ローカルまたはグローバル・グループは Domain2 に存在しているが、
実際のユーザー名は Domain1 で定義されているため、接続は機能しない。
GRANT CONNECT ON db TO GROUP grp1 コマンドが発行されていれば、 接続は機能するはずである。 |