0

technet.microsoft で未回答の質問を再投稿しますか?

MSDN の「ASP.NET Delegation」の記事では、次 のように説明しています。

  • 1) 「特定のアカウントをプロセス ID として使用するように構成すると、ASP.NET はそのアカウントを委任しようとします。リモート マシン上のローカル アカウントと同一 (パスワードを含む) のローカル アカウントである場合、委任が可能です。 . そのようなアカウントがリモート マシンに存在しない場合、ネットワークには Windows 匿名アカウント (NT AUTHORITY\ANONYMOUS LOGON) として表示されます. さらに、アカウントがドメイン アカウントにアクセスできる場合、委任も可能です。その場合、そのアカウントのドメイン ネットワーク ID を使用します。」

ワークグループ内のリモート コンピューター (サーバー リソース) に手動/対話的にアクセスする場合と同じ頻繁に繰り返される話 - 同じユーザー名、同じパスワードでローカル アカウントを作成する必要があります。しかし、なぜ？

ワークグループの Windows クライアント プロセスが、ターゲット マシン上にそのような (ローカル) アカウントの複製が事前に作成されていないと、サーバー マシン上のリソースにアクセスできない場合、クライアント (プロセス、マシン、またはユーザー) はサーバー リソースにアクセスできるのは、それ以降に限られるということですか?サーバー マシンにログインした (ログオン セッションを開く) ことはありますか?

または、サーバー マシンに対応する重複したローカル アカウントがなければ、そのようなアクセスは不可能であることをどのように理解すればよいでしょうか?

同じMSDN の「ASP.NET Delegation」の記事では、次のように説明されています。

  • 「NetworkService アカウント。システム アカウントと同じように動作します。このアカウントは、メンバーであるドメイン内のマシン アカウント (ドメイン名\マシン名) に関連付けられたネットワーク資格情報を所有しています」

どの Windows にもアカウント ((NT AUTHORITY\NETWORK SERVICE)) がありませんか?
他の多くの一般的な事前構築済みアカウントと同様に?
それらは (ドメインに参加する前に) インストールされているのに、リモート ネットワーク アクセスとクライアント識別に使用できないのはなぜですか?

ID ((NT AUTHORITY\NETWORK SERVICE) の下のワークグループ Windows からのプロセスがリモート サーバーにアクセスするときに使用される ID は何ですか?

私の関連する質問:

4

1 に答える 1

1

Q1: ワークグループ内のリモート コンピューター (サーバー リソース) に手動/対話的にアクセスする場合と同じよくある話 - 同じユーザー名、同じパスワードでローカル アカウントを作成する必要があります。しかし、なぜ？

A1: はい。以下の A3 を参照してください。

Q2: ワークグループ Windows クライアント プロセスが、ターゲット マシン上にそのような (ローカル) アカウントの複製が事前に作成されていないと、サーバー マシン上のリソースにアクセスできない場合、クライアント (プロセス、マシン、またはユーザー) がサーバー リソースにアクセスできるのは、 /サーバー マシンにログイン (ログオン セッションを開く) した後?

A2: はい - System1 のプロセスによる System2 のリソースへのすべてのアクセスは、認証される必要があります。例外として、誰かが System2 の 1 つ以上のリソース (およびシステム ポリシー) を構成して、匿名 (つまり、認証されていない) アクセスを許可している場合を除きます。さらに、Server2 は、System2 が検証できる資格情報を提示するネットワーク要求のみを認証できます。System2 のローカル ユーザー アカウントとパスワードから、または信頼できるドメイン コントローラーに接続することによって (System2 がドメインに参加している場合)。System2 は、ローカル ユーザーを含む System1 にのみ関連するユーザー アカウントまたは "ユーザー コンテキスト" (特別なハードコードされた SID によってのみ表される LocalSystem、Interactive、LocalService などの特別な "アカウント") について何も知りません。 System1 で定義されたアカウント、およびそれらの特別な SID のいずれか。

Q3: または、サーバー マシンに対応する重複したローカル アカウントがなければ、そのようなアクセスは不可能であることをどのように理解するのですか?

A3: 唯一の例外は (例外ではなく、設計されたユース ケースです)、System1 が System2 と同じユーザー名とパスワードを使用して認証する場合です。ネットワーク トラフィックに表示されるのは、System1 のプロセス (現在 System1\UserX として実行中) が System2 上のリソース (ファイル共有、データベース オブジェクト、Web ページなど) をネットワーク経由で要求することです。System1 からのその要求には、「System1 が認証に使用しようとしている資格情報」が含まれています (これは、特定の認証プロトコルに固有のものを説明することから逃れるための抽象的な一般化です。我慢してください)。他の状況では、アカウント UserX が System2 に存在しないか、別のパスワードを持っているため、System2 で認証の試行が失敗し、System1 の要求が失敗します。あれは、

一致するローカル アカウントがある状況では、System2 は、System1 がアカウント "System1\UserX" ではなく "System2\UserX" でログオンしていると "考え"、パスワードが一致するため、認証試行は成功します。

Q4: アカウント ((NT AUTHORITY\NETWORK SERVICE)) を持っている Windows はありませんか? 他の多くの一般的な事前構築済みアカウントと同様に、(ドメインに参加する前に) インストールされているのに、リモート ネットワーク アクセスとクライアント識別に使用できないのはなぜですか? ?

A4: NETWORK SERVICE は定義済みのアカウントではなく (Local Users and Groups アプレットには表示されません)、単なる SID であり、プロセスのトークンにその SID が含まれている場合 (状況によっては、そのトークンを使用するプロセスが作成された場合)、「ネットワーク サービス」(実際には「ネットワーク サービス SID を許可する任意のリソース」を意味します) がリソースにアクセスできるリソースは、リソースの通過を許可します。そうでなければ、Network Service は単なるユーザー フレンドリーな抽象化であり、残念ながら、ユーザー フレンドリーであるということは通常、それが実際にどのように機能するかを理解するのを難しくします。

システムがドメインに参加する前にネットワーク サービス SID にアクセス許可または特権を割り当てることができる場合がありますが、リモート システムへの要求は、マシンがドメインに参加しているかどうかに応じて、ネットワーク サービスとして実行されているサービスに対して非常に異なる応答をします。いいえ。ドメインに参加している場合、リモート要求は通常 (最新の Windows バージョンでは) ローカル システムのドメイン コンピューター アカウントを使用してリモート認証を試みます。ドメインに参加していない場合、リモート リクエストで資格情報が送信されず、リモート システムはそれを匿名 (つまり、認証されていない) リクエストとして処理する必要があります。

Q5: ID ((NT AUTHORITY\NETWORK SERVICE) の下のワークグループ Windows からのプロセスがリモート サーバーにアクセスするときに使用される ID は何ですか?

A5: A4 で暗示されているように、このシナリオではリモート サーバーが認識する IDはありません。

于 2010-10-27T20:13:08.313 に答える