GPO

このエントリでは典型的なWindowsクライアント、Windowsサーバーのトラブルシューティング時の確認ポイントやよくある問題についてまとめてみようと思います。 ログ確認 - イベントログ アプリケーション - システム - (監査)※監査ログを追う機会は比較的少ない - アプリケーションのログ デバッグモード、診断ログ的なものがあれば有効にする - 循環したり、切り捨てられるものが多いのですぐに回収する ダンプ - ダンプファイル確認 再現 - 再現性の有無を確認する - 再現手順を探す 設定差異 - 問題が発生する状況を確認する(問題発生時と未発生時) 端末 - ユーザー - OSバージョン - SPバージョン - 修正パッチ - ブラウザ(違うブラウザでの切り分け) - 導入ソフトウェア、アドオン 特にウイルス対策ソフトウェア(無効、除外による切り分け) - ログオンDC - ログオンサイト - ドメイン - ネットワーク設定 SNP - GW - DNS - NetBIOS over TCP/IP - WINS - IPv6 - コンポーネント - Windows FireWall パフォーマンス確認 - CPU - メモリ - ディスク - リーク メモリーリーク - ハンドルリーク 環境確認 - ネットワークトラフィック ブラックホールルーター問題 - SNP - ジャンボフレーム - DC複製状況 repadmin - GPO適用状況 gpresult - VSS動作状況 vssadmin list writers 問題発生時の動作確認 - ProcessMonitor - TCPコネクション状態 TCPポート枯渇 - パケットキャプチャ ...

ものすごく長いタイトルになってしまいましたが、今回は管理者権限を持たないユーザーにどのように管理者権限を持たせるか、というお話です。 実際の案件の中では以下のような状況が頻繁にあります。 - エンドユーザーの端末にソフトウェアをインストールさせたい、あるいは管理者権限が無いとできない設定変更をさせたい - でも、エンドユーザーのアカウントには管理者権限がない - エンドユーザーに操作をしてもらうことは可能だけど、管理者のID、パスワードは教えたくない(セキュリティ上の問題) やりたいことは簡単なんですけど、「エンドユーザーには教えずに」ということを実現させようと思うと中々大変です。 理想の状況 このようなことは頻繁にあるものなので、これらを簡単に実現するツールが全端末に仕込まれている状況が理想的です。これを実現する製品は多数存在しています。有名なところだと以下のようなものでしょうか。(私が仕事でよく扱っているものなので、偏ってるかもしれません。) - [System Center Configuration Manager : ホーム](http://www.microsoft.com/japan/systemcenter/configmgr/default.mspx) - [IT資産管理 ツール QND Plus ｜ クオリティ](http://www.quality.co.jp/products/QND/) - [LanScope Cat6 トップページ](http://www.motex.co.jp/cat6/index.html) - [BigFix, Inc. | Faster, Smarter Systems Management](http://www.bigfix.com/) もっとも、これらの製品は総合的な管理ツールになっているので、今回話題にしていることだけをしたいような時に導入するようなものでもないです。お値段も結構しますし…、ということでこういった製品が導入されていない企業も数多くあります。特に日本企業には多い印象です。話で聞くところによると米国企業はほとんどなにかしら導入しているらしいですけれども。 Active Directoryのグループポリシーを使う方法 製品が導入されていない状況でこれを実現する方法として、まずADのGPOを使う方法があります。 ソフトウェアインストール 例えばソフトウェア配布なら「ソフトウェアインストール」を使うことができます。 ただ、これがなかなか曲者でして、以下の制限事項があります。 - インストールできるのはmsiパッケージのみ(setup.exeなどは無理) - 「コンピューターの構成」-「ソフトウェアインストール」で構成した場合ローカルのSYSTEM権限で実行される - 「ユーザーの構成」-「ソフトウェアインストール」で構成した場合ログオンユーザーの権限で実行される(今回の場合使えない) - インストールに成功したのか、失敗したのか、どの程度の進捗なのか等を管理者が把握できない 1.の制限により、そもそもこの機能では配布できないことが結構あります。2.の制限があるのでパッケージの置き場所はドメインユーザー以外もアクセス可能にしなくてはいけませんし、都合の悪いことにそもそもSYSTEM権限ではインストールが成功しないソフトウェアが結構存在します。そして、4の制限があるので、トラッキングができません。 というわけで、やってみてうまく動けばそれでいいのですが、結構なケースでこの方法が取れないことがあります。 スタートアップスクリプト 「ソフトウェアインストール」が使えない場合、あるいはそもそもソフトウェアインストールではない場合にはスタートアップスクリプトを使うこともできます。 これであれば自分でロジックを作り込めるのでsetup.exe等の実行ファイルであってもキックすることができます。また、成功、失敗等の把握はどうにでもできます。簡単にやるなら、例えばインストールログを共有フォルダに保存させるようなロジックにしてしまえばいいでしょう。 ですが、以下の制限事項は同じです。 - 「コンピューターの構成」-「ソフトウェアインストール」で構成した場合ローカルのSYSTEM権限で実行される - 「ユーザーの構成」-「ソフトウェアインストール」で構成した場合ログオンユーザーの権限で実行される(今回の場合使えない)コンピューターの構成に仕込んでみて、ローカルのSYSTEM権限のみでうまく行くことを祈ることになります。 このようにADを使う方法はどのパターンでも確実に成功するわけではありません。そして、そもそも論としてはADに参加しているクライアントでなければこの方法は取れないわけです。 その他の方法 他の方法としては以下のようなものがあります。どれも完全なソリューションではないですが・・・。 ...

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