web-dev-qa-db-ja.com

リモート共有フォルダーのセキュリティ権限

Windows Server 2003を実行しているサーバーが2つあり、一方のサーバー（A）から、ローカルシステムアカウントで実行されているWindowsサービスを使用してプログラムでもう一方のサーバー（B）にファイルをコピーしたいと考えています。 「アクセスが拒否されました」というエラーが引き続き表示され、共有フォルダーを書き込み用に開くために設定する必要のあるセキュリティ設定がわかりません。

これは私が受信側で行ったことです：

  1. Aで、共有するフォルダを右クリックし、[共有]タブを選択して、[このフォルダを共有する]を選択します。共有名を設定します。
  2. 「権限」をクリックし、グループ「全員」を追加して、完全に制御できるようにします。

[セキュリティ]タブを選択していくつかのアクセス許可を付与しようとしましたが、[ワークグループコンピューター]ダイアログにBが表示されているにもかかわらず、[追加]ダイアログではローカルユーザーしか見つかりません。さらに詳しく調べてみると、これは[共有]タブの[権限]ダイアログにも当てはまります（同じですか？）。

更新：さらに調査したところ、サーバーAのプログラムがSYSTEMアカウントで実行されていることがわかりました。このプログラムが行う他のことを壊すリスクがあるため、これは私があえて変更するものではありません（TeamCity CIサーバー上のビルドエージェントです）。

したがって、ワークグループ環境で、A\SYSTEMにBの共有フォルダーに書き込むためのアクセス権を与える方法が必要です。

更新2：構成に次の変更を加えることができるようになりました。

  • TeamCityという名前のユーザーアカウントが各サーバーにあります。それらは同じパスワードを持ち、両方ともそれぞれのAdministratorsグループの一部です（同じ情報を使用して両方のサーバーにリモートデスクトップ経由でログオンすることで確認しました）。
  • TeamCity（具体的には\\ B\TeamCity）は、Bの共有フォルダーへのフルコントロールアクセス権を持っています。
  • Aのビルドエージェントは、\\ A\TeamCityアカウントで実行されます。

今回ファイルをコピーしようとすると、次のようなエラーが発生します

パスの一部が見つかりませんでした '\\ B\Shared.Folder.Name'

リモートデスクトップ経由でTeamCityアカウントにログオンすると、エラーメッセージからパスをコピーして、Windowsエクスプローラーのアドレスバーに貼り付けることができます。エクスプローラーは、Bの共有フォルダーに移動します。

windows-server-2003securityfile-sharing
1
Tomas Aschan
  1. ワークグループにはユーザーの中央リポジトリがないため、各ワークステーション（またはこの場合はサーバー）でアカウントを手動で複製する必要があります。
  2. ワークグループでは、LocalSystemは匿名としてネットワークにアクセスします。

別のアカウントとしてサービスを実行する必要があります。両方のマシンで同じ名前/パスワードのアカウントを作成し、サービスアカウントに共有アクセス許可を付与し、LocalSystemではなくそのようにサービスを実行するように設定します。start> run：services.mscサービスを右クリックして、プロパティに移動します。ログオンを、作成したユーザーアカウントに変更します。

それが機能しない場合は、匿名からの書き込みを受け入れるように受信フォルダーを構成できますが、読み取り/実行はできません。これにより、フォルダがドロップボックスのように機能します。

「セキュリティ」と「共有」のアクセス許可についての質問に答えるために、それらは同じではありません。セキュリティはNTFSアクセス許可です...それはファイルシステムにアクセスするためのアクセス許可です。共有アクセス許可は、ネットワークを介してそのリソースにアクセスするためのアクセス許可です。 2つの勝利の中で最も制限が厳しいため、セキュリティ設定で[Everyone]を[フルコントロール]に設定し、[共有]で[Everyone]を[読み取り専用]に設定すると、ローカルでリソースにアクセスした場合はフルコントロールが取得されますが、別のコンピューター。

4
Daniel B.

ローカルシステムアカウントには、ネットワークリソースにアクセスする権限がありません。適切な資格情報を使用して接続を確立できるプロセスを実行するか、別のアカウントでサービスを実行する必要があります。別のアカウントでは、リモートリソースにアクセスするために適切な資格情報を使用する必要があります。

1
John Gardeniers

あなたはおそらくドメインにいます。もしそうなら、ドメインアカウントを使用することをお勧めします。すでに述べたように、パススルー認証は可能ですが、これはワークグループのみを対象としています。または、ドメイン管理者が提供する内容が本当に制限されている場合（ただし、ネットワーク管理者が行うことをしていることを示唆しています） tサポート）。

ドメインに参加しているかどうかを確認する方法は次のとおりです。

  • 開始をクリックします。 マイコンピュータを右クリックし、プロパティをクリックします
  • コンピューター名タブをクリックします
  • この画面からはわかりますが、変更をクリックしてください
  • のメンバーがドメインまたはワークグループであるかどうかを確認します。

ワークグループの場合は、すでに説明したパススルー認証を使用します。 （両方のマシンでまったく同じユーザー名/パスワード）

ただし、ドメイン内にある場合は、ここで使用できるサービスアカウントをドメイン管理者に依頼することをお勧めします。パスワードを変更するとサービスが中断するため、自分のアカウントを使用しないでください。

[追加]ダイアログボックスには、場所...ボタンがあります。それをクリックして、ドメインが選択されていることを確認します（ドメインパスをたどる場合）。これにより、ドメインユーザーにアクセスできるようになります。

いずれの場合も（ワークグループまたはドメイン）、使用しているAのサービスアカウントを更新して、ローカルシステムを使用するのではなく、そのアカウントを使用するようにします。

新しいアカウントに、[共有]および[セキュリティ]タブに必要なアクセス許可（NTFSアクセス許可）のみを付与します。共有またはNTFSのいずれかへのアクセスをEveryoneに許可しません。これにより、ドメイン上のすべてのユーザーがコンピューターを使用できるようになります。

注：Everyoneグループを使用してテストし、テスト中に問題としてアクセス許可を削除しても問題ない場合もありますが、最終的な構成は必ず厳しくしてください。それは一時的なものでなければなりません。

更新：コメントでの議論に基づいて、これは私の作業構成に基づくTeamCity構成の例です。

<property name="source.root" value="D:\svn\trunk\admin"/>
<property name="staging.directory" value="\\B\Shared.Folder.Name"/>
<property name="directory.to.upload" value="${source.root}\ControlPanel"/>

<target name="network.deploy">
<echo message="-------- NETWORK.DEPLOY ---------------"/>
    <copy todir="${staging.directory}" verbose="true">
        <fileset basedir="${directory.to.upload}">
            <include name="**/*"/>
            <exclude name="**/*.vb"/>
        </fileset>
    </copy>
</target>
1
Scott Forsyth - MVP

各システムで同じローカルユーザーを作成することで、これを実行できるはずです。まったく同じユーザー名、まったく同じパスワード。次に、それらの資格情報を使用してサービスを実行します。また、NTFS ACLをそのまま設定し、各システムアクセスと共有アクセス許可でローカルアカウントを付与します。

0
Tatas