本文介绍了UserPrincipals.GetAuthorizationGroups同时枚举组时发生错误(1301)。升级到Server 2012的域控制器后的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

研究:

Similar问题的解决方法,而不是实际的解决方案存在的问题

Similar问题指向微软终点更新为罪魁祸首

以上链接是最适合我的问题,我也创建后,这个帖子被浏览堆栈溢出列出每一项类似的问题,只有上面提到的问题,适合我的问题。

背景:

我一直在使用 UserPrincipal.GetAuthorizationGroups 为特定的页面访问运行权限服务器IIS 7.5 2008 R2在C#.NET 4.0 Web表单的网站2个半年份。在2013年5月15日,我们删除了主域控制器上运行Server 2008(不R2)和带Server 2012的域控制器取代了它。第二天,我们开始收到下面列出的例外。

我使用的主要背景的窗体身份验证。用户名/密码握手成功,身份验证cookie被正确设置,但随后的主体上下文调用,还要求 UserPrincipal.GetAuthorizationGroups 间歇性失败。我们已经解决了出现在Server 2012的域控制器的几个BPA问题上,但是还没有解决这个问题。我也设立了两个独立的服务器上运行一个cron。虽然他们都运行相同的code基地的两台服务器将无法在不同的时间组的SID的分辨率。 (一个开发环境和生产环境)。

这个问题暂时解决本身在Web服务器重新启动,并且还开发服务器上会在12小时中不发挥作用后自行解决。生产服务器通常会停止正常工作,直到重新启动不解决本身。

在这一点上我想改进网络以及新的DC在针对特定的域控制器的cron和使用标准的LDAP查询当前不能产生更多有针对性的例外次。到目前为止,我们已经发现了一台Web服务器,没有任何图案,在它失败的日子,但它大致会在12小时内恢复。最新的研究结果表明8 AM-8PM的组SID解析失败则恢复正常,几天后就会失效,在晚上8点和恢复在上午8点,然后运行罚款,另外12个小时,失败了。我们希望看到,如果这只是一个特定的服务器之间的通信问题,或者看它是否是一整套的域控制器。

例外:

 异常信息:
异常类型:PrincipalOperationException
而枚举组时发生错误(1301):异常消息。
该工作组的SID无法解析。
在System.DirectoryServices.AccountManagement.SidList.TranslateSids(字符串对象,IntPtr的[] pSids)
在System.DirectoryServices.AccountManagement.SidList..ctor(SID_AND_ATTR [] sidAndAttr)
在System.DirectoryServices.AccountManagement.AuthZSet..ctor(字节[] userSid,NetCred凭据,ContextOptions contextOptions,串flatUserAuthority,StoreCtx userStoreCtx,对象userCtxBase)
在System.DirectoryServices.AccountManagement.ADStoreCtx.GetGroupsMemberOfAZ(首席P)
在System.DirectoryServices.AccountManagement.UserPrincipal.GetAuthorizationGroups()
 

问:

鉴于上述信息,没有任何人有任何想法,为什么退役的Windows Server 2008(而不是R2),并实施新的Server 2012的DC会导致 UserPrincipal.GetAuthorizationGroups 失败与1301 SID解析错误?在消除可能的原因想法也将是AP preciated。

免责声明:

这是我的第一篇文章,以堆栈溢出,我经常在这里的研究,但还没有加入讨论,直至现在。请原谅我,如果我在其他地方发布,并随时发布前指出更好的步骤。

更新13-JUN-2013:

在六月12日我处理不处理导致此问题的项目的可能性。时限已经过短,以确定是否调整code已经解决了该问题,但我会继续更新,因为我们努力找到解决的,这样也许如果幸运的话这里有人能伸出援助之手。

