.Net Проверка подлинности роли PrincipalPermission не выполняется

У меня есть приложение vb.net 3.5, использующее класс PrincipalPermission, чтобы гарантировать, что пользователь является членом роли. Код работает для некоторых групп в домене Active Directory, но не работает для других. Сначала я подумал, что пространство было проблемой, но я проверил «Пользователи домена», и это сработало. Выполняя этот код, я являюсь участником группы приложений.

Imports System.Security
Imports System.Security.Principal
Imports System.Security.Permissions

    Private Function DemandSecurity() As Boolean
        AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
        Dim principalGroup As New PrincipalPermission(Nothing, "App Group")
        Try
            principalGroup.Demand()
            Debug.Print("Demanding pricipal permissions for current user on 'App Group' role succeeded. ")
        Catch secEx As SecurityException
            Debug.Print("Security Exception - Demanding pricipal permissions for current user on 'App Group' role failed. ")

            Application.DoEvents()
            MessageBox.Show("Permission denied. Output: " & vbNewLine & secEx.ToString, "App - Security Exception", MessageBoxButtons.OK, MessageBoxIcon.Error, MessageBoxDefaultButton.Button1)

            Return False
            Exit Function
        End Try
        Return True
    End Function

Вывод ошибки из secEx.ToString:

«System.Security.SecurityException: запрос на разрешение участника не удался. В System.Security.Permissions.PrincipalPermission.ThrowSecurityException () в System.Security.Permissions.PrincipalPermission.Demand () в App.My.MyApplication.DemandSecurity () в C: \ Documents and Settings \ me \ My Documents \ Visual Studio 2008 \ Projects \ App \ App \ ApplicationEvents.vb: строка 28

Действие, которое не удалось, было: Требовать. Тип первого разрешения, которое не удалось, был: System.Security.Permissions.PrincipalPermission.

Первое разрешение, которое не удалось, было: IPermission class = "System.Security.Permissions.PrincipalPermission, mscorlib, Version = 2.0.0.0, Culture = нейтральный, PublicKeyToken = b77a5c561934e089" version = "1"> Identity Authenticated = "true" Role = " Группа приложений "/>

Спрос был на: IPermission class = "System.Security.Permissions.PrincipalPermission, mscorlib, Version = 2.0.0.0, Culture = нейтральный, PublicKeyToken = b77a5c561934e089" version = "1"> Identity Authenticated = "true" Role = "Группа приложений" "/>

Произошедшая ошибка сборки или домена приложения: mscorlib, Version = 2.0.0.0, Culture = нейтральный, PublicKeyToken = b77a5c561934e089 "

Дайте мне знать, если мне нужно добавить что-нибудь еще.


person Russell Hart    schedule 23.11.2012    source источник
comment
Я также пробовал использовать My.User.IsInRole, который также возвращает false. Я определенно в роли.   -  person Russell Hart    schedule 24.11.2012


Ответы (2)


Я думаю, вам лучше проверить свои группы AD, чтобы увидеть эту проблему: http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/3e8e9209-17c7-4674-8780-7ae09c607118

person Jorge Alvarado    schedule 23.11.2012
comment
Спасибо, Хорхе. Имя cn совпадает с именем до Windows 2000, так что это не сработает. Если только я не упустил суть этой статьи. - person Russell Hart; 24.11.2012
comment
Чтобы уточнить, это не отвечает на вопрос. Надеюсь, кто-нибудь может подсказать, что с этим не так. - person Russell Hart; 24.11.2012
comment
@RussellHart тот факт, что вы заявляете, что некоторые поиски завершаются неудачно, а другие нет, довольно странно, пахнет проблемой именования, как вы указали в своей информации в начале, пробовали ли вы использовать браузер LDAP и запрашивать идентификатор объекта вместо имени ? - person Jorge Alvarado; 24.11.2012
comment
Успешные группы находятся в CN = Users. Группы, которые терпят неудачу, находятся в OU = Security Groups в том же домене. Как изменить приведенный выше код, чтобы он требовал группы в организационном подразделении? Любые указатели очень приветствуются, отправьте, пожалуйста, новый ответ, чтобы я мог принять. Спасибо - person Russell Hart; 25.11.2012

хорошо, это просто безумное предположение, я случайно видел это обсуждение SAMAccountName и выдающихся имен, но не знаю, осталась ли это актуальной проблемой: Active Directory и PrincipalPermission

честно говоря, я не знаю, может ли «Роль» выполнять полный фильтр LDAP, но давайте попробуем: предположим, отличительное имя вашей группы выглядит так:

"CN = MyGroup, OU = SecurityGroups, OU = Department, DC = Company, DC = com"

почему бы не попробовать это:

Role="CN=MyGroup,OU=SecurityGroups,OU=Department,DC=Company,DC=com"

Role=@"Company.com\Department\Security Groups\MyGroup"  // Not sure about this one though

И поскольку это кажется более логичным, может быть так:

Role=@"Company\SAMAccountNameOfYourGroup"

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

person Jorge Alvarado    schedule 25.11.2012