User.IsInRole("поддельная группа") приводит к "Не удалось установить доверительные отношения между основным доменом и доверенным доменом"

У меня есть приложение MVC 3, использующее проверку подлинности Windows с утверждениями с использованием WIF 4.5.

Доступ к приложению контролируется (в настоящее время) через членство в группе AD:

<deny users="?" />
<allow roles="domain\somegroup" />
<deny users="*" />

В дополнение к группам AD у нас есть собственные роли, которые необходимо добавить. (Это приложение конвертируется из форм в аутентификацию Windows)

Для поддержки этих пользовательских ролей (до тех пор, пока они не будут управляться в AD), мы добавляем их как ClaimTypes.GroupSid к пользователю, чтобы существующий код использовал [Authorize("ADMIN")] а также User.IsInRole("ADMIN") продолжает функционировать:

Application_PostAuthenticateRequest(object sender, EventArgs e)
{
    var identity = ClaimsPrincipal.Current.Identity as WindowsIdentity;
    var roles = userDAL.GetRoles(identity.Name);
    foreach(var role in roles)
    {
        identity.AddClaim(new Claim(ClaimTypes.GroupSid, role));
    }
}

И все это работает, как ожидалось.

За исключением случаев, когда текущий пользователь НЕ является членом какой-либо настраиваемой роли (например, ADMIN), и эта роль также не существует в AD

Мы используем [Authorize("ADMIN")] на методы действия контроллера, а также различные случаи User.IsInRole("ADMIN") в зависимости от сценария. Это в тех случаях, когда происходит ошибка, и приложение взрывается.

Инфраструктура AD находится в процессе обновления / миграции. Я не осведомлен обо всех деталях, но знаю, что есть несколько доменов, предположительно с доверием между ними, и мне сказали специалисты по инфраструктуре, что эти доверительные отношения установлены и работают.

Так что на самом деле, я думаю, мне интересно 2 вещи:

  1. Это действительно не похоже на то, что наш код должен обрабатывать. Так что действительно может быть не так с доменом? Могу ли я узнать, для какого "доверенного" домена нарушаются доверительные отношения?

  2. Каков наилучший способ обойти это? Мне не нравится идея написания вспомогательных методов и Authorize() подклассы просто чтобы заманить это исключение в ловушку

Источник

1 ответ

Перейдите на страницу inetmgr, сайты, веб-сайт по умолчанию, имя сайта, группу iis, двойной щелчок по аутентификации, отключение анонимной аутентификации, а затем сбросьте пул приложений.

Это происходит, когда Windows не может расшифровать роли, определенные в теге "авторизация, разрешить роли" в файле web.config. Для тестирования закомментируйте теги пользовательских ролей из файла web.config. Эта проблема возникает при смешивании проверки подлинности с помощью форм и проверки подлинности Windows. Волшебство происходит в методе Application_PostAuthenticateRequest файла Global.asax, при использовании проверки подлинности с помощью форм вы можете преобразовать User.Identity в FormsIdentity, затем создать пользовательский идентификатор из билета FormsIdentity, а затем создать собственный принцип из пользовательского идентификатора, после чего вы будете возможность прикрепить CustomPrincipal к текущему пользователю и текущему принципалу, т.е.

Dim fIdent As FormsIdentity = CType(User.Identity, FormsIdentity)
Dim ci As New CustomIdentity(fIdent.Ticket) 
Dim cp As New CustomPrincipal(ci)
HttpContext.Current.User = cp : Thread.CurrentPrincipal = cp

Для IIS вы хотите включить проверку подлинности с помощью форм и анонимную проверку подлинности, все остальное должно быть отключено. При использовании проверки подлинности Windows метод Application_PostAuthenticateRequest в файле Global.asax может создать пользовательский принцип непосредственно из User.Identity, т.е.

Dim cp As New CustomPrincipal(User.Identity)
HttpContext.Current.User = cp : Thread.CurrentPrincipal = cp

В этом случае в качестве параметров IIS должна использоваться проверка подлинности Windows, а олицетворение ASP.Net включено, а все остальное отключено.

Смешивание этих методов проверки подлинности приводит к ошибке "Отношения доверия между основным доменом и доверенным доменом не удалось", потому что если ваш метод Application_PostAuthenticateRequest по какой-то причине не реализует CustomPrinciple, то окна будут пытаться использовать встроенную функцию IsInRole, которая проверяет роль против ролей домена вместо использования пользовательского IsInRole, который находится в вашем коде кода CustomPrinciple за файлом.

Вот полезная статья и ссылки:

http://www.codeproject.com/Articles/8819/Authorize-and-authenticate-users-with-AD https://msdn.microsoft.com/en-us/library/ff647405.aspx
https://support.microsoft.com/en-us/kb/306359

Источник

Это происходит, если у вас есть недоступная конфигурация доверенного домена, IsInRole также выполняет поиск группы в доверенных доаминах, а если доверенный домен недоступен, выдает исключение доверия.

Источник
Другие вопросы по тегам