对于遇到同样问题的人来说,这不是一个问题。
发生以下错误:
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建议使用以下解决方法代码,但由于重复调用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
答案 0 :(得分: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
答案 1 :(得分:2)
帐户管理库存在许多令人遗憾的缺陷,这只是众多中的另一个......
要使事情稍微快一点,您可以做的一件事就是调整LDAP查询,以便它同时检查组成员资格和对象类型作为查询的一部分而不是循环。老实说,我怀疑它会有很大的不同。
查询的大部分灵感来自How to write LDAP query to test if user is member of a group?。
查询:(&(!objectClass=foreignSecurityPrincipal)(memberof=CN=YourGroup,OU=Users,DC=YourDomain,DC=com))
注意:这是一个未经测试的查询......
如果有一种方法可以在AccountManagement中运行LDAP查询(我的另一个抱怨),那么这将是您的麻烦的结束,因为您可以运行查询并让AccountManagement从那里获取它,但此选项不存在...
根据个人经验,如果您坚持使用AccountManagement,我看不到任何其他选择。您可以做的是转储AccountManagement并仅使用DirectoryServices。在引擎盖下,所有AccountManagement都会包装DirectoryEntry对象,你可以编写一些辅助类来做类似的事情。
答案 2 :(得分:0)
作为替代方案,您可以使用此代码来获取成员:
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);
}