none
ActiveDirectory連携した「ファイルサーバー」認証について RRS feed

  • 質問

  • ◎サーバー環境
    Windows Server 2016 Standard

    件名についてご質問です。以下条件の場合で「認証機能は有効なのか」「問題点は何があるのか」ご教授お願いします。

    ◎条件

    ・1PCを「複数人」利用
    ・複数人が1ユーザーを利用する「専用ユーザー」を作成 →ログオン (電子証明の関係で)
    ・「専用ユーザー」ログオン中に共有フォルダ利用するシーン有り
    ・共有フォルダにはAD連携したユーザーが設定されている (専用ユーザーではなく、各個人)

    ◎イメージ
    「専用ユーザー」でログオンした時で、共有フォルダを利用する場合は「ADユーザーで認証」してオープン可能にする
    上記を行うことで「ADユーザーのログ」が取得可能になる
    2019年8月19日 9:06

回答

  • チャブーンです。

    イメージは「「専用ユーザー」をドメインコントローラに作成、ファイルサーバーの共有フォルダには「専用ユーザー」は設定せず、アクセス時は個人ユーザーで認証させる。」

    残念ながらできません。デスクトップログオン時にドメイン認証した場合、デスクトップは「(該当する)ドメインユーザーの権限」で動作します。共有フォルダーへのアクセスも、そのユーザーで透過的に行われますので、これを遮断することはできません。どうしてもということであれば、デスクトップログオン後に「ネットワークドライブ」を異なるユーザー権限で設定するしかありませんが、1つのデスクトップ上で2つ以上の異なるユーザー権限を(ネットワークドライブであっても)同時に設定する、というようなこともできません(それ以前に監査の問題で意味がないと思います)。

    ワークグループのローカルアカウントの場合、(条件を満たせば)透過的な認証は発生しないので、見た目上は可能だと思います。

    電子証明書がユーザー毎での利用となっており利用人全てに発行すると莫大なコストが発生するので、「現状難しい」という判断になっています。

    一応コメントしますが、ドメインアカウントに「ユーザー証明書」をインポートした場合、ふつうは「インポートを直接行った端末」以外の端末では、証明書は使えません。細かい説明は省きますが、証明書情報は「ユーザープロファイル」内に格納されるので、端末間同士でユーザープロファイルはそれぞれ別になるためです。

    これは第三者機関から「出来ない」と回答がありましたが....技術的に可能なのでしょうか?

    これは厳密には、要件次第です。クライアント端末から証明書の発行要求(CSR)を行うやり方であれば、「秘密鍵」と呼ばれる証明書の一部がエクスポートできないため、流用は不可能です。ですが、証明書がバイナリ形式で「ファイルとして入手」している場合、.pfxファイルのようなものであれば、秘密鍵も含んでいるので、複数のユーザーに同時利用させることが技術的には可能です。


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

    2019年8月22日 7:58
    モデレータ

