none
フォルダアクセス権の複合認証とWSFC RRS feed

  • 質問

  • はじめまして。お世話になります。

    フォルダアクセス権の複合認証とWSFCについてです。
    NTFSアクセス権の「条件の追加」からデバイスの条件を追加し、
    ユーザーアクセス権の複合認証を設定したところ、
    サーバー単体で作成した共有フォルダでは動作しますが、
    フェールオーバークラスターで作成した
    共有フォルダでは期待通りに動作しない現象が発生しました。

    環境は以下の通りです。OSは全てWindows Server 2012 R2です。

    ドメインコントローラー:DC01、DC02
    フェールオーバークラスターノード:FS01、FS02
     クラスタ化されたファイルサーバーの役割で作成した共有フォルダ:\\FS00\共有
    クライアント役のマシン:CL01、CL02

    ・フォレスト、ドメインとも機能レベルは2012 R2
    ・シングルフォレスト、シングルドメイン
    ・上記すべてのコンピューターがドメイン参加済み
    ・Default Domain Controllers Policyの「コンピューターの構成」で以下を設定
     - KDCで信頼性情報、複合認証、およびKerberos防御をサポートする → 有効&サポート
     - 複合認証を要求する → 有効
    ・Default Domain Policyの「コンピューターの構成」で以下を設定
     - Kerberosクライアントで信頼性情報、複合認証、およびKerberos防御をサポートする → 有効
     - 複合認証をサポートする → 有効&常時
     - 常に複合認証を先に送信する → 有効
     (当初はCL01、FS01、FS02向けにOUとグループポリシーを作成して個別で当てていたが、
      期待通りにならなかったのでDefault Domain Policyで設定したが現象変わらず)
    ・「\\FS00\共有」フォルダに以下のアクセス権を設定(フェールオーバークラスターマネージャーから設定)
    共有アクセス権 | Everyone | 変更
    NTFSアクセス権 | 上位からの継承を無効にする
            | SYSTEM | フルコントロール
            | Administrators | フルコントロール
            | CREATOR OWNER | フルコントロール
            | Domain Users | 読み取りと実行
    ・「\\FS00\共有\部長」フォルダに以下のアクセス権を設定
     (フォルダをエクスプローラーで右クリックして、プロパティから設定)
    NTFSアクセス権 | 上位からの継承を無効にする
            | SYSTEM | フルコントロール
            | Administrators | フルコントロール
            | CREATOR OWNER | フルコントロール
            | user01 | 読み取りと実行 ※A
      ※A NTFSアクセス権詳細設定の
      「アクセス許可エントリ」画面下部の「条件の追加」から以下の条件を追加する
      デバイス グループ 次のいずれかに所属する 値 CL01 (表示は「ドメイン名\CL01$」)
    ・全コンピューターで「gpupdate /force」を実行
    ・FS01、FS02については2台同時にOS停止の状態にし、再度起動させた
    ・CL01についてはOS再起動を実施

    この状態で、CL01にuser01でログインして、「\\FS00\共有\部長」にアクセスしても
    「アクセス権がありません」とメッセージが出てはじかれます。
    CL02からでも当然アクセスできません。
    デバイスの条件を削除すると、CL01、CL02どちらからでもuser01でアクセスできます。
    また、デバイスの条件を「次のいずれにも所属しない - CL01」にすると、
    今度はCL01でもCL02でもアクセスできてしまいます。

    サービスチケットが絡んでいるか、と、FS00、FS01、FS02、CL01に当てるグループポリシーの
    Kerberos ポリシーで最長有効期間を短くしたり、
    10時間待ったりしてみましたが、現象は変わりません。

    切り分けのために、FS01、FS02それぞれのCドライブ下に作成したフォルダを共有にし、
    (\\FS01\共有テスト、\\FS02\共有test)
    上と全く同じアクセス権を設定すると、
    今度はCL01にuser01でログインして\\FS01\共有テストへアクセス→アクセス可、
    CL02にuser01でログインしてアクセス→アクセス不可
    と、期待通りの結果になります。


    エクスプローラーからフォルダ右クリック→共有 での共有フォルダ作成と、
    フェールオーバークラスターでの共有フォルダ作成で、
    Kerberos認証の何かに違いが生じるものでしょうか。
    フェールオーバークラスターでのSMB共有は複合認証の対象外?

    何かしら情報がありましたらいただきたく、よろしくお願いいたします。

    2016年7月15日 15:32

