異なるフォレスト間におけるリソースのアクセス許可設定|試験問題作成委員会の独り言 忍者ブログ

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

異なるフォレスト間におけるリソースのアクセス許可設定

(質問)
異なるフォレスト間におけるリソースのアクセス許可設定について

 
異なるフォレスト間(フォレストA、フォレストB)において双方向の信頼関係を結びました。
フォレストAには、Aドメインのみ 、フォレストBには、Bドメインのみ存在しています。
フォレストAにあるリソース(ファイルサーバー)にアクセスさせるために、フォレストBのユーザーをフォレストAのグループに登録する方法についてご教授いただきたく存じます。
詳細について申しますと、フォレストAにあるグループ(ユニバーサルグループ、グローバルグループ)にフォレストBのユーザーを追加したいと考えております。フォレストA側の「Active Directory ユーザーとコンピュータ」において既存のグループ(ユニバーサルグループ、グローバルグループ)にフォレストBのユーザーを追加したいのですが、グループのプロパティのメンバータブ追加を押した際に、「ユーザー、連絡先、コンピュータまたはグループの選択」の場所においてフォレストBが表示されず、フォレストBのユーザーを追加できません。追加する方法についてご教授ください。
不足している情報等があればご指摘いただけると大変助かります。
宜しくお願い致します。
 
(回答)
グローバルグループには、同一ドメイン内のユーザーやグローバルグループを参加させることができます。
ユニバーサルグループには、同一フォレスト内のユーザーやグローバルグループ、ユニバーサルグループを参加させることができます。
どちらのグループも他のフォレストにあるユーザーやグループを参加させることはできません。
フォレスト A にある ユニバーサル or グローバルグループのメンバー追加画面で フォレスト B が表示されないのはそのためです。
ドメインローカルグループであれば、他のフォレストに存在するユーザーやユニバーサル or グローバルグループをメンバーに加えることができますので、
A ドメインにドメインローカルグループを作成して、そこにフォレスト B 内のユーザーやグループを追加してやれば良さそうです。

(MSのページ)
グループのスコープ 
(参考資料)
AGUDLPポリシー
http://ascii.jp/elem/000/000/505/505060/index-2.html

http://social.technet.microsoft.com/Forums/ja-JP/activedirectoryja/thread/7c9a9028-bba1-45f7-a80b-57b10e35988e

拍手[0回]

(質問)
ドメイン環境でのフォルダの共有設定

 
よろしくお願いします。環境はWindows2008R2です。
Active Direcotryドメインを社内に構成しています。
ドメイン名は「TERA」とします。
先日社内にファイルサーバを1台増設しました。
サーバ名は「FS01」とし、ADドメイン「TERA」に参加しました。
・・
次にファイルサーバ「FS01」に共有フォルダを作成しています。
仮に共有名を「Share」とします。
Shareにアクセス可能なアカウントを整理していますが、直接ADドメインアカウントを1つずつ指定するのではなく、FS01に先ずローカルグループを作成し、それにADドメインアカウントを含めたうえで、そのローカルグループに権限を与えようと考えています。
 
例)
FS01のローカルグループ名:LOCALGROUP01
同グループに含めるアカウント:
 TERA\taro.yamada
 TERA\hanako.sato
 TERA\tomato.yamada
Shareの共有権限:LOCALGROUP01に対し「フルコントロール」を付与
・・
上記までを設定し、別のADドメインに入っている端末に「taro.yamada」ドメインアカウントでログインし、
スタートメニューの「ファイル名を実行」で「\\FS01\Share」にアクセスしました。
しかし「\\FS01\Share」にアクセス許可がありません。管理者にアクセス権を要求して下さい。
と表示されフォルダ内にアクセスができません。
・・
尚、「Share」の共有権限をローカルグループでは無く、「TERA\taro.yamada」などADドメインアカウントを直接指定して、同様に「フルコントロール」を付与すると、今度は正常にフォルダにアクセスできました。
・・
要望としては、当初実施したように、FS01のローカルグループに先ずドメインアカウントを集め、グループ単位での共有権限の付与としたいのですが、上記のエラーとなる原因がわかりません。設定の経緯は正しいでしょうか・・?。
原因などアドバイスを頂けると助かります。
 
