NETBIOS

今回は「インターネット」ではなくて、「イントラネット」に繋がらないというケースについて書いてみます。 今、Active Directoryで構成されたWindowsネットワーク(ドメイン名sample.lcoal)があるとして、そこにintraという名前のメンバサーバーがあり、そこでイントラサイトが稼働しているとしましょう。このときのURLは何になるでしょうか? - http://intra/ - http://intra.sample.local/ さて、どちらが正解でしょうか? 正解は、「どちらも正解」です。 「なんだ、それは」と思うかもしれませんが、これがなかなか奥深い話もあったりします。たとえば1のhttp://intra/というアドレスを使っている場合。クライアントの設定によってはつながったりつながらなかったりします。繋がる場合でも、名前解決の方法が異なったりします。ちょっと詳しく見てみましょう。 名前解決の手段は何か? まず、http://intra/というURLですが、実際にはintraというホストのIPアドレスを知らなくてはいけません。最終的にはTCP/IPで接続するわけですから。 名前解決の手段としては様々なものがある、という話は以前しました。 - 参考：[NETBIOS名とホスト名の違い](https://windowsadmin.ebisuda.net/2009/02/10/netbios%e5%90%8d%e3%81%a8%e3%83%9b%e3%82%b9%e3%83%88%e5%90%8d%e3%81%ae%e9%81%95%e3%81%84/) この場合intraを名前解決する方法は以下のパターンがあるわけです。 - hostsファイル(ホスト名) - DNS(ホスト名) - lmhostsファイル(NETBIOS名) - WINS(NETBIOS名) - ブロードキャスト(NETBIOS名) で、厄介なのが2に関してです。 ドメインサフィックス DNSとして考えたときに「intra.」なんていうホスト名はあり得ないわけです。本来は「intra.sample.local」です。なので「intra」を裏で「intra.sample.local」に変更してくれている仕組みが存在するわけです。 マイネットワーク→プロパティ→(対象NIC)→プロパティ→インターネットプロトコル(TCP/IP)→プロパティ→詳細設定→DNSタブ (なんてわかりづらい所にあるんでしょう…) - 「プライマリおよび接続専用のDNSサフィックスを追加する」 - 「プライマリDNSサフィックスの親サフィックスを追加する」 - 「以下のDNSサフィックスを順に追加する」 - 「この接続のDNSサフィックス」 そしてもう一か所あります。 マイコンピュータ→プロパティ→コンピュータ名タブ→変更→詳細 (なんてわかりづらい所にあるんでしょう…) - 「このコンピューターのプライマリDNSサフィックス」 - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」 これらの設定が"仕組み"になります。 勝手にドメインサフィックスが追加される理由 通常は以下のような流れで、勝手に適切なドメインサフィックスが追加されるようになっています。 - Active Directoryに参加する - 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」が既定で有効であるため、ドメイン名(sample.local)が「このコンピューターのプライマリDNSサフィックス」として設定される - DNSを使った「intra」の名前解決の際に「プライマリおよび接続専用のDNSサフィックスを追加する」および「プライマリDNSサフィックスの親サフィックスを追加する」が有効であるので「intra.」だけではなくて「intra.sample.local」も検索される うまくいかないケース ここまでの説明が理解できれば、http://intra/ではアクセスできないケースがあることが理解できるのではないかと思います。 具体的なケースを示します。まず前提として以下のケースで、 - hostsファイルに記載されていない - lmhostsファイルに記載されていない - WINSが構成されていない - 対象サーバーと同一サブネットに無い(ブロードキャストでの名前解決はできない) これらすべてに加えて、以下のどれかの条件に当てはまる時です。 ...