すべての返信

  • チャブーンです。

    この件ですが、よくわからない点がありますが、ドメインコントローラーにファイルサーバーも兼ねさせる、という前提でしょうか?そうであるならですが、「専用ユーザー」がクライアントの「ローカルアカウント」を指しているのであれば、技術的には可能です。

    この場合ですが、「ローカルアカウント」のアカウント名が、Active Directoryドメインアカウントの「どのユーザー名とも一致しない」ことが必要です。この条件が満たされれば、アクセスすると「認証ダイアログ」が表示され、アカウントとパスワードを要求されます。アカウント名が一致してしまった場合、ドメインのそのユーザー名でパススルー認証が行われますので、認証が通るか、あるいは拒否されるかのどちらになります。「ADユーザーのログ」が何を指しているかは分かりませんが、セキュリティログや監査ログは記録されると思います。

    Active Directoryの主要目的は、オフィス環境でのSSO実現なので、これをムリに使わない、という場合、利便性とセキュリティ面で大きい問題が出ると思います。専用ユーザー利用中の誰かが、資格情報マネージャーの「Windows資格情報」で自分のドメインアカウントを保存した場合、他のユーザーもそれがそのまま使えてしまうので、ユーザーの監査という点での信ぴょう性は大きく下がるでしょう。また記録を禁止していても、(アカウント名とパスワードを入力した際の)「資格情報のキャッシュ」は物理メモリー上に残るため、利用後必ずログオフをしないと、他の利用者がそのキャッシュをそのまま使えてしまい(というか自分のアカウントが使えなくなります)、これも監査の観点では問題です。

    電子署名といっているのはおそらく第三者機関の「ユーザー証明書」だと思うので、Active Directoryユーザーに対して、ユーザー証明書のインポートを行えば解決するかと思います。同じ(第三者機関の)ユーザー証明書を複数のユーザーにインポートしても、Active Directoryの認証には、とくに影響はありません。


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


    2019年8月19日 10:20
    モデレータ
  • チャブーンさん
    ご返信ありがとうございます。


    三島コーポレーション カトウです。
    わかりにくい部分があり申し訳ございません。
    以下返信致します。よろしくお願い致します。

    ------------
    >ドメインコントローラーにファイルサーバーも兼ねさせる、という前提でしょうか?
    ドメインコントローラとファイルサーバーは「分離」します。ファイルサーバーはドメイン参加前提です。

    >「専用ユーザー」がクライアントの「ローカルアカウント」を指しているのであれば、技術的には可能です。
    イメージは「「専用ユーザー」をドメインコントローラに作成、ファイルサーバーの共有フォルダには「専用ユーザー」は設定せず、アクセス時は個人ユーザーで認証させる。」
    でしたが、これは「ローカルユーザーでないと」実現が難しいということでしょうか。
    (ローカルユーザーでも運用上問題ないが、ユーザー管理を一括集中したい目論見があるので...)

    >「ADユーザーのログ」が何を指しているかは分かりませんが、セキュリティログや監査ログは記録されると思います。
    「セキュリティログや監査ログ」のことを指しています。わかりにくく申し訳無いです。

    >Active Directoryの主要目的は、オフィス環境でのSSO実現なので、これをムリに使わない、という場合、
    >利便性とセキュリティ面で大きい問題が出ると思います。専用ユーザー利用中の誰かが、資格情報マネージャーの「Windows資格情報」で自分のドメインアカウントを保存した場合、
    >他のユーザーもそれがそのまま使えてしまうので、ユーザーの監査という点での信ぴょう性は大きく下がるでしょう。
    >また記録を禁止していても、(アカウント名とパスワードを入力した際の)「資格情報のキャッシュ」は物理メモリー上に残るため、
    >利用後必ずログオフをしないと、他の利用者がそのキャッシュをそのまま使えてしまい(というか自分のアカウントが使えなくなります)、これも監査の観点では問題です。
    上記が今回のパターン、一番のデメリットですね。
    本当はドメインコントローラに利用人毎に「ユーザー作成」を行うのが理想ですが、電子証明書がユーザー毎での利用となっており
    利用人全てに発行すると莫大なコストが発生するので、「現状難しい」という判断になっています。

    なので、上記デメリットを「ルール」でコントロールする...というのが現実的と考えています。

    >電子署名といっているのはおそらく第三者機関の「ユーザー証明書」だと思うので、Active Directoryユーザーに対して、ユーザー証明書のインポートを行えば解決するかと思います。
    >同じ(第三者機関の)ユーザー証明書を複数のユーザーにインポートしても、Active Directoryの認証には、とくに影響はありません。
    これは第三者機関から「出来ない」と回答がありましたが....技術的に可能なのでしょうか?

    2019年8月22日 2:08
  • 最後の証明書の所ですが、証明書の発行者が証明書のエクスポート/インポートをできない設定にして表明書を発行することが可能です。「できない」という回答があることから、そのような設定の証明書なのでしょう。その場合は技術的にも不可能です。


    Hebikuzure aka Murachi Akira

    2019年8月22日 2:45
  • 最後の証明書の所ですが、証明書の発行者が証明書のエクスポート/インポートをできない設定にして表明書を発行することが可能です。「できない」という回答があることから、そのような設定の証明書なのでしょう。その場合は技術的にも不可能です。


    Hebikuzure aka Murachi Akira

    ご回答ありがとうございます。
    発行元のさじ加減なのですね...明確に「インポート出来ない」と回答されているので
    技術的に不可能にしているのでしょうね。

    上記に関しては特に問題視はしていないのでスルーしています。
    2019年8月22日 5:59
  • チャブーンです。

    イメージは「「専用ユーザー」をドメインコントローラに作成、ファイルサーバーの共有フォルダには「専用ユーザー」は設定せず、アクセス時は個人ユーザーで認証させる。」

    残念ながらできません。デスクトップログオン時にドメイン認証した場合、デスクトップは「(該当する)ドメインユーザーの権限」で動作します。共有フォルダーへのアクセスも、そのユーザーで透過的に行われますので、これを遮断することはできません。どうしてもということであれば、デスクトップログオン後に「ネットワークドライブ」を異なるユーザー権限で設定するしかありませんが、1つのデスクトップ上で2つ以上の異なるユーザー権限を(ネットワークドライブであっても)同時に設定する、というようなこともできません(それ以前に監査の問題で意味がないと思います)。

    ワークグループのローカルアカウントの場合、(条件を満たせば)透過的な認証は発生しないので、見た目上は可能だと思います。

    電子証明書がユーザー毎での利用となっており利用人全てに発行すると莫大なコストが発生するので、「現状難しい」という判断になっています。

    一応コメントしますが、ドメインアカウントに「ユーザー証明書」をインポートした場合、ふつうは「インポートを直接行った端末」以外の端末では、証明書は使えません。細かい説明は省きますが、証明書情報は「ユーザープロファイル」内に格納されるので、端末間同士でユーザープロファイルはそれぞれ別になるためです。

    これは第三者機関から「出来ない」と回答がありましたが....技術的に可能なのでしょうか?

    これは厳密には、要件次第です。クライアント端末から証明書の発行要求(CSR)を行うやり方であれば、「秘密鍵」と呼ばれる証明書の一部がエクスポートできないため、流用は不可能です。ですが、証明書がバイナリ形式で「ファイルとして入手」している場合、.pfxファイルのようなものであれば、秘密鍵も含んでいるので、複数のユーザーに同時利用させることが技術的には可能です。


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

    2019年8月22日 7:58
    モデレータ
  • チャブーンさん

    ご回答ありがとうございます。

    的確な情報で非常に参考にさせて頂きました。

    いただいた情報を元にポリシーを作成させて頂きます。

    ありがとうございました。

    2019年8月23日 10:04