从 Active Directory 读取用户授权组答案

【问题标题】：Read user authorization groups from Active Directory从 Active Directory 读取用户授权组
【发布时间】：2010-12-23 13:11:52
【问题描述】：

在我们的系统中，我们以两种略有不同的方式从 Active Directory 中读取用户安全组。在一种情况下，AD 返回的组列表缺少域本地组。 GetAuthorizationGroups () 的响应取决于使用的 PrincipalContext。在失败的情况下 GetAuthorizationGroups() 将只返回全局组。结果是缺少 AD 中的所有域本地组。谁能解释一下为什么？

失败的解决方案：

PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "our.domain.net");

var userPrincipal = UserPrincipal.FindByIdentity(ctx, IdentityType.UserPrincipalName, "userB");

PrincipalSearchResult<Principal> groups = userPrincipal.GetAuthorizationGroups();

在这种情况下，进程由“UserA”执行。 “UserA”是域“our.domain.net”的成员。 “UserA”是与工作解决方案中特定标识的用户完全相同的用户。因此，PrincipalContext 应该与工作解决方案中的 PrincipalContext 相同。此解决方案中 GetAuthorizationGroups() 的响应缺少来自 AD 的域本地组。

工作解决方案：

PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "our.domain.net", "UserA", "PasswordA");

var userPrincipal = UserPrincipal.FindByIdentity(ctx, IdentityType.UserPrincipalName, "userB");

PrincipalSearchResult<Principal> groups = userPrincipal.GetAuthorizationGroups();

在这种情况下，调用用户在创建主体上下文时通过使用名称和密码来明确标识。在这种情况下，AD 返回用户所属的所有组。这也是我希望从失败的解决方案中看到的行为。在某些情况下，我没有 UserA 的用户密码，因此无法选择有效的解决方案。

请帮助我理解为什么失败的解决方案没有返回用户所属的所有组。

【问题讨论】：

您有多个域吗？你在什么操作系统上？它可能与UAC有关。我会尝试关闭 UAC 并重试（请记住在关闭 UAC 后重新启动计算机）。仅供参考，ValidateCredentials() 并不能帮助您执行 GetAuthorizationGroups()，以防您认为这样做
感谢您的回复哈维。这些问题是在我们的测试实验室进行系统测试时发现的。测试系统由一个域和多个域控制器组成。问题描述中的代码由 Windows 2003 服务器执行。在我们的产品发布之前，我们还必须支持多个域和 Windows 2008 服务器。我已经请我们的 Windows 服务器安装专家对 UAC 进行了一些实验。他咕哝了几句“这不是 2008 年的故事吗”。无论如何，他都要调查一下。我会尽快发布他的回复。最好的问候，贡纳尔

标签： c# .net active-directory

【解决方案1】：

“它错过了来自 AD 的域本地组”，因为您可能正在使用 foreach 循环迭代生成的 groups，并且您会得到 NoMatchingPrincipalException 异常，其中一个组是用户没有读取权限，此时它停止迭代，无法获取其余组。

作为一种解决方案，您可以使用以下迭代器（foreach 结构背后的代码）来获取所有其余组：

var enumerator = groups.GetEnumerator();                
while (enumerator.MoveNext())
{
    try
    {
        var e = enumerator.Current;
        listView1.Items.Add(e.Name);
    }
    catch (NoMatchingPrincipalException)
    {
    }
}

【讨论】：

【解决方案2】：

我们终于找到了问题所在。结果证明根本不是编码问题。奇怪的行为是由 Active Directory 中的错误域级别引起的。

必须将域级别设置为“2003 功能级别”

现在一切正常。

【讨论】：