Hey Mike,
I thought I would breathe new life into a dead thread. I work for a company that is several thousand users across the entire USA and has offices in parts of GB and AU. Our problem with the module was mostly scalability. We even purchased support from DNN and the ball got dropped by you guys. So left to my own devices we developed our own plan.
There are more than 80 groups in our AD that are sync'd with DNN roles. The problem is that the way the code is written, the provider hits the AD for each specific role to see if the user belongs to that AD group as it builds the users permissions during login. So multiply that time 2800+ users, and the "Upgrade" crushed our global catalog server. And believe me our network is SOTA - think APC InfraStruXure with quad AC Units. Our guys are among the best there is. So network issues are really out of the question.
Actually it was worse than that. We literally have over 8000 organizational units in our AD and the AD is only 3 levels deep. The AD provider "out of the box" was hitting the AD an average of 13 times per user - some more some less. The authentication was taking upwards of 11 seconds per user in controlled testing. Come to find out that everyone combined was hitting the AD somewhere in the neighborhood of 36400 times (average) just to see our homepage... No wonder our GC server was getting crushed.
So how did we fix it? We created a table called Roles_ActiveDirectory with a single column RoleID. Then I changed the AD provider code to look at the table for the 80 odd roles that we need to synchronize. The provider now hits the AD 3 times per user. 1 time to authenticate, 1 time to enter the authorization code, and 1 time to pull all the AD roles and build them into a generic list of AD entities for the user.
The rest of the code loops through a list of Roles from my new table, and compares them to what the user is supposed to have. On a match, it adds the user to the role if they don't already exist, and removes them from the role on a mismatch.
Then I augmented the rest of the functions that needed the AD roles by adding the generic list as an argument. Now instead of hitting the AD, I hit a database table and our scalability problems are a thing of the past.
I built two dlls. One for Debug and one for Release. The debug version generates an Authentication Log on the webroot when the site is placed into Debug mode. It is useful to see how the roles are being added, and how long it takes to authenticate and authorize each user.
The load times went from upward of 11 seconds down to about 500 milliseconds.
I have been thinking of adding a SyncADRole checkbox to the Roles list and edit screens to manage my new table, but for now since we only add roles and so on a couple times a year, I just manage it with SQL Management Studio.
I hope this helps someone.
We are still not without our problems see my next post, but this works perfectly for the most part.