(回答)
ローカルグループではなく、ドメインローカルグループで作成してみてはいかがでしょうか?
ドメインでアクセス権の設計をする際は、シングルドメインなら「A-G-DL-P」が基本になりますので・・・
・Aはアカウント
・Gはグローバルグループ
・DLはドメインローカルグループ
・Pはパーミッション
になります。
以上、参考になれば幸いです。
 
http://social.technet.microsoft.com/Forums/ja-JP/activedirectoryja/thread/55a7830b-83f8-42fc-9ceb-cc7e3bc30705/#9c670dd4-7b06-4a24-99b9-9afa572c6a17

----------------------------
(回答のフィードバック)

信頼関係を結んだフォレスト環境でのユーザ参照について
 
現在、グループ会社とのネットワーク接続を実施しています。その中で信頼関係を結びフォレスト構成を構築し、DNSの条件付きフォワーダ設定も完了しています。

・AAA.localドメイン
ADサーバ:Windows Server 2008 R2:機能レベル2003で構成
メンバーサーバ:Windows Server 2008 R2
クライアント:Windows 7 Enterprise
・BBB.localドメイン AD:Windows Server 2003R2:機能レベル2003で構成
メンバーサーバ:Windows Server 2008 R2 and Windows Server 2003 R2
クライアント :Windows 7 Professional

各サーバ上でアクセス権の設定を行う際、両ドメインのADサーバではお互いのユーザが参照できるのですが、各メンバーサーバからはお互いのドメインユーザを参照できません。共用のファイルサーバを構築しようとしているのですがユーザーを検索をしても『サーバーは使用可能ではありません』と表示されるだけです。

AAA.localドメイン
ADサーバ・・・・・・参照可能
メンバーサーバ・・・参照できず←これが今回の問題になっている箇所です。
BBB.localドメイン
ADサーバ・・・・・・参照可能
メンバーサーバ・・・未確認

インターネットを検索しても該当現象を見つけられず困っています。
申し訳ございませんが、お知恵を拝借したいと思いますのでよろしくお願い致します。
色々調べた結果、メンバーサーバから違うドメインのユーザー情報は見れないようですね。
ただ、グローバルグループには、同一ドメイン内のユーザーやグローバルグループをユニバーサルグループには、同一フォレスト内のユーザーやグローバルグループ、ユニバーサルグループを参加させることができるが、どちらのグループも他のフォレストにあるユーザーやグループを参加させることはできないようですね。なので、A にある ユニバーサル or グローバルグループのメンバー追加画面で フォレストB が表示されないのはそのためのようです。
ドメインローカルグループであれば、他のフォレストに存在するユーザーやユニバーサル or グローバルグループをメンバーに加えることができますので、A ドメインにドメインローカルグループを作成して、そこにフォレスト B 内のユーザーやグループを追加してやれば対応できそうなのでこれで対応しようと思います。
ありがとうございました。
 
(コメント)
○○○○です。
回答のフィードバックをいただき、ありがとうございます。結論として、正しい対応です。作法についてはMSにも資料がありますね。
http://technet.microsoft.com/ja-jp/library/cc772808(v=ws.10).aspx
----
別のフォレストにあるユーザーからアクセスする必要のあるリソースへのアクセス許可を割り当てるには、すべてのドメインでリソースベースのドメイン ローカル グループを作成し、これらのグループを使用して、そのドメイン内のリソースに対するアクセス許可を割り当てます。たとえば、ForestB で、OrderEntryApp というドメイン ローカル グループを作成します。このグループを、受注入力アプリケーションへのアクセスを許可するアクセス制御リスト (ACL) に追加して、適切なアクセス許可を割り当てます。
----

(過去ログ)
http://social.technet.microsoft.com/Forums/ja-JP/activedirectoryja/thread/738dbae4-987b-49d6-a81e-d8e29fb5696a
(うえを一部抜粋)
----
外していたら申し訳ないのですが、
XPクライアントが、Sever 2008(Server 2008 R2)ドメインに参加した場合、
netshコマンドでWindows firewallのプロファイルをみたところ、「STANDARD Profile」になっている。(Server 2003 R2メンバー、Vistaの場合はDOMAIN Profileになっている。)
(netshコマンドWindows firewallのプロファイルを調べる方法についてはしたの@ITの資料参照。)
http://www.atmarkit.co.jp/fwin2k/win2ktips/895fwprof/fwprof.html
 
