System.DirectoryServices.AccountManagment を使用して、ユーザーが特定のグループのメンバーであるかどうかを判断しようとしています。
- これは、64 ビット システムの SharePoint 2007 の SharePoint WebPart 内で行っています。
- プロジェクト ターゲット .NET 3.5
- 偽装は web.config で有効になっています。
- 問題の IIS サイトは、ドメイン ユーザーが ID として構成された IIS アプリケーション プールを使用しています。
私はそのようにインスタンス化することができますPrincipalContext:
PrincipalContext pc = new PrincipalContext(ContextType.Domain)
次に、プリンシパルを取得しようとします。
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
{
GroupPrincipal group = GroupPrincipal.FindByIdentity(pc, "MYDOMAIN\somegroup");
// snip: exception thrown by line above.
}
上記とUserPrincipal.FindByIdentityユーザー SAM の両方で、 DirectoryServicesCOMException「ログオン失敗: 不明なユーザー名またはパスワードが正しくありません」がスローされます。
完全な SAMAccountName をFindByIdentity(MYDOMAIN\username の形式で) またはユーザー名だけに渡してみましたが、動作は変わりません。HostingEnvironment.Impersonateと の両方のSPSecurity.RunWithElevatedPrivilegesアプローチを使用して、他の資格情報でコードを実行しようとしましたが、同じ結果が得られました。
また、ドメイン名を使用してコンテキストをインスタンス化しようとしました:
Principal Context pc = new PrincipalContext(ContextType.Domain, "MYDOMAIN");
PrincipalServerDownExceptionこれにより、 「サーバーに接続できませんでした」がスローされます。
かなり強化されたサーバーで作業しています。私はシステムをロックダウンしていないので、何が行われたのか正確にはわかりません. これらを機能させるために、プール ID のユーザーまたはドメイン セキュリティ ポリシーに割り当てる必要がある資格情報がある場合は、それに応じてドメインを構成できます。コードの実行を妨げている設定はありますか? コード自体に何か不足していますか? これは SharePoint Web では不可能ですか?
編集:さらにテストすると、.NET 4.0 を対象とするコンソール アプリケーションでテストすると、私のコードは正しく機能します。何らかの理由で .NET 3.5 を対象とした場合、コンソール アプリで AccountManagement を使用できなかったため、別のフレームワークを対象にしました。
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain))
using (UserPrincipal adUser = UserPrincipal.FindByIdentity(pc, "MYDOMAIN\joe.user"))
using (GroupPrincipal adGroup = GroupPrincipal.FindByIdentity(pc, "MYDOMAIN\user group"))
{
if (adUser.IsMemberOf(adGroup))
{
Console.WriteLine("User is a member!");
}
else
{
Console.WriteLine("User is NOT a member.");
}
}
この関数の実行を妨げる可能性のある SharePoint 環境の違いは何ですか?