今回はレイヤ2の話です。 レイヤ2と一口に言ってもPPPやHDLCやADCCP等多数のデータリンクプロトコルがありますが、まずはなんといってもイーサネットに関しての理解が必要です。 MACアドレス レイヤ2において色々と理解すべきことはありますが、まずは何と言っても「MACアドレス」を理解しなくてはいけません。大げさに言えば、私はMACアドレス、レイヤ2の概念をきちんと理解しているかどうかが素人とプロのまず大きな違いだと思っています。そのくらい重要です。 昨今ではTCP/IPが全盛なので、「コンピューターはIPアドレスを持っていて、IPアドレスを住所のように使って通信している」という理解をしている人が多いですし、確かにそれは間違いではありません。ですが、それはレイヤ3を考えた時の話です。レイヤ2で同じようなレベルで理解をするならば「NICはMACアドレスを持っていて、MACアドレスを住所のように使って通信している」ということになります。 「NIC」というのは「Network Interface Card」の略で「LANカード」などとも言われます。このNICに、MACアドレスというものが指定されているわけです。 MACアドレスを確認する 「IPアドレスは設定したことあるけど、MACアドレスなんて設定したことないよ?」という人も多いと思います。まずは自分が今使っているコンピューター(についているNIC)のMACアドレスを確認してみましょう。 コマンドプロンプトで「ipconfig /all」を実行してみてください。 「Physical Address. . . . . . . . . : XX-XX-XX-XX-XX-XX」という行があります。これがMACアドレスです。上の例だと「00-0F-B5-8E-0B-54」ですね。 このMACアドレスはメーカーが工場でNICを生産する際に埋め込みます。ですので基本的に私たちが設定するものではありません。(例外はありますがまずはこの理解でいいでしょう。) MACアドレスからベンダーを調べる このMACアドレスは重複しないようにメーカーごとに割り当てることができる範囲が決まっています。ですので、MACアドレスを見ればどのメーカーのNICなのかわかるようになっています。具体的にはMACアドレスの先頭24ビットがベンダーをあらわしています。具体的には以下のようなサイトで調べることができます。 IEEE Registration Authority - IEEE OUI and Company_id Assignments サイトに行って「Search the public OUI listing . . .」という項目に自分のNICのMACアドレスの先頭24ビットの値を入力して「Search!」して見ましょう。 上の例であれば「00-0F-B5」というのは「NETGEAR Inc」のNICであることがわかります。 フレームの構造 レイヤ2のレベルで考えたときには宛先、送信元にMACアドレスが入力され、Ethernetに電気信号として伝えられます。これの塊をレイヤ2では「フレーム」と呼びます。「フレーム」は以下のような構造をしています。 「プリアンブル」「タイプ」「FCS」などの理解はとりあえず後回しで大丈夫です。重要なのは「宛先MACアドレス」と「送信元MACアドレス」です。 原則としてEthernetでは全てのフレームが全てのコンピューターに届けられます。レイヤ1レベルではただの電気信号なので繋がっている全てのコンピューターまで届くわけです。NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す、という動きをします。(※例外あり、後述) どうやって通信相手のMACアドレスを知るのか では、何か通信をしたい時、送信元MACアドレスには自分が知っている自分自身のMACアドレスを入れればいいとして、宛先MACアドレスはどうしたらいいでしょうか?どうしたらわかるでしょうか? たとえばpingを考えてみましょう。「ping x.x.x.x」という形でコマンドを打つときには、宛先のipアドレスはコマンドを打つ人が入力してくれますが、このときにMACアドレスを入力するということはしません。 ですので、IPアドレスからMACアドレスを知る仕組みが必要になるわけです。NICの気持ちになって考えてみると「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という事をネットワークに流せばよさそうです。そしてMACアドレスを教えてもらう。このやり取りを**ARP(Address Resolution Protocol)**と言います。 ARPは正確にはレイヤ3に属するプロトコルなのですがレイヤ2のMACアドレスを理解するために重要なのでここで登場してもらいました。 ブロードキャスト ところで、「x.x.x.xのIPアドレスを持っている人MACアドレス教えて」という時には宛先MACアドレスには何を入れればいいでしょうか?宛先MACアドレスを知るための通信をするときの宛先MACアドレスです。 なかなか難しいですが、正解は「全員宛て」です。全員に通信を受け取ってもらって、受けとったコンピューターのうち、x.x.x.xのIPアドレスを持っているコンピューターからのみ返事をもらえればいいわけです。 このような「全員宛て」という意味で「FF-FF-FF-FF-FF-FF」というMACアドレスが使われます。先ほど「NICはフレーム内の宛先MACアドレスが自分のMACアドレスと等しいかを確認し、自分宛のものであれば上位の層(具体的にはレイヤ3)にデータを渡す」というように説明しましたが、より正確にはここで宛先MACアドレスとして「ブロードキャストアドレス(FF-FF-FF-FF-FF-FF)」やマルチキャストアドレス「01-00-5E…」であっても受け取って上位層に渡します。 MACアドレスだけではなぜいけないのか? さて、MACアドレスというものを知りました。宛先のアドレスはブロードキャスト、ARPを使って知ることができます。この仕組みだけあれば他にアドレスは必要ないようにも思います。なぜMACアドレスだけでは駄目なのでしょうか? 実際、昔Windowsネットワークで使われていたNETBEUIというプロトコルには他にアドレスは存在しません。NETBIOS名というものはつけますが、NETBEUIにおいてNETBIOS名はMACアドレスと一対一に対応付けられます。サブネットマスクだのデフォルトゲートウェイだのルーティングだの面倒なことはなにもありません。ネットワークに接続しさえすればきちんと通信できるのです。こっちのほうが楽でいいのではないでしょうか? この問いへの答えはブロードキャストのことを考えるとわかります。実際にデータを届けるには相手のMACアドレスが必要なわけですからブロードキャストするわけです。そのフレームは全コンピューターに届かなくてはいけません。これは小規模なネットワークなら問題にならないでしょう。ですが、今日最大のネットワークであるインターネットではどうでしょうか? インターネット上の全てのコンピューターの発するブロードキャストが全てのコンピューターが受信する必要があるとしたら、おそらくブロードキャストパケットだけでネットワークは飽和してしまうでしょう。 ...

