[Windows Server 2008 R2 SP1、2013年3月15日現在の最新の修正プログラム]。 Domain1に「IT」というセキュリティグループがあります。 Domain2にserver2があります。 Domain1からDomain2への一方向の信頼があります。 Domain1のITグループがアクセスできるように、server2の「Apps」というフォルダーを共有したいと思います。共有に成功しましたが、何かがおかしいです。共有フォルダにアクセスするために最初にDomain1\ITをグループとして追加したとき、共有ダイアログに正しいアイコンとテキストが表示されました。しかし、[共有]ダイアログを再度開いてアクセス許可を確認すると、列挙するのに非常に長い時間がかかり、最後に?が表示されます。アイコン、テキスト「<不明な連絡先>」。 Domain1のITグループは共有フォルダに正しくアクセスできますが、何かがおかしいと感じます。誰もが理由を知っていますか?
フォレスト内のドメインとそのフォレスト外のドメインの間に信頼が確立されると、外部ドメインのセキュリティプリンシパルが内部ドメインのリソースにアクセスできます。 Active Directoryは、信頼できる外部ドメインの各セキュリティプリンシパルを表すために、内部ドメインに外部セキュリティプリンシパルオブジェクトを作成します。これらの外部セキュリティプリンシパルは、内部ドメインのドメインローカルグループのメンバーになることができます。外部セキュリティプリンシパルのディレクトリオブジェクトはActiveDirectoryによって作成されるため、手動で変更しないでください。高度な機能を有効にすることで、ActiveDirectoryユーザーとコンピューターから外部のセキュリティプリンシパルオブジェクトを表示できます。
したがって、「不明な連絡先」は、Domain2で外部セキュリティプリンシパルとして知られているものです。ディレクトリのデフォルトの命名コンテキストのCN=ForeignSecurityPrincipals,DC=domain2,DC=com
にコンテナがあります。そのコンテナー内には、ActiveDirectoryがDomain2に認識されているDomain1のすべてのユーザーを解決するために使用するポインターが含まれている必要があります。 Domain2はSIDを認識していますが、Domain1にそのSIDをSamAccountNameに親切に変換するように依頼する必要があります。
あなたの信頼は一方向であるため、Domain1はそれを信頼していないため、Domain2はそれを行うことができません。
Domain1で匿名SID変換を有効にすることもできますが、これはセキュリティ上のリスクです。または、信頼を双方向にすることもできます。
SIDはフォレストの信頼をチェックするのに十分であるため、現在の「不明な連絡先」は、気付いたとおりに機能することを妨げていません。今のところ、それは一種の美的問題です。
その他のMSドキュメント:
実装
LookupAccountSidは、解決する単一のSIDを使用してLsaLookupSidsを呼び出します。したがって、LsaLookupSidsについてはこのセクションで説明します。
(LSA RPCインターフェイスを使用して)呼び出しが送信されるコンピューター上のLSAは、マップできるSIDを解決し、残りの未解決のSIDをプライマリドメインのドメインコントローラーに送信します。ドメインコントローラーは、グローバルカタログのSidHistoryにあるSIDを含め、追加のSIDをローカルデータベースのアカウント名に解決します。
そこでSIDを解決できない場合、ドメインコントローラーは残りのSIDを、SIDのドメイン部分が信頼情報と一致する信頼済みドメインのドメインコントローラーに送信します。
そして最後に、Microsoft AskDSブログ(これは素晴らしいブログです)からのこのビット:
ポートが開いていると仮定すると、変換をブロックしている他の部分があります。 最も一般的には、一方向の信頼が関係し、匿名の翻訳がブロックされている場合にこれが表示されます。グループで匿名のSID /名前の翻訳を簡単に許可できますポリシー。ドメインコントローラーは実際に変換要求を処理するサーバーであるため、このポリシーはドメインコントローラーにのみ適用されます。
編集:回避策として、「Server2上のアプリにアクセスできるユーザー」というドメイン2にセキュリティグループを作成し、ドメイン1からユーザープリンシパルを追加することを検討できます。そのグループに。