1

だからここに私が解決策を見つけようとしているシナリオがあります。

私の会社には現在、スタッフ用の記録システムがありますが、アクティブ ディレクトリにリンクされていません。このため、データが重複しており、多くの場合不正確です。私がやろうとしているのは、レコード システムが Active Directory の値を更新できるようにすることですが、何を誰が変更できるかをスコープしたいと考えています。それで

  1. 新しい雇用者がいる場合、IT は最初のレコードに入力し、AD ユーザーも作成します。
  2. hr がやって来て、タイトル/説明/電話/住所などを更新しますが、システムからレコードを作成または削除することはできません。（彼らはチケットか何かを提出する必要があります）

kerberos のダブルホップ問題について調べてみましたが、委任する機能が必要なようですが、私自身の IT 能力は十分ではありません。エスカレートして、より高いレベルの IT 担当者から承認を得て、アカウントへの委任を許可することもできますが、それは最後の手段として取っておきます。

偽装を使用して物事を達成したいのですが、偽装を実装する方法について明確な答えを見つけるのに苦労しています。

web.config と iis で偽装を有効にしました。appPool ID をネットワーク サービスに設定しました。その後、次に何をすべきか、設定をテストする方法がわかりません。

編集1：私はなりすましのためにこのパターンにも従っています

var iid = HttpContext.Current.User.Identity;
WindowsIdentity wi = (WindowsIdentity)iid;
WindowsImpersonationContext wic = wi.Impersonate();
try
{
    // do something with a directory entry here
}
catch
{}
finally
{
    wic.Undo();
}
4

2 に答える 2

2

Web サーバーで AD の委任が有効になっていることを確認してください。とにかく、それは私がいつも忘れているステップです。

カップル参照リンク:

http://blog.reveille.org.uk/2010/01/asp-net-impersonation-delegation/ http://support.microsoft.com/kb/810572?wa=wsignin1.0

また、Web サイトで Windows 認証を使用していることを確認してください。

適切な AD アクセス権を持つユーザーのみが AD 設定を操作できるように機能するかどうかは、すぐにわかります (文字通り、AD を自分で変更するのと同じようになるため)。

于 2012-12-14T04:48:01.897 に答える
0

委任は、より強力な形のなりすましです。なりすましを使用すると、ローカルコンピューターでユーザーとして機能でき、委任を使用すると、リモートコンピューターでユーザーとして機能できます。委任を回避する唯一の方法は、ADの制御をWebサービス（この場合はネットワークサービスとして実行しているため、Webサーバーのコンピューターアカウントに目的の属性への書き込み機能を与える）に委任し、Webを使用することです。サービスが更新を実行します。ただし、変更をWebサイトを使用していたユーザーに帰することはできないため、これはお勧めできません。

于 2012-12-14T21:06:26.517 に答える