- - PR -
ActiveDirectory配下での共有フォルダのユーザアクセス制御について
1
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-11-11 02:54
こちらの会議室ではいつも大変参考になっており感謝しております。
早速で申し訳ないのですが、現在Win2000ServerのActiveDirectoryを使用して 社内のLAN構築テストを行っていますが、サーバーの共有フォルダに対する アクセス制御が思うようにできず困っております。 フォルダプロパティのセキュリティにおける詳細設定の許可・拒否内容については 理解できているつもりなのですが下記のような場合、どのようにすれば希望通りの アクセス制御ができるのでしょうか。 以前見たことがあるような気がして検索してみたのですが、見当たりませんでした ので投稿致しました。 ■現在のテスト環境■ ■サーバ構成 SRV1にActiveDirectory導入、SRV2をDCとして追加、SRV3はメンバーサーバー ActiveDirectoryはWin2000以前のドメインと互換をとるための混在モードにて構築 ドメイン名はactv-test.co.jp ■SRV1へのOUとユーザ、グループの登録 actv-test.co.jp │ ├ Kanri(OU) ┬ Soumu (グローバルグループ） │ ├ Keiri (グローバルグループ） │ ├ user-S01（ユーザ）←Soumu(グローバルグループ）に所属 │ ├ user-S02（ユーザ）←Soumu(グローバルグループ）に所属 │ └ user-K01（ユーザ）←Keiri(グローバルグループ）に所属 │ └ Kaihatsu(OU) ┬ Dev1 (グローバルグループ） ├ Dev2 (グローバルグループ） ├ user-D01（ユーザ）←Dev1(グローバルグループ）に所属 └ user-D02（ユーザ）←Dev2(グローバルグループ）に所属 ■共有フォルダ（SRV1のDドライブ） D:￥Zensya-Data ← ActiveDirectoryに共有として登録 │ ├ ￥Kanri-Data │ ├ ￥Soumu-Data │ └ ￥Keiri-Data │ └ ￥Kaihatsu-Data ├ ￥Dev1-Data └ ￥Dev2-Data ※ Zensya-Dataについて 共有のアクセス許可：Admin（フルコントロール） Domain Users（変更） ■実施したいアクセス制御 例として上記の設定状態にてクライアントPC(win2k)よりuser-S01やuser-S02が ドメインへログオン後、次のようにアクセス制御されるようにしたい。 D:￥Zensya-Data ←フォルダやファイルの追加削除不可（一覧参照可能） │ ├ ￥Kanri-Data ←フォルダやファイルの追加削除不可（一覧参照可能） │ ├ ￥Soumu-Data ←サブフォルダやファイルの追加削除可能 │ └ ￥Keiri-Data ←アクセス拒否 │ └ ￥Kaihatsu-Data ←アクセス拒否 ├ ￥Dev1-Data ←アクセス拒否 └ ￥Dev2-Data ←アクセス拒否 当然の事ながら各部署に所属するユーザは増減するわけですからグループにより アクセスの制御を行いたいので色々調べながらトライしてみたのですが、 どうしてもうまくいきません。 また先々で他のサーバーに共有フォルダを設定する場合もあり得ますので ドメインローカルのグループ使用は不適切かと思っております。 本来であればNTドメインの様にグループ配下に下位グループを設けアクセス許可設定を 簡素化したいのですが、混在モードのためグループのネストもできませんので、 最低限上記のようなグループによる制御にしたいと考えております。 混在モード状態の理由としては本稼働後、関連会社のNTドメインとのデータ交換も あるためなのですが、モード変更することにより楽に設定可能となるのであれば データ交換手段を別に考えることとしてモード変更も有りかと考えておりますが、 変更後は元に戻せませんし、できる！という確信が持てないため躊躇しております。 どの様に設定すればよいか何方かご教授いただけませんでしょうか。 よろしくお願い致します。 | ||||||||||||
|
投稿日時: 2004-11-11 07:44
soumuグループに関しては、 D:￥Zensya-Data soumu:読み取り │ ├ ￥Kanri-Data soumu:読み取り │ ├ ￥Soumu-Data soumu:変更 │ └ ￥Keiri-Data soumu:なし(何も設定せず) │ └ ￥Kaihatsu-Data soumu:なし(何も設定せず) ├ ￥Dev1-Data soumu:なし(何も設定せず) └ ￥Dev2-Data soumu:なし(何も設定せず) で大丈夫でしょう。 上記各ディレクトリでのアクセス権継承は無効にすることと、 拒否させたい場合には何も設定しないのが注意点でしょうか。 多分付与したいアクセス権は D:￥Zensya-Data everyone: 読み取り │ ├ ￥Kanri-Data soumu:読み取り、kanri:読み取り │ ├ ￥Soumu-Data soumu:変更 │ └ ￥Keiri-Data kanri:変更 │ └ ￥Kaihatsu-Data dev1:読み取り、dev2:読み取り ├ ￥Dev1-Data dev1:変更 └ ￥Dev2-Data dev2:変更 みたいな感じでしょうかね。
よくある誤解ですが、ネイティブモードのWindows2000/2003 ActiveDirectoryと NTドメインは信頼関係を結べますし、NTドメイン端末やNTメンバマシンは正常動作しますよ。 混在モードを使う理由は唯一、そのドメインにNT BDCが存在するか否かです。 もし不安な場合は、NT BDCを準備した上で、ドメインと同期後、 オフラインにして保管しておいてください。 もし戻したくなった場合、全Windows2000DCをオフラインにした上で強制降格、 NT BDCをオンラインにしてPDCに昇格すればNTドメインに戻せますし、 それをWindows2000へアップグレードすればWindows2000ActiveDirectory混在モードに戻せます。 # 手順が面倒ですが、それ以前にそんな問題が起きることすらほぼありえないですし。 ネストを使うとしたら、 actv-test.co.jp │ ├Stuff (グローバルグループ） ├ Soumu (グローバルグループ）←Stuff(グローバルグループ)に所属 ├ Keiri (グローバルグループ）←Stuff(グローバルグループ)に所属 ├ user-S01（ユーザ）←Soumu(グローバルグループ）に所属 ├ user-S02（ユーザ）←Soumu(グローバルグループ）に所属 ├ user-K01（ユーザ）←Keiri(グローバルグループ）に所属 ├Dev (グローバルグループ） ├ Dev1 (グローバルグループ）←Dev(グローバルグループ)に所属 ├ Dev2 (グローバルグループ）←Dev(グローバルグループ)に所属 ├ user-D01（ユーザ）←Dev1(グローバルグループ）に所属 └ user-D02（ユーザ）←Dev2(グローバルグループ）に所属 のような構成にした上で、 D:￥Zensya-Data everyone: 読み取り │ ├ ￥Kanri-Data stuff:読み取り │ ├ ￥Soumu-Data soumu:変更 │ └ ￥Keiri-Data kanri:変更 │ └ ￥Kaihatsu-Data dev:読み取り ├ ￥Dev1-Data dev1:変更 └ ￥Dev2-Data dev2:変更 なんて感じに。stuffやdevなどの親グループに含まれるグループが頻繁に増えるなら、 こんな感じでネストする利点はあるでしょう。 また、各グループの管理を委任するとか、適用するセキュリティポリシーが違う、 なんて要件がないなら、OUを分ける必要はありません。 [ メッセージ編集済み 編集者: Mattun 編集日時 2004-11-11 07:50 ] [ メッセージ編集済み 編集者: Mattun 編集日時 2004-11-11 07:53 ] | ||||||||||||
|
投稿日時: 2004-11-11 14:56
Mattun様
朝早くから早々のアドバイスありがとうございます。 ネイティブモードについてのご説明は、正に目から鱗の状態で、 運用管理簡素化のために早速モード変更を行いました。 で、早速アクセス権設定のためにご呈示いただいたサンプル状態にて グローバルグループのネスト設定を行いクライアントからのテストを 行ってみました。 ■OU、グローバルグループとユーザの登録状態 actv-test.co.jp │ └ ZensyaUser(OU) ├ Stuff (GG) │ ├ Soumu (GG) │ │ ├ user-S01 (User) │ │ └ user-S02 (User) │ └ Keiri (GG) │ └ user-K01 (User) │ │ └ Dev (GG) ├ Dev1 (GG) │ └ user-D01 (User) │ └ Dev1 (GG) └ user-D02 (User) ■共有フォルダへのアクセス権 D:￥Zensya-Data ← セキュリティ登録＝Soumu(GG)：読み取り、Keiri(GG)：読み取り │ 共有アクセス許可＝Soumu(GG)：変更、 Keiri(GG)：変更 │ 共有名：Share-Data │ ├ ￥Kanri-Data ← Soumu(GG)：読み取り、Keiri(GG)：読み取り │ ├ ￥Soumu-Data ← Soumu(GG)：変更、Keiriは未登録 │ └ ￥Keiri-Data ← Keiri(GG)：変更、Soumuは未登録 │ └ ￥Kaihatsu-Data ← Soumuは未登録 ├ ￥Dev1-Data ← Soumuは未登録 └ ￥Dev1-Data ← Soumuは未登録 上記のような状態でActiveDirectoryよりネットワークドライブの割り当てを行おうとすると ネットワークドライブの割り当て完了ボタン押下直後に 「ネットーワークパス￥￥SRV1￥Share-Dataは見つかりませんでした」 となってしまいます。 そこで共有のアクセス許可、セキュリティ登録の両方を D:￥Zensya-Data ← セキュリティ登録＝Domain Users：変更 共有アクセス許可＝Domain Users：変更 と設定するとドライブの割り当てが可能となりましたが、配下の各フォルダへのアクセスは すべて拒否されてしまいます。 （本来であれば￥Zensya-Dataや￥Kanri-Dataへの設定はStuff(GG)を使用して設定したい ところですが、その前段階でつまずいております。） 当然ですがDomain Usersへは登録した各ユーザはメンバーとして自動登録されていますが、 テストとしてDomain Usersへ登録した全グローバルグループを手動でメンバーとして登録し、 一旦クライアントからuser-S01をログオフ、再度ログオンしてアクセスしてみましたが 結果は同じでした。 現在グループポリシーの設定等は何も操作しておらず、デフォルトのままです。 どこかActiveDirectory内の設定に問題があるのか、もしくはグループポリシー等を設定する 必要があるのでしょうか？ | ||||||||||||
|
投稿日時: 2004-11-11 15:24
まだ斜め読みですが、気づいた点だけ。
共有のアクセス権は、Everyoneフルコントロールにしてください。 セキュリティタブから設定できるNTFSアクセス権だけで十分制御できますから。 | ||||||||||||
|
投稿日時: 2004-11-11 17:52
Mattun 様
できました！ ご指摘の通り共有のアクセス権は、Everyoneフルコントロールにし、 念のため一旦ActiveDirectory内の共有登録を削除、 再度ActiveDirectoryへ登録実行後別の用事にて１５分程度放置した状態と なっていたのですが、その後クライアントからテストましたところ、 思った通りのアクセス制御が可能となりました。 いろいろお手数をおかけいたしまして申し訳ございませんでした。 あと一つだけ運用面での質問になり恐縮なのですが、今回の共有データエリアを毎日 全く別のサーバ（例えばSRV2）にバックアップしているとします。 このバックアップ先のセキュリティ登録や共有アクセス許可等の設定は全く同一で、 ActiveDirectoryへの登録がされていないだけとした場合、SRV1障害発生時に 本来の共有フォルダの代替えとして、ActiveDirectoryに登録されている共有フォルダの プロパティを表示し、UNC名のパスを変更してやるだけでクライアントユーザからは、 全く問題なく使用可能なのでしょうか？ バックアップ先はメンバーサーバーではなくDCでなければならないとか、 設定に関する注意事項等がありましたらお教えください。 よろしくお願いいたします。 | ||||||||||||
|
投稿日時: 2004-11-12 00:17
はい。 実際、そんな運用やってますし、問題なく切り替えできてます。
DCなファイルサーバの代替としてメンバサーバを使うのは何ら問題ありません。 # 逆のケースで、ローカルグループを使ってる場合は問題が発生し得ますが、 # そもそもローカルグループを使ったファイルサーバじゃこんな切り替えは大変です。 あとは、そのSRV2が唯一のバックアップ先だとしたら、構成を見直しましょう。 世代バックアップの取得ができないと、万が一の事故の場合に痛い目にあいます。 ウィルスにファイル全部削除されてしまい、その後複製が発生した場合、なんてのを 考えると、危険なのが分かるかと思います。 そういう意味では、世代バックアップを取るためのバックアップソフト(NTBACKUPでも可)と、 世代バックアップを格納可能な大容量記憶媒体(LTOテープドライブとか)は必要となるでしょう。 あと、いまさらかもしれないんですが、ファイルサーバ用途ならWindows2000Serverより WindowsServer2003の方が有利だと思います。ファイルサーバ向けの機能拡張が 素晴らしいし、セキュリティのレベルも高ければ、安定性も遜色ないor高いです。 もし近いうちにサーバ機を買う予定があるんだったら、WindowsServer2003モデルを購入し、 2003を前提で考えた方がいいでしょう。もし2003で実現できないことがあって 2000へ変更したい場合でも、ダウングレード権を行使すれば2000を導入できますし。 | ||||||||||||
|
投稿日時: 2004-11-12 10:28
了解いたしました。 おかげさまで計画しているとおりの運用管理ができそうでホッとしております。
いろいろ適切なアドバイスをいただきありがとうございます。 仰るとおりバックアップの世代管理は必要と認識しておりまして、 日中のSRV1に対する負荷軽減から深夜にバックアップ先のSRV2へ バックアップを実行し、今度は日中にSRV2のデータをオートローダの DLTへバックアップする運用計画にしております。
そうですか．．．．やはり2003の方が有利なんですね。 実は今回新規でサーバーを導入しているのですが、既存のライセンスを使用して コストを抑える必要があったことと、一部作り込みのシステムでSQLServer6.5が 存在しておりユーザーインターフェース部分の作り替えが必要となってしまう関係から 2000Serverにせざるをえなかったので残念です。 このシステムは来年にSQL2000ベースへ変更する計画となっていますので、 同システムの変更以降、改めてServerOSの変更計画を立案してみます。 いずれにいたしましても、今回は本当にお世話になり大変感謝しております。 ありがとうございました。 | ||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。