NT AUTHORITY\NETWORKSERVICEアカウントの読み取り権限を持つローカルファイル共有をクロールしています。
匿名アクセスを有効にしましたが、認証なしで検索ボックスにアクセスできるようになりました。しかし、実際に何かを検索しても、結果は返されません。管理者アカウントを使用すると結果を得ることができます。
ACL権限を変更してインデックスを再作成すると、ローカルユーザーが検索結果にアクセスできるようになりますが、最終的な目標は、匿名ユーザーが結果を表示できるようにすることです。
あなたが見ているのは実際に私が期待するものです。つまり、検索サーバーはインデックスファイルのACLに関して検索を実行するユーザーの資格情報に挑戦し、ユーザーがファイル自体に関する適切な読み取り権限を持っている場合にのみアクセスを許可します(つまり、検索インターフェースのみ)、例を参照してください インデックス作成のセキュリティに関する考慮事項 、セクションアイテムレベルのセキュリティについて:
ソースコンテンツがクロールされてインデックスが作成されると、承認情報が各アイテムの管理プロパティ(アイテムのACL、またはアクセス制御リスト)に追加され、アイテムへのアクセスが許可または拒否されたユーザーとグループが識別されます。アイテムACLは、各アイテムにアクセス許可をタグ付けすることにより、アイテムレベルのセキュリティを設定するのに役立ちます。
ユーザーがクエリを送信し、インデックスが検索結果を見つけると、クエリ処理サービスはユーザーのクエリを書き換えて、ユーザーが表示を許可されているアイテムのみを表示するようにします。このセキュリティトリミング[...]
あなたの例は、問題のファイルがNT AUTHORITY\NETWORK SERVICE
によってのみ読み取れることを示唆しているようです。したがって、検索インデックスを介してこれらのファイルのコンテンツを表示すると、回避されます。そもそもアクセス制限が意識的に適用されており、そうしないことは少なくとも賢明なデフォルトのように思われます(実際に唯一のオプションではないにしても)。
したがって、1つまたは(おそらく)2つの手段で目的の結果を達成できるはずです。
匿名ユーザー(またはより簡単で安全な開始のためのローカルテストアカウント)に、標準のWindowsACL管理を介してファイル自体へのアクセスを許可します。クエリ結果でACLの変更を表示するには、コンテンツのインデックスを再作成する必要がある可能性があることに注意してください。上記の引用を参照してください。
最終的にSearch Serverでは、インデックス付きファイルセットのACLを明示的にオーバーライドまたは無視できます-ただし、このオプションについてはわかりません(ただし、あまり馴染みがありません)検索サーバーでも)。
幸運を!