[番外編]究極のバックアップ方法

※今回は番外編です。メーカーの保障も私の保証もありません(笑)。 バックアップソフトウェアって、リストアソフトウェアじゃないよね 私が思うに、「バックアップソフトウェア」は、あくまでも「バックアップ」用であって、「リストア」用ではないです。メーカーの出しているマニュアルの手順どおりに操作を行っても「バックアップしたとおりには戻らない」「導入している製品ごとに個別にリストア手順を確立する必要がある」というのが当たり前です。フルバックアップしたものをフルリストアしても動かないなんてひどいじゃないですか。 一方、素敵にバックアップが取得できて、素敵に戻ってくれるのがディスクイメージングツールです。そもそも別OSで立ち上げて、ディスクイメージを取っているわけですから戻らないわけが無いんですけどね。でも、これだと、サーバーに必ずダウンタイムを作らなくてはいけないし、自動化もかなり難しいので、実運用に乗せるのは特殊なケースを除いてかなり厳しいでしょう。 イメージングツールの良い面と日々のバックアップツールの良い面を併せ持つすばらしいソリューションであるはずだった、オンラインでディスクイメージを取得するバックアップ製品。うまく動く場合にはいいのですが、はっきり言ってあちこちからトラブルの話ばかり聞こえてきます。しかもよくあるのはスナップショットドライバのバグでBSoDが発生するような致命的なものばかり。 究極のバックアップ方法 そんな中、私が知る限り必ず完璧に環境を戻してくれる素敵な手法があります。それは、「RAID1」です。 「『RAID1』ってHDDの冗長化の手法じゃなかったっけ?」というのは正しい反応なのですが、私が言っているのもそれです。同じ内容のディスクがあるわけですから、それがバックアップになっているのです。たとえば以下のようなときに使えます。 - 「あ、今の状態を取っておきたいな」と思ったらオンラインのまま(あるいはオフラインにしてから)1本引き抜く(バックアップ)。その後、別の新しいディスクを刺しておけばまた同期される。 - 「もしもうまくいかなかったらすぐに元に戻したいな」と思ったら、オンラインのまま(あるいはオフラインにしてから)1本引き抜く(バックアップ)。その後作業がうまくいけば抜いておいたディスクをそのまま指せばいいし、もしも作業がうまくいかなかったら一度オフラインにして、とっておいたディスクだけを刺して起動し、その後もう1本のディスクを指せばいい。 バックアップとずれますが以下のようなHDDコピー機としての使い方も。 - 同じハードウェア構成のサーバーを複数台構築するときに。1台を構築し、1本HDDを抜いて、新しいHDDを刺して、同期して、1本抜いて・・・を繰り返せばあっという間に複製完了 「いきなり引き抜いたら駄目なんじゃ?」と思う人もいるかもしれませんが、はっきり言っていきなりBSoDで落ちたときと同じレベルですし、昨今はきちんとファイルシステムレベルでジャーナル機能を持っているのでおいそれとおかしくはなりません。気になるならメモリの内容をフラッシュさせてから抜くなり、安全にやりたかったらオフラインで抜けば心配事は何もありません。 「単一で稼動するサーバーならそれでいいかもしれないけど、複数台で連携して稼動するようなシステムではだめだろう」と思う人もいるかもしれません。それは正しい指摘だとは思いますが、それでは世の中にあふれているバックアップソフトがそこまできちんと整合性を取ってバックアップ取得~リストアしてくれるでしょうか?・・・同じことだと思います。それに、どうしても完全に安全にやりたければ、関連するシステムを全部シャットダウンしたうえで、オフラインの状態でHDDを引っこ抜けばいいんです。この芸当はオンラインでバックアップを取得するソリューションでは不可能です。オフラインのイメージングツールでも同じことはできますが、やろうとおもったらRAIDのドライバが・・・とか色々面倒です。ディスク引っこ抜くのは一瞬です(笑)。 「OS部分はそれでいいかもしれないけど、データが外部ストレージにあるような場合はどうするんだ」と思う人がいるかもしれませんが、まさにデータ部分に対してこの手法を用いているのがディスクのクローニングの技術です。なぜ外部ストレージにあるデータにはディスクでのコピーを許容するのに、OS部分にはそれを使わないんですかね?矛盾して無いでしょうか? ・・・。 オンラインでディスクの同期を停止してもデーターの整合性がとられるようにVSSなどの技術があるわけなので、それとこれとは話が違うじゃないかと思うと思いますが、それは正解です(笑)。 冗談はともかく真面目な話 冗談はともかくとしても、私は真面目な話としてこのRAID1を使ったバックアップを、ロールバック案としてきちんと検討、採用していいのではないかと考えています。 たとえば、Active Directoryのスキーマ拡張作業。普通に作業をするだけなら10分で終わる作業です。CD or DVDを入れてコマンド一発です。ですが、マイクロソフトが「スキーマ拡張作業で何か問題が発生したときにはフォレスト全体に悪影響が及び復旧に多大な時間がかかる可能性があるから・・・」とかなんとか脅かして、“ベストプラクティス"としてまだるっこしい手順を大々的に宣伝してしまったものだからみんなビビッて10分の作業のために何時間も、何日も、準備をふくめて何ヶ月もかけるケースすらあります。(たとえばこの辺とかMicrosoft での構造化された Active Directory スキーマ管理) もちろん、それだけの危険性がある根拠があるのであれば(たとえば、勝手にスキーマを拡張しまくっていて本当にバッティングの恐れがある、とか)わかるのですが、スキーマはだれも自分たちではいじっていないし、ADとExchangeが入っているだけ・・・というような場合には問題が起きる可能性なんてありえないんです。だって全く同じことが世界中で行われていて、問題ないんですから。 なのに、まずステージングサイトを用意して、スキーママスタをステージングサイトに移動して、そこでまずアウトバウンドの複製をとめて・・・だの何だのやり始めてしまうのは全く持ってナンセンス。だと思うのです。まずやってみて、駄目だったら戻せばいいじゃないかと言いたいのです。 そうすると、「リストア手順の確立」とか、「復旧時間が」とかそういうまためんどくさい話になります。DCの場合には複製も考慮しないといけないので、さらにめんどくさい。 で、こんなときこそ私はこのRAID1でのバックアップをロールバック手段として使えばいいんじゃないかと思うのです。 - 全DCシャットダウン~HDD1本抜く - DC起動 - スキーマ拡張 - テスト - (テストOKなら)抜いてあったHDDをオンラインのまま指す - (テストNGなら)全DCシャットダウン~抜いてあったHDDを刺して起動 これでいいじゃないですか。これならDCの数にもよりますけど1時間もあればロールバック含めて完了するでしょう?戻らない可能性なんてほぼ無いでしょう?準備も必要ないでしょう? というわけで、今回は無責任なことを言って終わりにします。あまり真に受けないでください。

