14

对于遇到同样问题的人来说，这与其说是一个问题，不如说是信息。

出现以下错误：

System.DirectoryServices.AccountManagement.PrincipalOperationException: An error (87) occurred while enumerating the groups. The group's SID could not be resolved. 
at System.DirectoryServices.AccountManagement.SidList.TranslateSids(String target, IntPtr[] pSids) 
at System.DirectoryServices.AccountManagement.SidList.ctor(List`1 sidListByteFormat, String target, NetCred credentials) 
at System.DirectoryServices.AccountManagement.ADDNLinkedAttrSet.TranslateForeignMembers()

当运行以下代码并且组或子组包含 ForeignSecurityPrincipal 时：

private static void GetUsersFromGroup()
{
    var groupDistinguishedName = "CN=IIS_IUSRS,CN=Builtin,DC=Domain,DC=com";
    //NB: Exception thrown during iteration of members rather than call to GetMembers.    
    using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "Domain", "Username", "Password"))
    {
        using (GroupPrincipal groupPrincipal = GroupPrincipal.FindByIdentity(ctx, IdentityType.DistinguishedName, groupDistinguishedName))
        {                    
            using (var searchResults = groupPrincipal.GetMembers(true))//Occurs when false also.
            {
                foreach (UserPrincipal item in searchResults.OfType())
                {
                    Console.WriteLine("Found user: {0}", item.SamAccountName)
                }
            }
        }
    }
}

我向 Microsoft 拨打了支持电话，他们已确认这是一个问题。内部提出了一个错误，但尚未确认是否会修复此错误。

Microsoft 建议使用以下解决方法代码，但由于对 UserPrincipal.FindByIdentity 的重复调用，它在具有大量用户的组上表现不佳。

class Program
{
    //"CN=IIS_IUSRS,CN=Builtin,DC=dev-sp-sandbox,DC=local"; //TODO MODIFY THIS LINE ACCORDING TO YOUR DC CONFIGURATION

    static void Main(string[] args)
    {
        if (args.Length != 1)
        {
            Console.WriteLine("Usage: ListGroupMembers \"group's DistinguishedName\"");
            Console.WriteLine("Example: ListGroupMembers \"CN=IIS_IUSRS,CN=Builtin,DC=MyDomain,DC=local\"");
            return;
        }

        string groupDistinguishedName = args[0];

        PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "dev-sp-dc", "Administrator", "Corp123!");
        List<UserPrincipal> users = new List<UserPrincipal>();
        listGroupMembers(groupDistinguishedName, ctx, users);

        foreach (UserPrincipal u in users)
        {
            Console.WriteLine(u.DistinguishedName);
        }
    }

    //Recursively list the group's members which are not Foreign Security Principals
    private static void listGroupMembers(string groupDistinguishedName, PrincipalContext ctx, List<UserPrincipal> users)
    {
        DirectoryEntry group = new DirectoryEntry("LDAP://" + groupDistinguishedName);
        foreach (string dn in group.Properties["member"])
        {

            DirectoryEntry gpMemberEntry = new DirectoryEntry("LDAP://" + dn);
            System.DirectoryServices.PropertyCollection userProps = gpMemberEntry.Properties;

            object[] objCls = (userProps["objectClass"].Value) as object[];

            if (objCls.Contains("group"))
                listGroupMembers(userProps["distinguishedName"].Value as string, ctx, users);

            if (!objCls.Contains("foreignSecurityPrincipal"))
            {                    
                UserPrincipal u = UserPrincipal.FindByIdentity(ctx, IdentityType.DistinguishedName, dn);
                if(u!=null)  // u==null for any other types except users
                    users.Add(u);
            }
        }                 
    }
}

可以修改上述代码以查找导致组问题的外部安全主体。

Microsoft 提供了有关外国安全主体的以下信息：

这是 AD 中的一类对象，它代表来自外部源的安全主体（因此是另一个林/域或下面的“特殊”帐户之一）。该类记录在这里：http: //msdn.microsoft.com/en-us/library/cc221858 (v=PROT.10).aspx 容器记录在这里：http: //msdn.microsoft.com/en -us/library/cc200915(v=PROT.10).aspx FSP 不是 AD 中的真实对象，而是指向位于不同的受信任域/林中的对象的占位符（指针）。它也可以是“特殊身份”之一，这是一堆众所周知的帐户，它们也被归类为 FSP，因为它们的 SID 与域 SID 不同。例如，此处记录的匿名、经过身份验证的用户、批处理和其他几个帐户： http://technet.microsoft.com/en-us/library/cc779144(v=WS.10).aspx

4

3 回答 3

4

当然这是一个旧线程，但可能会对某人有所帮助。我使用下面的代码块来解决问题。Principal 类公开了一个名为 StructuralObjectClass 的属性，它告诉您该主体的 AD 类是什么。我用它来确定对象是否是用户。GetMembers(true) 递归搜索相关 groupPrincipal 中的所有嵌套成员。

希望这可以帮助某人。

    List<UserPrincipal> members = new List<UserPrincipal>();
    foreach (var principal in groupPrincipal.GetMembers(true))
    {
        var type = principal.StructuralObjectClass;
        if (type.Contains("user"))
            members.Add((UserPrincipal)principal);
    }

谢谢，R

于 2016-08-26T01:46:49.770 回答
2

作为替代方案，您可以使用此代码获取成员：

var pth = "LDAP://ex.invalid/CN=grpName,OU=Groups,OU=whatever,DC=ex,DC=invalid";
var dirEntry = new DirectoryEntry(pth);
var members = dirEntry.Invoke("Members"); //COM object
foreach (var member in (IEnumerable)members) {
    var userEntry = new DirectoryEntry(member); //member is COM object
    var sid = new SecurityIdentifier((byte[]) userEntry.InvokeGet("objectSid"), 0);
    var typ = typeof(System.Security.Principal.NTAccount);
    var account = (NTAccount)sid.Translate(typ);
    Console.WriteLine(account.Value);
}
于 2015-04-08T18:42:26.833 回答
2

帐户管理库有许多令人痛心的缺陷，这只是众多缺陷中的另一个......

您可以做的一件稍微加快速度的事情是调整您的 LDAP 查询，以便它同时检查组成员资格和对象类型作为查询的一部分，而不是在循环中。老实说，我怀疑它会产生很大的不同。

查询的大部分灵感来自 How to write LDAP query to test if user is a group? .

询问： (&(!objectClass=foreignSecurityPrincipal)(memberof=CN=YourGroup,OU=Users,DC=YourDomain,DC=com))

注意：这是一个未经测试的查询...

如果有一种方法可以在 AccountManagement 中运行 LDAP 查询（我的另一个抱怨），那么这将结束您的麻烦，因为您可以运行查询并让 AccountManagement 从那里获取它，但是这个选项不存在......

根据个人经验，如果您坚持使用 AccountManagement，我看不到任何其他选择。您可以做的是转储 AccountManagement 并仅使用 DirectoryServices。在幕后，所有 AccountManagement 所做的就是包装 DirectoryEntry 对象，您可以编写一些帮助类来做类似的事情。

于 2012-06-01T17:49:16.383 回答