XPクライアントの「共有フォルダのアクセス許可」に信頼先ドメインのアカウントを指定すると、そのアカウント情報を取得する際、信頼先のドメインコントローラから直接情報を取得できない。(Server 2003 R2メンバー、Vistaの場合は信頼先のドメインコントローラから直接情報を取得できる。) 「共有フォルダのアクセス許可」を設定する際に信頼先ドメインの山が見えなければ、「[信頼先ドメインのユーザーまたはグループ名]@[信頼先ドメイン名](xxx.co.jp[など])」 と直接オブジェクト名を指定すれば信頼先ドメインのアカウントにアクセス許可を与えることはできますが。
XPクライアントが、Sever 2003 R2ドメインに参加した(信頼先もSever 2003 R2ドメインの)時は、Windows firewallのプロファイルが「DOMAIN Profile」になっていたことは記憶にあり、この問題はなかったのですが。
したのMSブログにあるようですが・・・。
http://blogs.technet.com/b/jpntsblog/archive/2009/07/01/windows-windows-xp.aspx
MSの回答または識者よりの回答を待ってみられるのが良いように思います。 
----
 http://social.technet.microsoft.com/Forums/ja-JP/activedirectoryja/thread/fc2da408-a150-44a8-8c15-36106274a60c/#84818618-3e56-400e-8029-32c9b856af45


----------------------------
(質問)
信頼関係とセキュリティの設定について教えてください。


信頼関係を結ぶと別ドメインや別フォレストのリソースが利用可能になるとききましたが、
あくまで信頼関係を結んだ先のドメインやフォレストのグループアカウントに使用したいリソースへのアクセス権を設定してそのグループのメンバーになればリソースが利用可能になるということでしょうか?
AD FSとの違いが気になりまして。
初歩的なことですが、教えてください。
よろしくおねがいいたします。
 
(回答)
××××です
おっしゃる通り、信頼関係を結ぶことにより認証が通るということです。ですので適切なアクセス権がないと当然のことながらアクセスできません。
ただし、フォレストの信頼で、認証の選択をした場合は各サーバー毎に認証の権限を付与しないと認証自体が通りません。
AD FSは自分の組織での認証を行うことにより、リソースパートナーに設置してあるWebを使用することができるものです。
 
(補足)
○○○○です。
××××さんの回答に補足します。
信頼関係とフェデレーションの違いは、どのドメインの認証機関(ドメインコントローラ)が認証の責任を持つか(トークンを発行するか) なのかなと思います。
Windows のドメイン認証では、まずコンピュータとドメインコントローラ間で「セキュアチャネル」という暗号化セッションを構築して、その前提でユーザのログオン認証が行われます。信頼関係では、信頼のある相手ドメインのドメインコントローラに対して(本来は確立できない)セキュアチャネルを確立することで、相手ドメインのドメインコントローラへドメイン認証を可能にしますが、最終的に認証するのはあくまで相手側ドメインのドメインコントローラです。
フェデレーションサービスは、トークンと呼ばれる認証情報を自分のドメインで取得し、そのトークンがあれば(認証が行われていると理解して)アクセスが可能な別組織のWebサーバ(リソース)にアクセスするしくみを用意することで、「Webサーバ(リソース)は他組織に用意してもらい、認証システム(Active Directory)は自前で用意する」といったソリューションを提供するものです。
こうすることで、リソースは外注でお願いすることで使い勝手や費用面を向上させ、認証システムは自前で用意することでセキュリティ要件を高める、といったメリットがあります。まあこれは ADFS 1.0 の世界観ですけれど。
 
http://social.technet.microsoft.com/Forums/ja-JP/activedirectoryja/thread/66953b85-eee4-41d2-9b98-07cd0763167e
PR

コメント

お名前
タイトル
文字色
メールアドレス
URL
コメント
パスワード Vodafone絵文字 i-mode絵文字 Ezweb絵文字

トラックバック

プロフィール

HN:
試験問題作成委員会
性別:
男性

カレンダー

04 2024/05 06
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

カウンター

最新コメント

[10/17 バーバリー]
[07/25 NONAME]
[05/18 試験問題作成委員会]
[05/18 通りすがりん]
[05/18 試験問題作成委員会]
[05/18 通りすがりん]
[05/16 通りすがりん]
[05/14 通りすがりん]
[05/13 試験問題作成委員会]
[05/13 通りすがりん]

最新トラックバック

ブログ内検索

忍者画像RSS

忍者AdMax

フリーエリア