Principal.IsInRole("AD组名称")始终返回false,不会引发任何异常 [英] Principal.IsInRole("AD Group Name") always returns false, no exceptions thrown

查看:51
本文介绍了Principal.IsInRole("AD组名称")始终返回false,不会引发任何异常的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Web API控制器中,我需要使用包含来自另一个林中多个域的成员的AD组来确定角色成员身份.

In a Web API controller I needed to determine the role membership using an AD group that contained members from multiple domains in another forest.

this.RequestContext.Principal.IsInRole(roleName)

返回false,找不到错误指示.不过, did 上面的代码可与其他广告组一起使用.然后,我修改了代码以遍历有问题的组并收到异常.

returned false and no indication of an error could be found. The code above did work with other AD groups, though. I then modified the code to loop through the group in question and received an exception.

GroupPrincipal group = GroupPrincipal.FindByIdentity(ctx, roleName);
if (group != null)
{
    foreach (Principal p in group.GetMembers())
    {
         if (p != null && currentUserPrincipal.UserPrincipalName == p.UserPrincipalName) 
        {
            roles.Add(roleName);
            break;
         }
      }


 }

指定的目录服务属性或值不存在.

The specified directory service attribute or value does not exist.

我确定这是从特定域向组成员抛出的异常.我删除了所述个人,并正常执行了代码.我添加了与第一个域相同的域的另一个帐户,并返回了错误.

I determined it was the exception was being thrown on a group member from a specific domain. I removed said individual and code executed normally. I added another account form the same domain as the first and the error returned.

推荐答案

搜索给定的错误消息,我发现以下 SO问题和答案.最重要的答案是这样.

Searching for the given error message I found the following SO question and answer. The top answer states.

当省略 PrincipalContext 类中所述的LDAP容器属性时,运行该代码的用户必须对默认的 User 容器(即 CN= Users,DC = yourDomain,DC = COM )和 Computers 容器(即 CN = Computers,DC = yourDomain,DC = COM ).

When omitting the LDAP container property as described in PrincipalContext Class, the user running the code must have read permissions to both the default User Container (i.e. CN=Users,DC=yourDomain,DC=COM) and the Computers Container (i.e. CN=Computers,DC=yourDomain,DC=COM).

使用Active Directory用户和计算机我浏览了问题域的AD,并且看不到任何 Computers 容器.我联系了IS并告知他们这一点,他们将目录恢复到良好状态.那时, this.RequestContext.Principal.IsInRole(roleName)可以正常工作,并且我能够评估角色成员身份.

Using Active Directory Users and Computers I browsed the AD of the problem domain and could not see any Computers container. I contacted IS and informed them of this and they restored the directory to a good state. At that point this.RequestContext.Principal.IsInRole(roleName) worked as expected and I was able to evaluate role membership.

天哪!这也解决了SharePoint用户配置文件服务无法同步来自同一域中成员的用户详细信息的问题.我已经尝试了两年来跟踪用户配置文件错误的原因,但没有成功.

OMG! This also fixed an issue with the SharePoint user profile service not syncing user details from members in the same domain. I have been trying for two years to track down the cause of the the user profile error with no success.

这篇关于Principal.IsInRole("AD组名称")始终返回false,不会引发任何异常的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