Question

我遇到C＃访问AD对象的问题。代码的目标是检索用户的组。我们有两个涉及的域 - 应用程序和许多用户所在的域，以及一个包含用户的可信域，因此代码必须能够从两个域中获取组。

我正在使用DirectorySearcher对象并根据用户SID对其进行过滤。它被打包成DLL以供应用程序使用。应用程序当前使用相同的代码并且它可以工作，但是当它调用DLL时，DLL将不会从AD返回任何内容。它无法从FindOne（）调用中检索任何用户。

我们在使用搜索用户之前遇到了类似的问题，之前我们只涉及1个域，但找到了解决方法 - 我们可以直接打开用户对象，但没有搜索该对象。既然我们有第二个域，我们必须使用用户的SID，我们不能只打开对象。

DLL在一个测试环境中工作，但在其他两个测试环境中不起作用。什么可能导致这种行为？这是DLL的问题吗？ AD安全吗？应用安全性？我们如何确定用户是否有权搜索？

或者（如果我们找不到解决此问题的方法），如何在不使用搜索的情况下根据其SID获取用户的组？

Answer 1

您使用的是.NET 3.5吗？用于组和用户管理的AD内容（“主要管理”）在3.5中已经有了很大的改进。

有一个新的System.DirectoryServices.AccountManagement命名空间非常有用 - 在Ethan Wilansky和Joe Kaplan撰写的一篇文章中阅读了所有关于它的here on MSDN Magazine。

.NET 3.5的内容最终允许您以编程方式轻松获取用户的组，并包含用户的主要组和任何嵌套的组成员身份。

如果您使用的是.NET 3.5，则可以使用以下代码：

using(PrincipalContext ctx = new PrincipalContext(ContextType.Domain))
{
    using(p = Principal.FindByIdentity(ctx, "yourUserName"))
    {
        var groups = p.GetGroups();

        using (groups)
        {
            foreach (Principal group in groups)
            {
                Console.WriteLine(group.SamAccountName + "-" + group.DisplayName);
            }
        }
    }
}

S.AD.AM还包括“Principal”类的新方法，以通过各种搜索标准（例如，用户，组，计算机）查找主体（用户，组，计算机）。按名称，SID，GUID：

FindByIdentity包含两个重载，两者都采用PrincipalContext 和寻找的价值。对于价值，你可以指定任何支持的身份类型：SamAccountName，姓名， UserPrincipalName，DistinguishedName，希德，或指导。

非常整洁，是吗？： - ）

马克

Answer 2

一般来说，使用DLL不会改变System.DirectoryServices的工作方式。我使用插件程序集方法来搜索AD，它的工作方式与运行实际程序集本身相同。

有几个问题（你应该问自己）可能会有所启发：

测试环境是否相同？相同的功能域级别（Win2000，Win2003等），同样的信任设置？
机器是否在运行代码域加入（即你创建时提供凭据 DirectoryEntry对象）？ 1.您使用的帐户是否在域中搜索拥有跨域信任。
您的域名是否设置为父/子关系？
如果您通过sAMAccountName或搜索域名会发生什么情况 UPN？
您是否已将DirectorySearch参数设置为自动搜索其他域名？

有几种方法可以调试它。

如果FindOne没有返回任何内容（并且没有抛出任何异常），那么它告诉您FindOne没有找到符合您条件的任何结果。

或者，FindOne抛出异常（通常是一个ComException），您可以使用comexception错误代码来查找正在发生的事情。

您可以启动WireShark，禁用，密封和安全绑定，并嗅探应用程序中的数据包。您将看到对您的搜索的LDAP响应。

代码无法搜索AD

2 个答案: