.net UserPrincipal.FindByIdentity 坚持“服务器上没有这样的对象。”

UserPrincipal.FindByIdentity Insists "There is no such object on the server."

提问by lsuarez

I am currently aiming to implement a read-only role provider for an ASP.NET application based on domain security groups using the utilities in the System.DirectoryServices.AccountManagementassembly. I have the following piece of code which works fine on my development domain, but fails in the deployment environment:

我目前的目标是使用程序集中的实用程序为基于域安全组的 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

The exception stack trace returns as follows:

异常堆栈跟踪返回如下：

    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)

I know the obvious "gotcha" here is to be certain the object actually, well... exists on the server. However, I can confirm without a doubt that no matter which account's SAM Account Name I use, I receive the same result from the call. Additionally, Microsoft's ActiveDirectoryMembershipProviderhas no trouble authenticating against the same SAM Account Name and I am able to find the object using that information with the DirectorySearcherclass. The only differences I can identify between the development network and deployment is that the deployment environment's DC is a Windows Server 2003 box, whereas locally I am developing with a Windows Server 2008 DC. What might I be overlooking?

我知道这里明显的“问题”是确定对象实际上存在于服务器上。但是，我可以毫无疑问地确认，无论我使用哪个帐户的 SAM 帐户名称，我都会从呼叫中收到相同的结果。此外，MicrosoftActiveDirectoryMembershipProvider可以轻松地针对相同的 SAM 帐户名进行身份验证，并且我能够使用DirectorySearcher该类信息找到该对象。我能确定的开发网络和部署之间的唯一区别是部署环境的 DC 是 Windows Server 2003 机器，而我在本地使用 Windows Server 2008 DC 进行开发。我可能会忽略什么？

采纳答案by lsuarez

For some reason, the problem lay in the path to the domain controller. Describing the path as DC=box123,DC=domdid not work, but using the path box123.domdid. Can't say why, and it's not a behavior I can duplicate on the local domain, but that resolved the issue.

出于某种原因，问题出在域控制器的路径上。将路径描述为DC=box123,DC=dom不起作用，但使用路径box123.dom却起作用。不能说为什么，这不是我可以在本地域上复制的行为，但这解决了问题。

EDIT:
Upon further investigation, the construction DC=box123,DC=domwhen pared down to DC=domfunctioned correctly as well. I don't understand the dynamics of the addressing, but I was able to determine the trouble by displaying the path to a sample user using a DirectorySearcher object, which revealed the path to my user to be: LDAP://box123.dom/CN=username/CN=Users/DC=dom

编辑：
经过进一步调查，该结构DC=box123,DC=dom在缩减时也DC=dom能正常运行。我不了解寻址的动态，但我能够通过使用 DirectorySearcher 对象显示示例用户的路径来确定问题，该对象显示我的用户的路径为：LDAP://box123.dom/CN=username/CN=Users/DC=dom

回答by Ron O

I know this is a relatively old question, but I thought our solution might help someone else down the line. We encountered the same issue in the customer's live environment. Initially we couldn't replicate the issue in our test environment, but then we discovered it only happened when accessing the site under https. Through a lot of trial and error plus a support call to Microsoft, I started playing around with the call to create the principal context. Initially, the object instantiation was coded as

我知道这是一个相对较旧的问题，但我认为我们的解决方案可能会帮助其他人。我们在客户的现场环境中遇到了同样的问题。最初我们无法在我们的测试环境中复制该问题，但后来我们发现它仅在通过 https 访问站点时发生。通过大量的试验和错误以及给 Microsoft 的支持电话，我开始尝试创建主要上下文。最初，对象实例化被编码为

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

The full constructor can take one additional parameter

完整的构造函数可以带一个额外的参数

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

Once the ContextOptionwas specified (and in our case, it had to be Negotiate), the call to UserPrincipal.FindByIdentityworked as expected.

一旦ContextOption指定了（在我们的例子中，它必须是Negotiate），对 的调用就会UserPrincipal.FindByIdentity按预期工作。

回答by JPBlanc

You don't show th values of dcPath here is a way to construct PrincipalContext like this.

您不在这里显示 dcPath 的值是一种像这样构造 PrincipalContext 的方法。

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

After that the exception can be explained by the fact that userNameis not a valid samAccountName on your controler.

之后，异常可以通过userName在您的控制器上不是有效的 samAccountName这一事实来解释。