Проверка членства в группе Active Directory in.Net 4.5

у меня есть ASP.Net приложение MVC с использованием проверки подлинности Windows, и я проверяю членство в группе для безопасности действий контроллера.

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

Первая Попытка: [Санкционировать]

классический метод состоит в том, чтобы просто шлепнуть Authorize атрибут аннотации данных на действии контроллера и перейдите в город:

[Authorize(Roles = @"domaingroupName1")]

нет кости. Я подсказал для верительных грамот. Обычно это означает, что что-то не так с конфигурацией проверки подлинности Windows, но она отлично настроена: (1) HttpContext.User это WindowsPrincipal object, и (2) я подтвердил, что работает другое известное имя группы.

Вторая Попытка: IsInRole ()

следующим шагом было пойти более старомодным путем и использовать IPrincipal.IsInRole() и снова возвращается false, другой true.

var wp = (WindowsPrincipal)User;

// false
var inGroup1 = wp.IsInRole(@"domaingroupName1");
// true
var inGroup2 = wp.IsInRole(@"domaingroupName2");

тупик... так что я включаю свои системы, ботаники, и мы перепроверяем. всё. Пользователь является членом группы? Да. Название группы пишется правильно? Да. Следующим шагом было поймать Сида.

третья попытка: Поиск коллекции группы идентичности

в моем контроллере я проверяю WindowsIdentity и просмотрите коллекцию групп для SID проблемной группы:

var wi = (WindowsIdentity)wp.Identity;
var group = wi.Groups.SingleOrDefault(g => g.Value == "group1-sidValue");

на group переменная

7
.net active-directory asp.net-mvc c# security

2 ответов

ответ:

по сути, это проблемы перевода между WindowsIdentity и NTAccount (обе эти системы.Безопасность.Принципал) и, наконец, фактическая запись Active Directory.

при проверке a WindowsIdentity против AD, если вы хотите использовать что-либо, кроме Sam или Sid, вам нужно будет использовать System.DirectoryServices.AccountManagement.

предостережение: в .Net 4.5 участники безопасности включают утверждения, но это вне контекста.

долго Объяснение:

в веб-приложении с проверкой подлинности Windows,HttpContext.User это WindowsPrincipal объект обертывания базового WindowsIdentity.

WindowsIdentity имеет для большинства намерений и целей, только два свойства, с помощью которых пользователем могут быть определены: Name и User.

эти свойства преобразуются в два свойства в соответствующей записи рекламного аккаунта идентификатора:

WindowsIdentity.Name = SamAccountName

WindowsIdentity.User = SID

на [Authorize] атрибут фильтра в конечном счете называет IsInRole(string role) на основного... и IsInRole() string overload создает экземпляр NTAccount С role ("SamAccountName" в записи объявления).

это объясняет сбой в #1 и #2 выше.

разрешить HttpContext.User против всего, кроме его / ее Sid или SamAccountName, вам понадобится DirectoryServices.AccountManagement или классический LDAP.

4

у меня есть ASP.Net приложение MVC с использованием проверки подлинности Windows, и я проверяю членство в группе для безопасности действий контроллера. Как бы просто это ни звучало, я не нашел другого вопроса, который может решить проблему, которую я испытываю. Мне потребовалось много времени, чтобы найти что-то http://www.c-sharpcorner.com/uploadfile/scottlysle/test-for-user-group-membership-in-Asp-Net-C-Sharp/

мой код, чтобы проверить, принадлежит ли пользователь к группе объявлений :

foreach (System.Security.Principal.IdentityReference group in System.Web.HttpContext.Current.Request.LogonUserIdentity.Groups)
{
     if (String.Equals(group.Translate(typeof(System.Security.Principal.NTAccount)).ToString(), @"your_domain_name\your_group_name", StringComparison.InvariantCultureIgnoreCase))
     {
         // the user belongs to a group 
     }
}

это все, что мне нужно, кроме <authentication mode="Windows"/> в Интернете.файл config

0