UserPrincipal.FindByIdentity Настаивает «На сервере такого объекта нет». - PullRequest
Новая
       38

UserPrincipal.FindByIdentity Настаивает «На сервере такого объекта нет».

5 голосов
/ 11 ноября 2011

В настоящее время я планирую реализовать поставщик ролей только для чтения для приложения 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 я использую, я получаю один и тот же результат от вызова.Кроме того, Microsoft ActiveDirectoryMembershipProvider не испытывает проблем при аутентификации с использованием того же имени учетной записи SAM, и я могу найти объект, используя эту информацию в классе DirectorySearcher.Единственные различия, которые я могу определить между сетью разработки и развертыванием, заключаются в том, что DC среды развертывания представляет собой Windows Server 2003, тогда как локально я занимаюсь разработкой с Windows Server 2008 DC.Что я могу упускать из виду?

Ответы [ 3 ]

4 голосов
/ 11 ноября 2011

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

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

2 голосов
/ 21 октября 2014

Я знаю, что это относительно старый вопрос, но я подумал, что наше решение может помочь кому-то еще в будущем.Мы столкнулись с той же проблемой в реальной среде клиента.Изначально мы не могли воспроизвести проблему в нашей тестовой среде, но потом обнаружили, что это происходит только при доступе к сайту по 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 работал как ожидалось.

1 голос
/ 11 ноября 2011

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

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

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

...