February 17, 2009 · 1 min · 胡田昌彦

NETBIOS名とホスト名の違い

今回は「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)

February 10, 2009 · 1 min · 胡田昌彦

sysprepの意味

ディスクイメージを作成し、それをクローニングする作業の中ではよくsysprepが実行されます。ここでは「なんのためにsysprepを実行するのか」「実際には裏で何が行われているのか」といったことを整理してみます。 sysprepは何をしてくれるのか sysprepはそもそも何をしてくれるものなのか、という点に関してはTechNetに記述がありますので、引用します。 Sysprep ユーティリティは下記の 3 つの異なる用途で使用できます。 **ディスクの複製。**Sysprep を使用してディスク複製の準備を行うと、完全にインストールされたシステムを同様のハードウェアにコピーできます。Sysprep によって、ローカル コンピュータのセキュリティ ID (SID) がコンピュータごとに一意になるように変更されます。詳細については、次を参照してください。Sysprep を使用してディスク複製用のイメージを準備する方法 (英語) 監査。 コンピュータの監査を実行した後に Sysprep を使用すると (–nosidgen コマンド ライン オプションを使用)、Sysprep によって、エンド ユーザーが Windows を実行できる準備が整えられます。詳細については、次を参照してください。Sysprep を使用して監査をインストールする方法 (英語) **ミニ セットアップの自動化。**Sysprep では簡易形式の GUI モード セットアップが作成されます。このセットアップでは、通常 45 ~ 60 分かかる処理が 5 ~ 6 分で済み、エンド ユーザーは使用許諾契約書 (EULA) の同意や、プロダクト キーの入力、ユーザー名および会社名の入力など、ユーザー固有の必須情報を入力するだけで済みます。このモードで Sysprep を使用するには、Windows XP をローカル コンピュータにプレインストールした後、–nosidgen パラメータを付けて Sysprep を実行し、次の手順に従います。詳細については、次を参照してください。Sysprep を使用してミニ セットアップを自動化する方法 大きく3つの用途があるということですが簡単に言ってしまえば以下の3つです。 SIDの変更 監査の実行 ミニセットアップの実行 が、はっきりいって2と3は普通行いません。通常はディスクの複製時におけるSIDの変更のためにsysprepが実行されると思っておいて良いでしょう。 具体的な動作ロジックに関してはsysprepではなく類似のSID変更ツールであるNewSIDに詳細に書かれており、sysprepでも同じことが行われていると考えてよいものと私は考えています。 以下NewSID v4.10から引用しました。 NewSID starts by reading the existing computer SID. A computer’s SID is stored in the Registry’s SECURITY hive under SECURITY\SAM\Domains\Account. This key has a value named F and a value named V. The V value is a binary value that has the computer SID embedded within it at the end of its data. NewSID ensures that this SID is in a standard format (3 32-bit subauthorities preceded by three 32-bit authority fields). ...

January 17, 2009 · 6 min · 胡田昌彦

ドメイン参加

今回はドメイン参加の話をします。ドメインといってもDNSの話ではなく、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 コンテナのリダイレクト

January 12, 2009 · 1 min · 胡田昌彦

AI・テクノロジーの情報を発信しています

YouTube

AI・テクノロジーの最新トレンドを動画で配信中

note

技術コラム・深掘り記事を公開中