回答

  • チャブーンです。

    この件ですが、簡単に検証で確認した限りですが、FCIによる共有フォルダには「デバイス制御による」ダイナミックアクセス制御は、うまく動かないように見受けられます。設定はまったく同じようにできるのですが、おそらく(実サーバとは異なる)異なるクラスタ用の仮想オブジェクト経由でのアクセスが、DACに想定されていないのかもしれません。

    ちなみに、こちらで実施した手順は、簡単にいうとしたのようなものです。一部の掲示板にあるような「DACを使用せずにデバイス制限を使用する」というようなことはしていません。(リクツ的にこれはムリかと思います)

    1. (Active Directory管理センターから)「dNSHostName」に対するClaim Types設定を行う
    2. (今回は使わないので)Resource Properties設定は行わない
    3. 「ターゲットリソース」はなし、「現在のアクセス許可」はAuthenticated Usersに(デバイス。dNSHostName 次のいずれか{"マシン名FQDN1","マシン名FQDN2"})でフルコントロールのようにCentral Access Rules設定を行う
    4. 設定したCentral Access Ruleを含むCentral Access Policies設定を行う
    5. 設定したCentral Access Policyを「集約型アクセスポリシー」に含むGPOをファイルサーバとクライアントのみに適用
    6. [Kerberosクライアントで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをファイルサーバとクライアントのみに適用(うえと同じGPOに設定でよい)
    7. [KDCで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをドメインコントローラのみに適用
    8. ファイルサーバ側の共有フォルダ[セキュリティ]からAuthenticated Usersに(デバイス。dNSHostName 次のいずれか{"マシン名FQDN1","マシン名FQDN2"})でフルコントロールのようにアクセス許可を追加する
    9. ファイルサーバ側の共有フォルダ[セキュリティ]-[詳細設定]-[集約型ポリシー]に設定済みのCentral Access Policyを設定する

    最終的に、FCIによる共有フォルダには「デバイス制御による」ダイナミックアクセス制御ができるのかどうかについて、きちんとした情報はないようですので、どうしても白黒はっきりつけたいということでしたら、MS有償サポートにお尋ねいただくことになると思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2016年7月20日 9:00
    モデレータ
  • チャブーンです。

    この件ですが、「Resource Propertyを使って」デバイスベースでアクセス制御を行う方法を試してみました。したのような方法で試しましたが、結果的にはローカルディスクではうまくいきましたが、FCIでは前回同様うまくいきませんでした。

    1. 事前にファイルサーバに対して「ファイルサーバーリソースマネージャー」をインストールしておく
    2. (Active Directory管理センターから)「dNSHostName」に対するClaim Types設定を行う
    3. 提案された値に「値:マシン名FQFN1/表示名:マシン名1」「値:マシン名FQFN2/表示名:マシン名2」を指定した「R_dNSHostName」という名前で、Resource Properties設定を行う
    4. ターゲットリソースに「リソース。R_dNSHostName 次のいずれか {"マシン名1","マシン名2"}」、「現在のアクセス許可」はAuthenticated Usersに(デバイス。dNSHostName 次の値と等しい リソース。R_dNSHostName)でフルコントロールのようにCentral Access Rules設定を行う
    5. 設定したCentral Access Ruleを含むCentral Access Policies設定を行う
    6. 設定したCentral Access Policyを「集約型アクセスポリシー」に含むGPOをファイルサーバのみに適用
    7. [Kerberosクライアントで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをクライアントのみに適用(うえとは違うGPOになる)
    8. [KDCで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをドメインコントローラのみに適用
    9. ファイルサーバ側の共有フォルダ[セキュリティ]-[詳細設定]-[集約型ポリシー]に設定済みのCentral Access Policyを設定する
    10. ファイルサーバ側の共有フォルダ[分類]から、R_dNSHostNameプロパティの値を"マシン名1"に設定する

    内容から、やはり仮想オブジェクトのファイルサーバに対してのアクセス評価、というところがポイントのように思います。これ以上は、MS有償サポートに聞かないとはっきりわからないと思いますが、内容的にDACの制限事項に該当する可能性がかなり高い、というのが個人的な見解となります。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2016年7月21日 8:09
    モデレータ

すべての返信

  • チャブーンです。

    この件ですが、簡単に検証で確認した限りですが、FCIによる共有フォルダには「デバイス制御による」ダイナミックアクセス制御は、うまく動かないように見受けられます。設定はまったく同じようにできるのですが、おそらく(実サーバとは異なる)異なるクラスタ用の仮想オブジェクト経由でのアクセスが、DACに想定されていないのかもしれません。

    ちなみに、こちらで実施した手順は、簡単にいうとしたのようなものです。一部の掲示板にあるような「DACを使用せずにデバイス制限を使用する」というようなことはしていません。(リクツ的にこれはムリかと思います)

    1. (Active Directory管理センターから)「dNSHostName」に対するClaim Types設定を行う
    2. (今回は使わないので)Resource Properties設定は行わない
    3. 「ターゲットリソース」はなし、「現在のアクセス許可」はAuthenticated Usersに(デバイス。dNSHostName 次のいずれか{"マシン名FQDN1","マシン名FQDN2"})でフルコントロールのようにCentral Access Rules設定を行う
    4. 設定したCentral Access Ruleを含むCentral Access Policies設定を行う
    5. 設定したCentral Access Policyを「集約型アクセスポリシー」に含むGPOをファイルサーバとクライアントのみに適用
    6. [Kerberosクライアントで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをファイルサーバとクライアントのみに適用(うえと同じGPOに設定でよい)
    7. [KDCで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをドメインコントローラのみに適用
    8. ファイルサーバ側の共有フォルダ[セキュリティ]からAuthenticated Usersに(デバイス。dNSHostName 次のいずれか{"マシン名FQDN1","マシン名FQDN2"})でフルコントロールのようにアクセス許可を追加する
    9. ファイルサーバ側の共有フォルダ[セキュリティ]-[詳細設定]-[集約型ポリシー]に設定済みのCentral Access Policyを設定する

    最終的に、FCIによる共有フォルダには「デバイス制御による」ダイナミックアクセス制御ができるのかどうかについて、きちんとした情報はないようですので、どうしても白黒はっきりつけたいということでしたら、MS有償サポートにお尋ねいただくことになると思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2016年7月20日 9:00
    モデレータ
  • チャブーン様

    お世話になっております。
    ご返信、またお時間を割いて検証までしていただき、
    真にありがとうございます。

    そうですか・・・
    FCIによる共有フォルダではDACのデバイス制御でもうまく動かないようですね。
    きちんとした情報も、自分も探したのですがやはりないようですね。

    MS有償サポートの使用、別の方法への切り替え含め、検討します。
    検討の結論がある程度出ましたら、「回答としてマーク」などの
    クローズをさせていただきます。

    ありがとうございました。
    2016年7月20日 11:10
  • チャブーンです。

    この件ですが、確かめの意味で、「ユーザの属性設定」でのアクセス許可について、以下の方法で試したところ、FCIでもきちんとできるようです。

    https://blogs.technet.microsoft.com/canitpro/2013/05/06/step-by-step-protecting-your-information-with-dynamic-access-control/

    つまり、FCIについてはちゃんとサポートはされているようですが、デバイスの属性設定について、確かめがいるかもしれませんね。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2016年7月21日 4:42
    モデレータ
  • チャブーンです。

    この件ですが、「Resource Propertyを使って」デバイスベースでアクセス制御を行う方法を試してみました。したのような方法で試しましたが、結果的にはローカルディスクではうまくいきましたが、FCIでは前回同様うまくいきませんでした。

    1. 事前にファイルサーバに対して「ファイルサーバーリソースマネージャー」をインストールしておく
    2. (Active Directory管理センターから)「dNSHostName」に対するClaim Types設定を行う
    3. 提案された値に「値:マシン名FQFN1/表示名:マシン名1」「値:マシン名FQFN2/表示名:マシン名2」を指定した「R_dNSHostName」という名前で、Resource Properties設定を行う
    4. ターゲットリソースに「リソース。R_dNSHostName 次のいずれか {"マシン名1","マシン名2"}」、「現在のアクセス許可」はAuthenticated Usersに(デバイス。dNSHostName 次の値と等しい リソース。R_dNSHostName)でフルコントロールのようにCentral Access Rules設定を行う
    5. 設定したCentral Access Ruleを含むCentral Access Policies設定を行う
    6. 設定したCentral Access Policyを「集約型アクセスポリシー」に含むGPOをファイルサーバのみに適用
    7. [Kerberosクライアントで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをクライアントのみに適用(うえとは違うGPOになる)
    8. [KDCで信頼性情報、複合情報、およびKerberos防御をサポートする]を有効とするGPOをドメインコントローラのみに適用
    9. ファイルサーバ側の共有フォルダ[セキュリティ]-[詳細設定]-[集約型ポリシー]に設定済みのCentral Access Policyを設定する
    10. ファイルサーバ側の共有フォルダ[分類]から、R_dNSHostNameプロパティの値を"マシン名1"に設定する

    内容から、やはり仮想オブジェクトのファイルサーバに対してのアクセス評価、というところがポイントのように思います。これ以上は、MS有償サポートに聞かないとはっきりわからないと思いますが、内容的にDACの制限事項に該当する可能性がかなり高い、というのが個人的な見解となります。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2016年7月21日 8:09
    モデレータ
  • チャブーン様 追加調査いただきありがとうございます。その後有償サポートを検討しつつ、一方でいただいた検証の内容を再現させて確認したり、 iisのkerberos認証をヒントにSPNなどの観点からも調べたりしましたが結局解決せず、 MSの有償サポートを使うことにしました。 貴重なお時間割いていただき、ありがとうございました。
    2016年7月27日 0:05