User.IsInRole("假组")导致"主域和可信域之间的信任关系失败"

时间:2014-03-19 21:13:41

标签: active-directory windows-authentication trust isinrole

我有一个MVC 3应用程序,使用Windows身份验证和声明使用WIF 4.5。

通过AD组中的成员资格(当前)控制对应用程序的访问:

<deny users="?" />
<allow roles="domain\somegroup" />
<deny users="*" />

除AD组外,我们还需要添加自定义角色。 (此应用程序正在从Forms转换为Windows身份验证)

为了支持这些自定义角色(直到它们在AD中管理),我们将它们添加为ClaimTypes.GroupSid声明给用户,以便利用[Authorize("ADMIN")]User.IsInRole("ADMIN")的现有代码继续运行:

Application_PostAuthenticateRequest(object sender, EventArgs e)
{
    var identity = ClaimsPrincipal.Current.Identity as WindowsIdentity;
    var roles = userDAL.GetRoles(identity.Name);
    foreach(var role in roles)
    {
        identity.AddClaim(new Claim(ClaimTypes.GroupSid, role));
    }
}

这一切都按预期工作。

除非当前用户不是某个自定义角色的成员(例如ADMIN) 且该角色在AD中也不存在

我们在Controller Action Methods上使用[Authorize("ADMIN")],并根据场景使用User.IsInRole("ADMIN")的各种实例。这是在发生错误并且应用程序爆炸的情况下。

AD基础架构正处于升级/迁移过程中。我不知道那里的所有细节,但我知道有一些域名,据说他们之间有信任,基础设施人员已经提到这些信任关系正在运行。

所以,我想我想知道两件事:

  1. 这似乎不是我们的代码应该处理的东西。那么域名真的可能出现什么问题?我可以找出信任关系失败的“可信”域吗?

  2. 解决此问题的最佳方法是什么?我不喜欢写辅助方法的想法&amp; Authorize()子类只是为了捕获此异常。

2 个答案:

答案 0 :(得分:1)

请转到inetmgr,站点,默认网站,站点名称,iis组,双击身份验证,禁用匿名身份验证,然后重置应用程序池。

这似乎发生在Windows无法破译授权下定义的角色时,允许角色&#39; web.config文件中的标记。用于测试注释掉web.config文件中的自定义角色标记。混合使用Forms身份验证和Windows身份验证时,似乎会出现此问题。魔术在Global.asax文件Application_PostAuthenticateRequest方法问题,请使用窗体身份验证时,就可以把User.Identity为FormsIdentity,然后创建从FormsIdentity票务定制身份,然后创建自定义的身份定制的原则,您都能够将CustomPrincipal附加到当前用户和当前主体,即

Dim fIdent As FormsIdentity = CType(User.Identity, FormsIdentity)
Dim ci As New CustomIdentity(fIdent.Ticket) 
Dim cp As New CustomPrincipal(ci)
HttpContext.Current.User = cp : Thread.CurrentPrincipal = cp

对于IIS,您希望启用Forms身份验证和匿名身份验证,其他所有内容都应禁用。使用Windows身份验证时,Global.asax文件Application_PostAuthenticateRequest方法可以直接从User.Identity创建自定义原则,即。

Dim cp As New CustomPrincipal(User.Identity)
HttpContext.Current.User = cp : Thread.CurrentPrincipal = cp

在这种情况下,IIS设置应该是Windows身份验证,并启用ASP.Net模拟,其他所有内容都被禁用。

将这些身份验证方法混淆会导致主域和受信任域之间的信任关系失败,并且&#39;错误,因为如果你的Application_PostAuthenticateRequest方法因某些原因无法实施CustomPrinciple那么Windows会尝试使用内置的IsInRole功能检查,而不是使用自定义的IsInRole是在隐藏文件的CustomPrinciple代码对域角色的作用。

这是一篇有用的文章和链接:

http://www.codeproject.com/Articles/8819/Authorize-and-authenticate-users-with-AD https://msdn.microsoft.com/en-us/library/ff647405.aspx
https://support.microsoft.com/en-us/kb/306359

答案 1 :(得分:0)

如果您拥有的信任域配置不可用,IsInRole也会在信任域中搜索该组,并且如果该信任域不可用,则会抛出信任豁免。