NTドメインが、何と何を管理するものなのか、いまだによくわかっていないのですが、このあいだ、ユーザー名と、パスワードを集中して管理している、ということが、少しわかってきました。
さらにもう一つ、コンピュータアカウントも管理していたことがちょっぴり、理解しかかったところです。今頃になってこんなことを書いている人も時代遅れですよね。。。
先日、社内で検証用に構築したNT4.0Serverにユーザーを作成して、WindowsXPや、Windows2000のコンピュータから、そのユーザーでドメインに参加する作業を、試していました。（やっていたのは、私ではありません）
XPや、2000のコンピュータから、ドメインに参加しようとすると（システムのプロパティ－ネットワークID－プロパティから）「ドメインに参加するアクセス許可を与えられたアカウントのユーザー名とパスワードを入力してください」と、聞かれます。
ここで、たとえば今作成したユーザー名とパスワードを入れて、少し待つと「サーバーのセキュリティ データベースにこのワークステーションの信頼関係に対するコンピュータアカウントがありません。」と出て、ドメインに参加できませんでした。
あれれ、どうして？
NTドメインに、参加するには
・あらかじめ使用するコンピュータアカウントを、サーバーに登録しておく または
・ユーザー名とパスワードを聞かれたときに、『コンピュータアカウントを作成する権限を持っている』ユーザー名を入力する
の、どちらかが必要なのだそうです。
NTドメインには、ユーザー名、パスワード、コンピュータアカウントがすべて登録された人しか参加できません。つまり、NTドメインでは、ユーザー、パスワード、コンピュータアカウントを管理している…。そうだったんだ。。今頃になっての発見です。
Windows9Xマシンについては、こういう説明になっています。
『Windows 9x／MeなどのOSは、ドメインに参加できないのでアカウントは作成されない。ただしこれらのOSでも、ユーザー名とパスワードをドメインのIDと一致させることで、ドメインの共有資源を使うことはできる』
ユーザー名と、パスワードを一致させれば、共有資源を使うことはできる。だけど、ログインしても、コンピュータアカウントは作成されない。。
そっかあ。Win9Xは、ドメインに参加していたわけではなかったんだ…。
今ままで、このことを意識したことがなかったのは、社内では自分たちはAdministratorグループにいるため、コンピュータアカウントを作成する権限を持っていたからのようです。
検証サーバを作っても、クライアントから接続する検証は、どうやら、やっていなかったのかもしれません。
ではここで、今ままで、よくわからなくて勉強していなかったドメインモデルを、少しだけ、見てみます。
シングル・ドメイン・モデルしか、知らないのであまり信頼関係とかを意識しないで、勉強しようともせずに過ごしていました。
【シングル・ドメイン・モデル】
ユーザー、グループ、コンピュータを1つのドメインで管理するドメイン・モデル。
同じデータベースでドメインのすべてのアカウントを管理することができるシンプルなモデル。
1つのドメインだけ管理すればよいため、集中管理が行える。
【シングル・マスター・ドメイン・モデル】
ユーザーやグループを1つのドメインにまとめ、全従業員を集中管理し、コンピュータ・アカウントをそれぞれの拠点ドメインでまとめ管理するモデル。
ユーザーやグループのドメインをアカウント・ドメインと呼び、コンピュータのドメインをリソース・ドメインと呼ぶ。
ユーザーがコンピュータを使用するためには、リソース・ドメインはアカウント・ドメインを信頼しなければならない。
【マルチ・マスター・ドメイン・モデル】
ユーザーやグループを1つのドメインにまとめきれない場合や、
管理範囲が分散されているような場合において、アカウント・ドメインを複数用意したモデル。
すべてのユーザーがすべてのコンピュータを利用できるようにするためには、それぞれのリソース・ドメインはそれぞれのアカウント・ドメインを信頼する必要がある。
そのため、シングル・マスター・ドメイン・モデルと比較すると、信頼関係の設定が多くなる。
【完全信頼ドメイン・モデル】
それぞれのドメインにおいて、ユーザーやグループ・アカウントもコンピュータも管理し、さらに、お互いにリソースを共有できるように、それぞれで双方向に信頼関係を結ぶモデル。
拠点や、部門単位で管理が分散するような場合にこのようなモデルになる。
各ドメインが相互に信頼関係を結ぶので、ドメインの数が増えれば増えるほど、信頼関係も複雑化してしまう。
★何年も前から、眺めている図ですが、やっと少し図の意味がわかってきた気がします。
↓参考
http://www.atmarkit.co.jp/fwin2k/operation/admigrate01/admigrate01_01.html
さらにもう一つ、コンピュータアカウントも管理していたことがちょっぴり、理解しかかったところです。今頃になってこんなことを書いている人も時代遅れですよね。。。
先日、社内で検証用に構築したNT4.0Serverにユーザーを作成して、WindowsXPや、Windows2000のコンピュータから、そのユーザーでドメインに参加する作業を、試していました。（やっていたのは、私ではありません）
XPや、2000のコンピュータから、ドメインに参加しようとすると（システムのプロパティ－ネットワークID－プロパティから）「ドメインに参加するアクセス許可を与えられたアカウントのユーザー名とパスワードを入力してください」と、聞かれます。
ここで、たとえば今作成したユーザー名とパスワードを入れて、少し待つと「サーバーのセキュリティ データベースにこのワークステーションの信頼関係に対するコンピュータアカウントがありません。」と出て、ドメインに参加できませんでした。
あれれ、どうして？
NTドメインに、参加するには
・あらかじめ使用するコンピュータアカウントを、サーバーに登録しておく または
・ユーザー名とパスワードを聞かれたときに、『コンピュータアカウントを作成する権限を持っている』ユーザー名を入力する
の、どちらかが必要なのだそうです。
NTドメインには、ユーザー名、パスワード、コンピュータアカウントがすべて登録された人しか参加できません。つまり、NTドメインでは、ユーザー、パスワード、コンピュータアカウントを管理している…。そうだったんだ。。今頃になっての発見です。
Windows9Xマシンについては、こういう説明になっています。
『Windows 9x／MeなどのOSは、ドメインに参加できないのでアカウントは作成されない。ただしこれらのOSでも、ユーザー名とパスワードをドメインのIDと一致させることで、ドメインの共有資源を使うことはできる』
ユーザー名と、パスワードを一致させれば、共有資源を使うことはできる。だけど、ログインしても、コンピュータアカウントは作成されない。。
そっかあ。Win9Xは、ドメインに参加していたわけではなかったんだ…。
今ままで、このことを意識したことがなかったのは、社内では自分たちはAdministratorグループにいるため、コンピュータアカウントを作成する権限を持っていたからのようです。
検証サーバを作っても、クライアントから接続する検証は、どうやら、やっていなかったのかもしれません。
ではここで、今ままで、よくわからなくて勉強していなかったドメインモデルを、少しだけ、見てみます。
シングル・ドメイン・モデルしか、知らないのであまり信頼関係とかを意識しないで、勉強しようともせずに過ごしていました。
【シングル・ドメイン・モデル】
ユーザー、グループ、コンピュータを1つのドメインで管理するドメイン・モデル。
同じデータベースでドメインのすべてのアカウントを管理することができるシンプルなモデル。
1つのドメインだけ管理すればよいため、集中管理が行える。
【シングル・マスター・ドメイン・モデル】
ユーザーやグループを1つのドメインにまとめ、全従業員を集中管理し、コンピュータ・アカウントをそれぞれの拠点ドメインでまとめ管理するモデル。
ユーザーやグループのドメインをアカウント・ドメインと呼び、コンピュータのドメインをリソース・ドメインと呼ぶ。
ユーザーがコンピュータを使用するためには、リソース・ドメインはアカウント・ドメインを信頼しなければならない。
【マルチ・マスター・ドメイン・モデル】
ユーザーやグループを1つのドメインにまとめきれない場合や、
管理範囲が分散されているような場合において、アカウント・ドメインを複数用意したモデル。
すべてのユーザーがすべてのコンピュータを利用できるようにするためには、それぞれのリソース・ドメインはそれぞれのアカウント・ドメインを信頼する必要がある。
そのため、シングル・マスター・ドメイン・モデルと比較すると、信頼関係の設定が多くなる。
【完全信頼ドメイン・モデル】
それぞれのドメインにおいて、ユーザーやグループ・アカウントもコンピュータも管理し、さらに、お互いにリソースを共有できるように、それぞれで双方向に信頼関係を結ぶモデル。
拠点や、部門単位で管理が分散するような場合にこのようなモデルになる。
各ドメインが相互に信頼関係を結ぶので、ドメインの数が増えれば増えるほど、信頼関係も複雑化してしまう。
★何年も前から、眺めている図ですが、やっと少し図の意味がわかってきた気がします。
↓参考
http://www.atmarkit.co.jp/fwin2k/operation/admigrate01/admigrate01_01.html