原code

 公共BOOL isGroupMember(用户名字符串,ArrayList的群组列表)
    {
        布尔有效=虚假的;

            PrincipalContext CTX =新PrincipalContext(ContextType.Domain,domain_server +.domain.org:636,空,ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

            //发现在身份存储用户
            UserPrincipal用户=
                UserPrincipal.FindByIdentity(
                    CTX,
                    用户名);

            //获取组的用户主体和
            //将结果存储在一个PrincipalSearchResult对象
            PrincipalSearchResult<主>组=
                user.GetAuthorizationGroups();

            //显示组的姓名该
            //用户所属
            的foreach(主要组群)
            {
                的foreach(在GROUPLIST串组名)
                {
                    如果(group.ToString()==组名)
                    {
                        有效= TRUE;
                    }
                }

            }
        返回有效的;
    }
 

更新code

 公共BOOL isGroupMember(用户名字符串,ArrayList的GROUPLIST,串domain_server)
        {
        布尔有效=虚假的;

            尝试
            {

                使用(PrincipalContext CTX =新PrincipalContext(ContextType.Domain,domain_server +.domain.org:636,空,ContextOptions.Negotiate | ContextOptions.SecureSocketLayer))
                {

                    //发现在身份存储用户
                    UserPrincipal用户=
                        UserPrincipal.FindByIdentity(
                            CTX,
                            用户名);

                    尝试
                    {
                        //获取组的用户主体和
                        //将结果存储在一个PrincipalSearchResult对象
                        使用(PrincipalSearchResult&其中;主基团= user.GetAuthorizationGroups())
                        {
                            //显示组的姓名该
                            //用户所属

                            的foreach(主要组群)
                            {
                                的foreach(在GROUPLIST串组名)
                                {

                                    如果(group.ToString()==组名)
                                    {
                                        有效= TRUE;
                                    }
                                }

                                group.Dispose();

                            }
                        } //结束使用-2
                    }
                    抓住
                    {
                        log_gen(任意信息);
                        返回false;
                    }
                } //结束使用-1
            }
            抓住
            {
                log_gen(任意信息);
                返回false;
            }

        返回有效的;

    }
 

解决方案

我刚刚碰到同样的问题,我已成功地跟踪可能会有所帮助的信息;如上面我们已经看到了这个问题,在域控制器运行Server 2012 - 首先与客户的部署,然后复制自己的网络上

一些实验,我们发现,我们的code将运行罚款Server 2012中,但击中时,客户机系统正在运行Server 2008的关于什么是在这里被发现发生的关键信息1301错误code后:

<一个href="http://translate.google.co.uk/translate?hl=en&sl=de&tl=en&u=http://blogs.technet.com/b/deds/archive/2013/08/12/probleme-mit-dem-umwandeln-von-sids-in-namen.aspx">MS从官方博客德国翻译

的修补程序提到在下面的链接已经修复了这个问题在我们的测试系统

SID S-1-18-1和SID S-1-18-2不能映射

希望这是对别人有帮助的!正如许多人所指出的这个方法调用似乎相当脆弱,我们可能会看到实施一些替代方法之前,我们打等问题。

加里

Research:

Similar Issue with workaround, but not actual solution to existing problem

Similar issue pointing to Microsoft End Point update as culprit

The above links are the most suited to my problem, I have also viewed every similar question listed by Stack Overflow upon creating this post, and only the above referenced questions fit my issue.

Background:

I have been using UserPrincipal.GetAuthorizationGroups for permissions for specific page access running IIS 7.5 on Server 2008 R2 in a C#.NET 4.0 web forms site for 2 and a half years. On May 15 2013 we removed a primary Domain controller running Server 2008 (not r2) and replaced it with a Server 2012 Domain Controller. The next day we started receiving the exception listed below.

I use Principal Context for Forms Authentication. The username/pass handshake succeeds and the auth cookie is properly set, but the subsequent Principal Context call that also calls UserPrincipal.GetAuthorizationGroups fails intermittently. We've resolved a few BPA issues that appeared in the Server 2012 Domain Controller but this has yet to resolve the issue. I also instituted a cron that runs on two separate servers. The two servers will fail at Group SID resolution at different times though they are running the same code base. (A dev environment and production environment).

The issue resolves itself temporarily upon web server reboot, and also on the dev server it will resolve itself after 12 hours of not functioning. The production server will usually stop functioning properly until a reboot without resolving itself.

At this point I am trying to refine the cron targeting specific Domain Controllers in the network as well as the new DC and using the standard LDAP query that is currently failing to yield more targeted exception times. Thus far we've found on one web server that there is no pattern to the days at which it fails, but it will recover within roughly 12 hours. The latest results show Group SID resolution failure between 8AM-8PM then it recovers, several days later it will fail at 8pm and recover at 8am then run fine for another 12 hours and fail again. We are hoping to see if it is just a specific server communication issue or to see if it is the entire set of Domain Controllers.

Exception:

Exception information:
Exception type: PrincipalOperationException
Exception message: An error (1301) 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(SID_AND_ATTR[] sidAndAttr)
at System.DirectoryServices.AccountManagement.AuthZSet..ctor(Byte[] userSid, NetCred credentials, ContextOptions contextOptions, String flatUserAuthority, StoreCtx userStoreCtx, Object userCtxBase)
at System.DirectoryServices.AccountManagement.ADStoreCtx.GetGroupsMemberOfAZ(Principal p)
at System.DirectoryServices.AccountManagement.UserPrincipal.GetAuthorizationGroups()

Question:

Given the above information, does anyone have any idea why decommissioning the Windows Server 2008 (not r2) and implementing a new Server 2012 DC would cause UserPrincipal.GetAuthorizationGroups to fail with the 1301 SID resolution error?Ideas on eliminating possible causes would also be appreciated.

Disclaimer:

This is my first post to Stack Overflow, I often research here but have not joined in discussions until now. Forgive me if I should have posted elsewhere and feel free to point out better steps before posting.

UPDATE 13-JUN-2013:

On the 12th of June I addressed the possibility of items not disposed causing the issue.The time frame has been too short to determine if the adjusted code has fixed the issue, but I will continue to update as we work towards a resolution such that maybe with any luck someone here can lend a hand.

Original Code

    public bool isGroupMember(string userName, ArrayList groupList)
    {
        bool valid = false;

            PrincipalContext ctx = new PrincipalContext(ContextType.Domain, domain_server + ".domain.org:636", null, ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

            // find the user in the identity store
            UserPrincipal user =
                UserPrincipal.FindByIdentity(
                    ctx,
                    userName);

            // get the groups for the user principal and
            // store the results in a PrincipalSearchResult object
            PrincipalSearchResult<Principal> groups =
                user.GetAuthorizationGroups();

            // display the names of the groups to which the
            // user belongs
            foreach (Principal group in groups)
            {
                foreach (string groupName in groupList)
                {
                    if (group.ToString() == groupName)
                    {
                        valid = true;
                    }
                }

            }
        return valid;
    }

Updated Code

        public bool isGroupMember(string userName, ArrayList groupList, string domain_server)
        {
        bool valid = false;

            try
            {

                using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain, domain_server + ".domain.org:636", null, ContextOptions.Negotiate | ContextOptions.SecureSocketLayer))
                {

                    // find the user in the identity store
                    UserPrincipal user =
                        UserPrincipal.FindByIdentity(
                            ctx,
                            userName);

                    try
                    {
                        // get the groups for the user principal and
                        // store the results in a PrincipalSearchResult object
                        using (PrincipalSearchResult<Principal> groups = user.GetAuthorizationGroups())
                        {
                            // display the names of the groups to which the
                            // user belongs

                            foreach (Principal group in groups)
                            {
                                foreach (string groupName in groupList)
                                {

                                    if (group.ToString() == groupName)
                                    {
                                        valid = true;
                                    }
                                }

                                group.Dispose();

                            }
                        }//end using-2
                    }
                    catch
                    {
                        log_gen("arbitrary info");
                        return false;
                    }
                }//end using-1
            }
            catch
            {
                log_gen("arbitrary info");
                return false;
            }

        return valid;

    }
解决方案

I have just run into this same issue and the info I have managed to track down may be helpful; as above we have seen this problem where the domain controller is running Server 2012 - firstly with a customer deployment and then replicated on our own network.

After some experimentation we found that our code would run fine on Server 2012, but hit the 1301 error code when the client system was running Server 2008. The key information about what was happening was found here:

MS blog translated from German

The hotfix referred to in the link below has fixed the problem on our test system

SID S-1-18-1 and SID S-1-18-2 can't be mapped

Hope this is helpful for someone! As many have noted this method call seems rather fragile and we will probably look at implementing some alternative approach before we hit other issues.

Gary

这篇关于UserPrincipals.GetAuthorizationGroups同时枚举组时发生错误(1301)。升级到Server 2012的域控制器后的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-06 16:44