C# System.DirectoryServices.AccountManagement 未知错误 (0x80005000) UserPrincipal.IsMemberOf()
类似于以下 MSDN 线程中的问题:http://social.msdn.microsoft.com/Forums/en-MY/csharplanguage/thread/4c9fea6c-1d0a-4733-a8ac-e3b78d10e999
我正在尝试验证是否给定用户是某个组的成员,而我们现有的功能解决方案太慢(13-16 秒),我正在尝试加快速度。我目前有:
public bool IsMemberAD(string userName, string groupName)
{
var pc = new System.DirectoryServices.AccountManagement.PrincipalContext(System.DirectoryServices.AccountManagement.ContextType.Domain);
var user = System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(pc, System.DirectoryServices.AccountManagement.IdentityType.SamAccountName,
userName.ToLower());
var group = System.DirectoryServices.AccountManagement.GroupPrincipal.FindByIdentity(pc, groupName);
if (group == null || user == null) return false;
return user.IsMemberOf(group);
}
有趣的是,当用户不直接位于组中,而是目标组内的组的成员时,它只会返回错误。
例如:
Steve 和 Sam 是两个用户,GroupParent 和 GroupChild 是两个组。 Steve 和 GroupChild 是 GroupParent 的成员。 Sam 是 GroupChild 的成员。如果我在 (Steve, GroupParent) 上调用此函数,它将返回 true。如果我在 (Sam, GroupParent) 上调用它,则会收到错误。如果我在(“fdkjskghkf”,GroupParent)上调用它,它会返回 false。
我在上面链接了一篇有类似问题的文章,但他的解决方案对我不起作用,我仍然遇到同样的错误。有想法吗?
Similar to the problem in the following MSDN thread: http://social.msdn.microsoft.com/Forums/en-MY/csharplanguage/thread/4c9fea6c-1d0a-4733-a8ac-e3b78d10e999
I am trying to verify whether or not a given user is a member of a group, and our existing functional solutions are too slow (13-16 seconds) and I'm trying to speed it up. I currently have:
public bool IsMemberAD(string userName, string groupName)
{
var pc = new System.DirectoryServices.AccountManagement.PrincipalContext(System.DirectoryServices.AccountManagement.ContextType.Domain);
var user = System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(pc, System.DirectoryServices.AccountManagement.IdentityType.SamAccountName,
userName.ToLower());
var group = System.DirectoryServices.AccountManagement.GroupPrincipal.FindByIdentity(pc, groupName);
if (group == null || user == null) return false;
return user.IsMemberOf(group);
}
What makes this interesting is that it only returns an error when the user is not in the group directly, but rather a member of a group that is within the target group.
For example:
Steve and Sam are two users, and GroupParent and GroupChild are two groups. Steve and GroupChild are members of GroupParent. Sam is a member of GroupChild. If I call this function on (Steve, GroupParent), it returns true. If I call it on (Sam, GroupParent), I get an error. If I call it on ("fdkjskghkf", GroupParent) it returns false.
I linked an article above with similar issues, but his solution did not work for me, I still got the same error. Ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
感谢 Jon Theriault 此处 下面的代码为我解决了这个问题。
Thanks to Jon Theriault here the following code fixed this problem for me.
我记得当我编写类似的代码时,我确实遇到了一些奇怪的问题。我不确定您的呼叫失败的确切原因,但您可以扭转问题并执行以下操作:
I remember when I wrote similar code I did run into some strange issues. I'm not sure exactly why your call is failing but you can turn your problem around and do something like:
你能尝试这样的事情吗:
Can you try somethig like this :
如果有人有兴趣的话。使用具有以下过滤器的 DirectorySearcher 大约快 60%。
字符串过滤器 = string.Format("(&(distinguishedName={1})(memberof:1.2.840.113556.1.4.1941:={0}))", dnOfUser, dnOfGroup);
过滤器将向上遍历,而不仅仅是用户的父级。
If anyone is interested. Using DirectorySearcher with the following filter is approx 60% faster.
string filter = string.Format("(&(distinguishedName={1})(memberof:1.2.840.113556.1.4.1941:={0}))", dnOfUser, dnOfGroup);
The filter will traverse upwards and not just the parent of the user.
GetAuthorizationGroups() 找不到嵌套组。
要真正获取给定用户是包含的嵌套组的成员的所有组,请尝试以下操作:
使用 Try/Catch 因为我在一个非常大的 AD(50 万个对象)中遇到了一些异常,其中 200 个组中有 2 个,因为我的一些 SID(翻译确实) SID -> 名称转换)不再可用。
在我们庞大的广告中只需要< 1秒。
GetAuthorizationGroups() does not find nested groups.
To really got all groups a given user is member of included nested groups try this:
Use Try/Catch because I had some exceptions in a very large AD (half a million objects) with 2 out of 200 groups because my some SIDs (Translate does SID -> Name conversion) were no longer available.
In our huge AD is only takes < 1 second.