One of the most often heard requests before I took over the project and shortly after was that people wanted nested groups searched (User is a member of the AD Group Sales and Sales is a member of the AD Group Staff so when the roles are synchronized the user should be added to the Sales DNN Security Role). When I implemented that I didn't do it in the ideal way as it was take the DNN Role and then searching the AD for A) was the user a member of that group and B) were there any nested groups and was the user a member of that group. So to use my earlier example it would search for Staff and then see that Sales was part of the staff group and then search Staff to see if the user was a member. It seems simple enough but if there are a lot of groups and nested groups then it's going to take time and I think what's happening in your case is it's timing out and causing these problems.

So, there's two things you can try. One is to disable Synchronize Roles and see if the problem goes away (I really recommend trying this before trying the second option) and the second option is to try the 01.00.04 beta (http://dnn.gmss.org) which is the same version as I've submitted to the DNN Release Tracker. I changed the code significantly for the AddUserRoles. Along with the problem mentioned above the code there was a lot of SQL traffic to the database especially if there were a lot of DNN roles setup (the way the roles were synchronizing is that the user was getting deleted out of any roles they belonged to and then re-added).

What I did for the .04 beta was the following: Make a call to the database to get an arraylist of all the DNN Roles on the portal; make a call to the database to get an arraylist of the roles the user belongs to; make a call to the Active Directory to get an arraylist of the user's MemberOf property (MemberOf contains the roles a user belongs to and any parent roles of those roles). Then a comparison is done through the arraylists and a user is deleted from only those DNN Security Roles they no longer belong to and added only to those Roles that they need to be added to. I haven't done an actual time comparison between the two versions but I have noticed a significant change on our production server.

As for people getting logged out and using a javascript redirect to WindowsSignin. Well, hopefully we can track down the cause of the problem (if it's not what I think it is above) What I've done is just used a Text/HTML module on the pages that a user must be logged in to see and provided a link to the WindowsSignin.aspx (example at http://www.bus.nait.ca/main/Resources/IDrive.aspx). This isn't ideal either but users sometimes click Logout and this is a quick way to get them logged back in.