Пользовательская реализация IPrincipal throws System.SystemException: доверительные отношения - PullRequest
1 голос
/ 03 августа 2010

У нас есть сайт ASP.NET, который частично зависит от проверки подлинности форм для учетных данных для входа, однако реализация IPrincipal полностью настраивается.

Но при запуске сайта на определенном сервере (который несколько полу-защищенный, когда речь заходит о безопасности), приложение аварийно завершает работу при вызове IPrincipal.IsInRole () со следующим сообщением:

System.SystemException: доверительные отношения между основным доменом и доверенным доменом не удалось.

Это указывает на ошибку связи между веб-сервером и 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, но в моей среде и веб-сервер, и DC2008 R2, так что это не должно применяться.У меня, однако, есть некоторые ошибки в моем журнале событий, которые указывают, что есть некоторые проблемы с коммуникацией с DC, но так как мы не полагаемся на LDAP, это не должно быть проблемой.

Системе безопасности не удалось установить защищенное соединение с сервером ldap / ddc.domain.com / xxxxxxxxxxxxx.Протокол аутентификации недоступен.

Серверы выходят за пределы моей области, что означает, что я сам не могу это исправить, однако у меня есть билет поддержки, но это может быть преднамеренно иметь эту настройкупо соображениям безопасности (даже если это кажется глупым).

Кто-нибудь сталкивался с этой проблемой?

Продолжение: трассировка стека показывает это:

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.

Я попытался изменить принципала по умолчанию, вызвав его при запуске appstart

AppDomain.CurrentDomain.SetPrincipalPolicy( PrincipalPolicy.NoPrincipal);

Но это некажется, не пойдет. Как изменить принципал по умолчанию в ASP.NET?

1 Ответ

1 голос
/ 03 августа 2010

Я подумал, что это был модуль WindowsAuthenticationModule, добавивший WindowsPrincipal в HttpContext.User, но удаление которого все же привело к той же проблеме. Это подразумевалось в этой статье:

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]);

Я согласен на это сейчас. Спасибо за вклад всех!

...