1

ログイン資格情報のフォーム認証に部分的に依存する ASP.NET サイトがありますが、IPrincipal の実装は完全にカスタムです。

ただし、特定のサーバー (セキュリティに関しては多少強化されています) でサイトを実行している場合、次のメッセージで IPrincipal.IsInRole() を呼び出すと、アプリがクラッシュします。

System.SystemException: プライマリ ドメインと信頼されたドメインの間の信頼関係に失敗しました。

これは、Web サーバーと DC 間の通信エラーを示していますが、アプリケーションは Windows 認証をまったく使用していないため、DC と通信する必要がある理由がわかりません。

これは私の実装です:

[Serializable]
public class CustomPrincipal : IPrincipal
{
    public CustomPrincipal( IUser userObj )
    {
        this.Identity = new CustomIdentity( userObj.Id, userObj.Username );
    }

    public bool IsInRole( string role )
    {
        if ( role == null )
            return false;

        var roles = HttpContext.Current.Session["authentication-roles"] as string[];

        if (roles == null)
            return false;

        return Array.IndexOf( roles, role ) >= 0;
    }

    public IIdentity Identity { get; private set; }

    public CustomIdentity FullIdentity
    {
        get { return (CustomIdentity) this.Identity; }
    }
}

ローカル (動作する場所) でデバッグする場合、実際に実行されるのは正しい実装です。使用法は次のとおりです。

    public override void Render()
    {
        var items = this.manager.Items
            .Where( i => EngineContext.CurrentUser.IsInRole( i.Role.InternalName ) );

ここでブレークポイントを設定すると、EngineContext.CurrentUser が実際には CustomPrincipal の実装であることがわかります。

誰もこれを経験しましたか？ASP.NET がまだインターフェイス メソッドで LDAP ルックアップをトリガーしているように見えるのはどうしてですか?

http://support.microsoft.com/kb/976494を見つけましたが、私の環境では Web サーバーと DC の両方が 2008 R2 なので、これは当てはまりません。ただし、DC との通信に問題があることを示すエラーがイベント ログにいくつかありますが、LDAP に依存していないため、問題にはなりません。

セキュリティ システムは、サーバー ldap/ddc.domain.com/xxxxxxxxxxxx との安全な接続を確立できませんでした。利用可能な認証プロトコルがありませんでした。

サーバーは私の範囲外です。つまり、これを自分で修正することはできません。ただし、サポートチケットを持っていますが、セキュリティ上の理由から意図的にこの設定を行うことを意図している可能性があります (馬鹿げているように見えますが)。

誰もこの問題を経験しましたか?

フォローアップ：スタックトレースはこれを示しています：

at System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed)
at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
at System.Security.Principal.WindowsPrincipal.IsInRole(String role)
at Company.Sites.Manager.ViewComponents.MenuComponent.<Render>b__0(INavigationItem i)

編集：

最終的に、開発マシンでこのエラーを再現できるようになりました (昨日 DC からマシンを取り消しましたが、今日まで再現しませんでした)。

HttpContext.User は実際にはデフォルトで WindowsPrincipal のようですが、私のコードのエラーは、ログイン時に CustomPrincipal に置き換えるだけでした。したがって、認証されていないユーザーは引き続き WindowsPrincipal を取得しますが、AD に信頼の問題がある場合、WindowsPrincipal は恐ろしく失敗します。

appstartでこれを呼び出して、デフォルトのプリンシパルを変更しようとしました

AppDomain.CurrentDomain.SetPrincipalPolicy( PrincipalPolicy.NoPrincipal);

ASP.NET で既定のプリンシパルを変更するにはどうすればよいですか?

4

1 に答える 1

1

WindowsPrincipal を HttpContext.User に追加したのは WindowsAuthenticationModule だと思いましたが、それを削除しても同じ問題が発生しました。それはこの記事で暗示されていました：

http://msdn.microsoft.com/en-us/library/ff647076.aspx

AppDomain.CurrentDomain.SetPrincipalPolicy( PrincipalPolicy.NoPrincipal); を設定してみました。

appstart および OnAuthenticateRequest で提案されていますが、役に立ちません。

ただし、これは機能しました（OnAuthenticateRequestで）：

Context.User = new GenericPrincipal(new GenericIdentity(String.Empty), new string[0]);

とりあえずこれで落ち着きます。皆様のご意見をお寄せいただきありがとうございます。

于 2010-08-03T10:01:23.297 に答える