今回は「NETBIOS名」と「ホスト名」について解説します。「NETBIOS名」と「ホスト名」が混ざってしまいよく理解できていない人はかなり多いです。いざという時のトラブルシュートで差が出ますのでしっかり理解しましょう。 Windowsネットワークの歴史 NETBEUIの時代 「NETBOIS名」のことをよく理解するためにはWindowsネットワークの歴史を知らなくてはいけません。 まず、今のTCP/IP全盛の時代からすると信じられないかもしれませんが、初めてWindowsにネットワーク機能が標準搭載されたWindows95では規定のプロトコルはTCP/IPでは無くてNETBEUIというものでした。そしてNETBEUIはNETBIOSというAPIを利用しています。 NETBEUIはTCP/IPとは全く異なる考え方のプロトコルです。IPアドレスなんてありません。ルーティングもしません。名前だけ決めておけばアクセスできる。そんなプロトコルです。考え方は非常にシンプルです。 このNETBIOSのAPIを利用するために「コンピューターにつける名前」が「NETBIOS名」です。 Windows95, 98の時代にはコンピューターにコンピューター名(=NETBIOS名)だけつけておいて、あとはEthernetで接続(レイヤ1で接続)だけしておいてあげれば「\コンピューター名」という形式で他のコンピューターにアクセスしてファイル共有やプリンタ共有を利用することができました。 「NETBEUI時代に使っていたコンピューター名」が「NETBIOS名」です。 NETBEUIの限界 NETBEUIは現在ではほぼ使われていません。なぜ使われていないのかというと以下の点で現在のネットワーク環境に合わなくなってしまったからです。 - ルーティング機能が無いため大規模なネットワークには向かない - インターネットが普及し、NETBEUIとの相互接続性に問題がある 95, 98の時にはファイルやプリンタの共有のためにはNETBEUIプロトコルを使って、インターネット接続にはTCP/IPを使って･･･と、複数のプロトコルスタックを使うようなこともありました。今では用途別に複数のプロトコルスタックを使い分けるということはもうほぼありません。 TCP/IPへの移行 Windowsネットワークもインターネット普及の流れに乗るためにTCP/IPを標準のプロトコルに採用します。時代の流れです。ですが、単純にTCP/IPに移行してしまうと今まで使っていたNETBIEUI+NETBIOSのAPIをつかったWindowsファイル共有やプリンタ共有が使えなくなってしまいますし、Windowsネットワークの特徴であった「とりあえず名前だけ決めておけば繋がる」という利点が失われてしまいます。 そこでマイクロソフトがとったのはTCP/IPの上でNETBIOSのAPIを使えるようにする、という戦略です。これをNETBIOS over TCP/IPといいます。TCP/IP上でNETBOISを使えるようにしたわけです。これにより、NETBIOSのアプリケーションそのままに、TCP/IPを使って複数セグメントに分かれた大規模なネットワークにも対応可能になりました。 このNETBIOS over TCP/IPの機能があるため、何も設定していない状態で「ping コンピューター名」に応答が返ってくるわけです。 複数セグメントになったことで起きる問題 NETBIOS over TCP/IPによって複数セグメントに対応し、大規模なネットワークに対応できるようになりました。ですが、もともとNETBEUIは「ブロードキャスト」を多様することで簡単に接続できるようになっていたため、複数セグメントに分かれてしまうとNETBIOSのAPIがきちんとネットワーク全体で使えない、という問題が出てきてしまいます。 この問題を解決するために、セグメントを越えるために、出てきた技術がWINSです。各コンピューターがNETBIOS名とIPアドレスの対応付けをWINSサーバーに登録しておき、利用したい場合にはWINSサーバーに問い合わせることで、セグメントを越えることができるようになりました。 また、lmhostsファイルというファイルにもNETBIOS名とIPアドレスの対応付けを書くことができるようになっています。 WINSサーバーを使うかlmhostsファイルにそれぞれ記述することでセグメントを越えることが出来るようになっています。 NETBIOS名 ここまで見てきたようにNETBIOS名というのはもともとTCP/IPとは別のNETBEUIというプロトコルスタック上で使われていた名前です。WindowsがNETBEUIからTCP/IPに乗り換える際に、過去の遺産を持ってきた、そういう構造になっています。ですからはじめからプロトコルスタックにTCP/IPを採用していたUNIX系のOSではNETBIOS名という考え方は存在しません。 基本的には自分のNETBIOS名をコンピューターは知っていて、それが(ブロードキャストで)呼ばれたら変事をするような仕組みになっています。 UNIX系ネットワーク(TCP/IP)の歴史 hostsファイル TCP/IPでは他のコンピューターと通信する際にはIPアドレスを利用します。 IPアドレスを人間が全て記憶することは難しいため、hostsファイルにIPアドレスとそれにつけるコンピューターの名前(=ホスト名)を記述し、管理していました。全てのコンピューターにhostsファイルを記述する、というのがもっとも原始的な形態です。 個別のhostsファイルにホスト名とIPアドレスの対応付けを全て記述していたのでは、ネットワークにコンピュータが1台増えただけで、既存のコンピューター上の全てのhostsファイルを更新して回る必要が発生してしまいます。同じようにIPアドレスを変更したい、ホスト名を変更したいと思った場合も同様です。 このようにhostsファイルだけでは小規模なネットワークならともかく、大規模なネットワークでは事実上管理できません。 DNS hostsファイルの問題を解決する仕組みとして考え出されたのがDNSです。クライアントはDNSサーバーに問い合わせて、ホスト名とIPアドレスの変換を行います。 ただし、この際に単純にhostsファイルに記載されていたものをDNSサーバー上に登録しただけでは何百、何千、何万というレコードを1台のサーバーで管理しなくてはいけなくなります。DNSはインターネット上でも使われていますが、インターネット上のホストとなると何百万、何千万、何億という単位です。これを1台で全て管理したり、冗長化のために複数台にコピーしたり、というのはかなり効率が悪いです。 さらにもしかしたら全く同じ名前を持っているホストが存在しているかもしれません。この場合どちらかのレコードのみを登録するわけにもいきませんのでどちらかの名前を変更しなくてはいけなくなってしまいます。 そこでDNSには、このような問題を解決するためのしくみとして、「ドメイン」という概念が導入されています。「ドメイン」ごとにレコードを管理し、ホスト名のあとにドメイン名までつけて1つのホストを表します。たとえばこのブログが稼動しているサーバーはdyndns.bizというドメイン上のebiというホストです。ebi.dyndns.biz.というのが完全修飾ドメイン名(FQDN)になります。(※完全修飾ホスト名とは言わずに、完全修飾ドメイン名といいます。) ちなみにWINSにはこのような「ドメイン」という考え方は存在しませんので上記の問題をそのまま抱えています。ですので、マイクロソフトもWINSには見切りをつけていて、廃止の方向に向かっています。 ホスト名 見てきたように「ホスト名」はhostsファイルおよびDNSにて管理され、ドメインという概念を含んだものです。 NETBIOS名とは異なり、自分のホスト名に対してそのIPアドレスを返答するような仕組みは備わっていません。 Active DirectoryでDNSを導入 マイクロソフトはWindows2000でActive DirectoryというWindowsネットワークを管理する新しい仕組みを導入し、その中で名前解決の仕組みにDNSを導入します。ここから本格的にWindowsネットワークでもTCP/IP+DNSという仕組みを採用したわけです。 ですが、過去の資産を継承するためにNETBIOSの仕組みも存続させます。NETBIOS over TCP/IPも搭載していますし、NETBIOS名の名前解決の仕組みとしてWINSも健在です。 このようにして、WindowsネットワークはNETBIOS名とホスト名が混在するややこしい状態になりました。 ポイント - lmhostsファイルとhostsファイル、WINSとDNSとが技術的には対応付けられる。ただし、その技術が必要となってきた経緯は異なる。 - ホスト名はTCP/IP,Unixの文化から来ている。 - NETBIOS名はNETBEUI(プロトコルスタック)+NETBIOS(API)という過去の技術を継承しているために残っている。TCP/IPへとプロトコルスタックを変更する際にNETBIOS over TCP/IPという技術が導入され、これによりTCP/IPネットワーク上でNETBIOS(API)が利用できる。 - NETBIOS名とホスト名が混在しているのはWindowsネットワークだけ。 参考 - [Insider's Computer Dictionary [NetBEUI] － ＠IT](http://www.atmarkit.co.jp/icd/root/14/5787514.html) - [DNSの仕組みの基本を理解しよう](http://www.atmarkit.co.jp/fnetwork/rensai/dns01/dns01.html) - [＠IT：基礎から学ぶWindowsネットワーク](http://www.atmarkit.co.jp/fwin2k/serial/index/index.html#baswinlan)

今回はドメイン参加の話をします。ドメインといってもＤＮSの話ではなく、Windowsのドメインの話です。(両者はよく混同されるので気をつけてください) ドメイン参加をすると何が嬉しいのかという事に関してはまた別エントリにして、ここでは、ドメイン参加時の設定の意味や良くあるトラブル等に関しての話をします。 ドメイン名には二種類ある test.localというActive　Directoryのドメインがあったとします。この時、ドメイン参加する際に入力すべきなのは「test」でしょうか、「test.local」でしょうか?この問いに答えるためには2つの違いをしっかりと認識しておく必要があります。 まず「test」ですがこれはNETBIOSドメイン名と呼ばれます。より正確には大文字で「TEST」です。これはNTドメインの時代から使われてきたドメイン名です。NETBIOSの名前ですからNETBIOSの名前解決が必要になります。つまり、ブロードキャスト、lmhosts、WINSをつかってドメインを探すわけです。 一方「test.local」はDNSドメイン名と呼ばれます。こちらはDNSあるいはhostsを使ってドメインを探します。DNSのドメイン名の話ではないと始めにいっておきながらやっぱりそうじゃないか、と思うかもしれませんが、そうではありません。ここが混同しやすいのですが、あくまでも探す目的はWindowsのドメインであり、探す手段としてDNSが利用されているだけです。 「Active Directoryのドメインに参加する際にどちらが適切か」という問いに関しての答えは「test.localの方が良い」という答えになります。何故ならActive Directoryでは全てのコンピュータが適切にDNSを利用して名前解決ができる事が前提になっているからです。「test.local」と入力する事できちんとDNSを使って名前解決が出来る事のテストを兼ねる事ができる訳です。 ここでの最悪の行動は「test.localと入力したらドメインが見つから無かったが、testと入力したらドメインが見つかってドメイン参加出来たからそれで良いことにした」というものです。一見正常に動作するように見えますが後々色々な所で問題が発生してきますので、絶対にやってはいけません。具体的には、Kerberos認証ができなくなるのですが、その影響は特定のwebアプリケーションのさらに一部の機能が使えなかったり、特定のアプリケーションの動きが他の端末に比べて明らかに遅かったりなど、認証方式が原因であるということが非常にわかりづらい形ででてきてしまいます。 逆のパターン(「test」ではドメイン参加できないが、「test.local」ではドメイン参加できる場合)はWINSを使っていない環境では普通に起こりますので問題ありません。ただし、ドメインコントローラーと同じセグメントにいるコンピュータでは「test」で正常にドメイン参加できます。これは同一セグメントであればブロードキャストでの名前解決が成功するからです。これを理解していないと場所によって挙動が異なり混乱してしまいます。さらに同一セグメントであっても条件によってはドメインを見つけられないこともあり(NETBIOS over TCP/IPが無効になっている場合やノードタイプの違いなど)更に混迷を極めます。 「ドメイン参加はDNSドメイン名で」と覚えておきましょう。 ドメイン参加時のアカウント ドメイン参加をする際にはアカウントとパスワードの入力を求められます。これはなぜかというと、ドメイン参加時にはActive Directory上にコンピューターアカウントが作成されるためです。それを行うことのできるActive Directory上のアカウントを指定し、その権限でもって操作を行うわけです。具体的にはコンピューターのローカルのSIDが含まれる文字列を設定し、Active Directory上のオブジェクトと紐付けます。これによってコンピューターがドメイン上のリソースにアクセスできるようになるわけです。 このときには具体的にどのアカウントを指定すればよいのでしょうか?よく誤解されているのですが、ドメインアドミン(Domain Adminsに所属しているユーザー)である必要はありません。ドメインユーザー(Domain Usersに所属しているユーザー)であれば権限は十分なのです(正確にはAuthenticated Usersに対して許可がなされている)。つまり**「ユーザーが勝手に自宅のパソコンを会社に持ってきて、ネットワークに接続し、ドメイン参加させてしまう」ということが既定の状態ではできてしまう**わけです。 逆に言うとドメイン参加の際にわざわざ管理者が作業を行ったり、あるいはドメインアドミンのアカウントのID、パスワードを伝えたりするケースがありますが、そんな必要は無いわけです。特に、クライアントの大量導入の際に作業員にドメイン参加させるためだけにドメインアドミンのID、パスワードを一時的とはいえ伝えているケースがあるかと思いますが、セキュリティの面から考えると大変に危険ですし、かつ本来その必要は無いわけです。(※もちろんその他作業との関連性やお客様との信頼関係、作業員との信頼関係に基づき、ドメインの管理者自体を伝えて作業するケースは考えられると思います。) 企業によっては、ドメイン参加作業はユーザーが自分で行うのが当たり前という運用方針のところもあります。ドメインのユーザーであるということはドメインにコンピューターを参加させる権限がある、ということなわけです。Active Directoryはそのような思想で構築されています。もちろんこの設定は変更することもできます。 しかし、ドメインユーザーを使えばあとは何も問題が無いのかというとそういうわけではありません。既定の状態で10台までしかドメイン参加させることができないという制限があります。これではクライアントの大量導入の場合の作業効率に問題があります。 これに関しては3つの解決策があります。 ドメイン参加を許可する台数の上限を十分に大きな数に設定しておく あらかじめコンピュータアカウントを作成しておき、ドメイン参加させることができるアカウントとしてドメイン参加に使用するユーザーを指定しておく コンピューターアカウントの生成を許可するようにセキュリティ設定を変更する 特に2番目の方法だと、以下のような点で別のメリットもあります。 あらかじめコンピューターアカウントを特定のOUに作成しておくことができGPOの適用もれがなくなる コンピューター名の間違いに気が付くことができる (ドメインユーザーでのドメイン参加を許可させないように設定変更しておくことで)すでに存在しているコンピューター名でしかドメイン参加できない 権限の無いユーザーではドメイン参加できない コンピュータアカウントのできる場所 何も特別な設定を行わずにコンピューターをドメイン参加させると、コンピュータオブジェクトは「Computersコンテナ」に作成されます。特にコンピューターに対して何も特別なポリシーを適用していない、という環境ならこれで問題ないのですが、コンピューターオブジェクトに対してGPOを適用している環境では一度「Computersコンテナ」に作成されたコンピューターオブジェクトを手動で任意のOUに移動させる必要があります。これはGPOはOUに対しては適用できるもののコンテナに対しては適用できないからです。かなり面倒ですね。 全てのコンピューターを一律特定のOUに格納する運用であれば良い方法があります。以下のコマンドでドメイン参加時にコンピューターオブジェクトが作成される場所を変更させることができます。 c:\windows\system32\redirusr container-dn ただしこの方法はActive DirectoryがWindows Server 2003以上のドメイン、フォレスト機能レベルで実行されていなければいけませんので気をつけてください。 全てのコンピューターが同じOUに配置されるわけではない場合にはすでに紹介したようにコンピューターオブジェクトをあらかじめOUに作成しておく方法が良いでしょう。特にこの方法はグローバルな企業で、特定の国の管理者には特定のOUにのみ権限が委任されている場合によく採用されているようです。 認証モード すでに述べましたが、ドメイン参加後にはWindows 2000以上のOSであれば認証モードがKerberos認証に変更されます。運用中に切り分けの難しい問題で悩まないためにもきちんと確認しておくと良いでしょう。確認は以下の場所から行えます。 「マイコンピュータ」→右クリック→プロパティ→「変更」→「詳細」 「ドメインのメンバシップが変更されるときにプライマリDNSサフィックスを変更する」にチェックが入っている状態でドメイン参加し、きちんとActive Directoryであることを認識できると、この部分にきちんとドメインサフィックスが追加され、フルコンピュータ名がFQDNになります。こうなっていればきちんとKerberos認証になっている(=Active Directoryであることを認識できている)ということになります。 WINSが存在する、あるいはドメインコントローラーが同一セグメントに存在する状態で、DNSの設定を誤ったままでNETBIOSのドメイン名を指定してドメイン参加を完了すると、この部分がきちんと更新されません。気をつけましょう。 参考 ドメイン ユーザーがワークステーションまたはサーバーをドメインに参加させられない Windows Server 2003 ドメインの Users および Computers コンテナのリダイレクト