*

ドメインとワークグループ

公開日: : 最終更新日:2014/08/16 windows ネットワークの基礎

さて前のトラブルシュートの記事はあくまで、ワークグループ環境(一部の SBS サーバーを除く規定の状態) での共有アクセスについての記事でした。

もうすでにお分かりの方もいらっしゃると思いますが、実は Windows OS はワークグループ環境とドメイン環境という 2 つが用意されています。
では、ワークグループとドメインのそれぞれの特徴について以下に記しますので、『なんとなくドメイン環境のほうがいい』などの安易な理由で用件に組み込もうとしている管理者の方。ちょっと立ち止まってみてはいかがでしょう?

a ワークグループとは

    a-1 Windows の規定の環境でマシン名と IP アドレスさえ一意で設定できれば特に構築の必要がない

    a-2 ユーザーオブジェクトが各マシン上にて分散管理されている。(つまりユーザーログオン先としてはローカルのみ)

※補足
a-2 はどういう事かというと
例えば FS01 と FS02 というファイルサーバーがあったとして、CL01 というクライアントから FS01 FS02 にアクセスした場合を想定します。
そこで、例えば、\\FS01 とか \\FS02 という指定でサーバーに共有アクセスしたとします。

内部では CL01 から FS01 や FS02 にアクセスする際に CL01 にログオンしているローカルのユーザー名とそのパスワードが暗号化された状態でFS01 や FS02 に渡され FS01 と FS02 で認証されます。
同様のユーザー名とパスワードをもったユーザーオブジェクトが FS01 や FS02 のローカルに存在すれば認証はクリアし、次のアクセス許可の有無のチェックに移行します。
同様のユーザー名とパスワードをもったユーザーオブジェクトが FS01 や FS02 のローカルに存在しない場合、認証に失敗し、クライアントにはユーザー名とパスワードを入力させるダイアログボックス(図1)が表示されます。

そこで、サーバー上のユーザー名とパスワードを入力して、はじめて認証をクリアします。

多少脱線しましたが。。。
『ワークグループ環境でのユーザーはそのマシン上でしか存在できないローカルユーザーで、認証もローカルマシンの認証機関(Security Account Manager:SAM)で行う』
ということを覚えておいてください。

図1 ワークグループ上でのおなじみの認証ダイアログ
ntlm_dg

b ドメインとは

    b-1. ドメインコントローラ(一台で兼用可能であるが DNS サーバも)が必須

    b-2. 別途ドメインコントローラ以外のマシンでドメインに参加する手順が必要となる。

    b-3. ユーザーオブジェクトはドメインコントローラ上に作成しドメインコントローラで集中管理可能。(つまりユーザーログオン先としてはローカルとドメインの 2 つが選択可能)

※補足
b-1 について 一般的にはファイルサーバーや DB サーバー等他のリソースサーバーとも共存可能
b-3 について
例えば contoso.com ドメイン内の FS01 と FS02 というファイルサーバーがあったとして、contoso.com ドメイン内の CL01 というクライアントから FS01 FS02 にアクセスした場合を想定します。
そこで、例えば、\\FS01 とか \\FS02 という指定でサーバーに共有アクセスしたとします。

内部では CL01 から FS01 や FS02 にアクセスする際に CL01 にログオンしている contoso.com ドメインのユーザー名とそのパスワードが暗号化された状態でドメインコントローラに渡され、Kerberos 認証というものを行い認証にクリアできれば FS01 FS02 に提示する目的の TGS というサービスチケットがドメインコントローラからクライアント (CL01)に発行され、その TGS というチケットを FS01 FS02 に提示してアクセス許可の有無に移行します。

Kerberos 認証に失敗した場合、クライアントにはユーザー名とパスワードを入力させるダイアログボックス(図2)が繰り返し表示されるかエラーメッセージ(図3)が表示されアクセスに失敗します。

ここまででお気づきの方もいらっしゃると思いますが、Kerberos 認証を使用することで、ワークグループ環境であったら例えば FS01 にアクセスした後に FS02 にアクセスした場合はそれぞれ基本的には FS01 と FS02 上のローカルユーザー 2 つの資格情報を、アクセスするたび入力する必要がありましたが、同一のドメイン内であれば(FS01.contoso.com,FS02.contoso.com,CL01.contoso.comであった場合)ドメインユーザーでクライアント(CL01)にログオンさえすれば、後は資格情報の入力等も必要ありません。

また脱線しましたが。。。
『ドメイン環境でのユーザーはドメインコントローラ上のユーザー(ドメインユーザーと呼びます)で、認証もアクセス先のサーバーの SAM ではなくドメインコントローラの認証機関(Kerberos Key Distribution Center: KDC) で行う』
ということを覚えておいてください。

どちらがいいかと言う指針なのですが、
一般的ですが ユーザー数が 30 名以上いる環境ではドメイン環境が 30 名以下であった場合、ワークグループ環境がいいかと思います。
※マイクロソフトとしての環境構築に体裁する敷居値については推奨値はございません。

上にも書いたのですが、実際に使用するユーザー数が比較的多い場合はドメインコントローラでのユーザー一括管理が有効です。
そのほかにもドメインレベルでのグループポリシー等でドメイン配下のクライアントPC およびユーザーを一括設定することが可能です。

逆に実際に使用するユーザー数が少ない場合はドメインコントローラでのユーザー管理よりもローカルユーザーを使用した管理のほうが直感的で分かりやすいかもしれません。

以上を踏まえて環境構築してみてはいかがでしょう。

図2 あえて、ドメインコントローラ上の Key Distribution Center サービスを停止させてから \\FS01\share にアクセスさせてみました。
すると 図2 が表示され、ユーザ名に domainName\userName とパスワードを入力したら、図3 が表示されアクセスに失敗しました。
krb_err_dg

図3
krb_err_msg

関連記事

Windows OS を使って共有を管理する

共有フォルダに接続できない いままでサポートをしていて最も多い問い合わせが 「Windows

記事を読む

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

no image
冬に流行するもの

あ、さて・・・ とか流暢なこと言ってられなくなっています。 な

ドメインとワークグループ

さて前のトラブルシュートの記事はあくまで、ワークグループ環境(一部の

Windows OS を使って共有を管理する

共有フォルダに接続できない いままでサポートをしていて最も多い問い合

→もっと見る

PAGE TOP ↑