UserPrincipal.FindByIdentity настаивает на том, что на сервере нет такого объекта.

В настоящее время я стремлюсь реализовать поставщика ролей только для чтения для приложения ASP.NET на основе групп безопасности домена с использованием утилит в сборке System.DirectoryServices.AccountManagement. У меня есть следующий фрагмент кода, который отлично работает в моем домене разработки, но не работает в среде развертывания:

Using myContext As New PrincipalContext(ContextType.Domain, Nothing, "DC=My,DC=Controller", accountName, accountPassword)
    Try
        Dim p As UserPrincipal = UserPrincipal.FindByIdentity(myContext, IdentityType.SamAccountName, userName)
        Dim groups = p.GetAuthorizationGroups()
        For Each g In groups
            Debug.WriteLine("Found security group: " & g.DisplayName & vbNewLine)
        Next
    Catch ex As Exception
        Debug.WriteLine("Encountered an exception: " & vbNewLine & ex.ToString())
    End Try
End Using

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

    System.DirectoryServices.AccountManagement.PrincipalOperationException: There is no such object on the server.
     ---> System.DirectoryServices.DirectoryServicesCOMException (0x80072030): There is no such object on the server.
       at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
       at System.DirectoryServices.DirectoryEntry.Bind()
       at System.DirectoryServices.DirectoryEntry.get_SchemaEntry()
       at System.DirectoryServices.AccountManagement.ADStoreCtx.IsContainer(DirectoryEntry de)
       at System.DirectoryServices.AccountManagement.ADStoreCtx..ctor(DirectoryEntry ctxBase, Boolean ownCtxBase, String username, String password, ContextOptions options)
       at System.DirectoryServices.AccountManagement.PrincipalContext.CreateContextFromDirectoryEntry(DirectoryEntry entry)
       at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInit()
       --- End of inner exception stack trace ---
       at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInit()
       at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit()
       at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize()
       at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx()
       at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable`1 identityType, String identityValue, DateTime refDate)
       at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext context, Type principalType, IdentityType identityType, String identityValue)
       at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, IdentityType identityType, String identityValue)

Я знаю, что очевидная "проблема" здесь заключается в том, чтобы убедиться, что объект действительно, ну ... существует на сервере. Тем не менее, я могу без сомнения подтвердить, что независимо от того, какое имя учетной записи SAM я использую, я получаю один и тот же результат от звонка. Кроме того, ActiveDirectoryMembershipProvider от Microsoft не имеет проблем с аутентификацией то же имя учетной записи SAM, и я могу найти объект, используя эту информацию с помощью _ 4_ класс. Единственное различие, которое я могу определить между сетью разработки и развертыванием, заключается в том, что DC среды развертывания - это Windows Server 2003, тогда как локально я разрабатываю с помощью Windows Server 2008 DC. Что я могу пропустить?


.net active-directory vb.net account-management .net-3.5
person lsuarez    schedule 10.11.2011    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Почему-то проблема заключалась в пути к контроллеру домена. Описание пути как DC=box123,DC=dom не сработало, но использование пути box123.dom сработало. Не могу сказать почему, и это поведение, которое я не могу воспроизвести в локальном домене, но это решило проблему.

РЕДАКТИРОВАТЬ:
После дальнейшего исследования конструкция DC=box123,DC=dom при сокращении до DC=dom также работала правильно. Я не понимаю динамики адресации, но я смог определить проблему, отобразив путь к образцу пользователя с помощью объекта DirectorySearcher, который показал путь к моему пользователю: LDAP://box123.dom/CN=username/CN=Users/DC=dom

person lsuarez    schedule 11.11.2011
comment
Так как же решить эту проблему? - person Nathan McKaskle; 17.08.2017

arrow_upward
2
arrow_downward

Я знаю, что это относительно старый вопрос, но я подумал, что наше решение может помочь кому-то еще в будущем. Мы столкнулись с той же проблемой в реальной среде клиента. Первоначально мы не могли воспроизвести проблему в нашей тестовой среде, но затем мы обнаружили, что это происходит только при доступе к сайту по https. После множества проб и ошибок, а также обращения в службу поддержки в Microsoft, я начал экспериментировать с вызовом, чтобы создать основной контекст. Первоначально создание экземпляра объекта было закодировано как

using (var pc = new PrincipalContext(ContextType.Domain, <serverUri>, <ldapDomain>, <username>, <userpass>))

Полный конструктор может принимать один дополнительный параметр

using (var pc = new PrincipalContext(ContextType.Domain, <serverUri>, <ldapDomain>, ContextOptions.Negotiate, <username>, <userpass>))

Как только ContextOption был указан (а в нашем случае это должно было быть Negotiate), вызов UserPrincipal.FindByIdentity работал должным образом.

person Ron O    schedule 21.10.2014

arrow_upward
1
arrow_downward

Вы не показываете значения dcPath, вот способ создать PrincipalContext подобным образом.

Using myContext As New PrincipalContext ContextType.Domain, "dom.fr:389", "dc=dom,dc=fr", "jpb", "root.123");

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

person JPBlanc    schedule 11.11.2011
comment
Конструкция DC-пути верна, в противном случае возникает исключение: «Отсылка была возвращена с сервера». Как я объяснил, одно и то же имя учетной записи SAM можно успешно использовать с DirectorySearcher со строкой фильтра "samaccountname=" & userName. Мне нужна другая идея. : \ - person lsuarez; 11.11.2011
comment
+1 за то, что заставил меня попробовать новые способы построения пути к контроллеру. Получился довольно неожиданный результат, описанный ниже. - person lsuarez; 11.11.2011