Configuration: Windows 2003 Server, DNN 4.06.00

Sorry, I didn't setup the site a and don't know DNN real well.  I believe we are running ActiveDirectory Provider 1.00.00.  The options match what the documents indicate that version supports.  However I can't find a way to verify that from the files on the production server.  The version info on DotNetNuke.Authentication.ActiveDirectory.dll says 4.6.0 for 1.00.00 and 1.00.03.  Is there a chance the guy who set this up (between July 07 and Dec 07) has a pre 1.00.00 version?  I don't know.

What does work: Authentication seems fine.  We do *not* auto login, most users are anonymous.  They go through a login page to enter name/pw.  This authenticates against AD and the site shows their correct user name. 

The problem: The users are not given the correct permissions from the security role that matches the AD group.  I have verified that the security role in DNN has the same name as the pre-Windows 2000 name of the AD group.  It all was working a few months ago.

The same thing happened Jan 2008. At that time we found the patch for KB941202 (MS07-056: Security Update for Outlook Express and Windows Mail) had been put on the machine and we tried removing it.  That fixed the problem. No, I haven't any idea how those are really related.

In June the same patch was put on the machine again (oops).  It has been removed again.  We thought it was fixed then but now I am not so sure.  We may have been confused by the fact that some users are directly added into the DNN security roles.

 Thank you for your time,

Steve

Thank you Mike. From your description our dll is the 1.00.00 version.

I just checked (again :) and Synchronize Role is checked on the Admin->Authentication page.

We have started exploring an upgrade to 4.8.4 but it is daunting.  We are 1 software engineer and 1 network admin, both overworked on our main jobs in a volunteer organization and withoug experience in DNN.  We will look at it but...

I'm not sure if this is going to be useful info or not but here goes.  Working with one user I just went through a few experiments.

I added him explicitely to the dnn security role. He logged in. RESULT: he can’t edit.

I deleted his user from dnn. He logged in. It automatically created the user again. RESULT: he can’t edit.

I told him to keep his browser window open with him logged in. I added him to the dnn security role. He left the page and went back to it. RESULT: he can edit!

I suspect that deleting the user was not important but it may have been. In other scenarios deleting the user has cleaned up some confusion. I think the critical thing here is the combination of the person being logged in and then adding them to the security role. I believe what happens is that at login dnn tries to synchronize the role with active directory. It fails but in the midst of that the explicit addition of the user to the role gets lost (perhaps by design). Then, we add the user to the role again and that will last for awhile. I suspect it will only last as long as the user keeps that particular browser session alive. The next login will probably try to synchronize the role and go back to the failure state.

We'll look into 4.8.4.  Any other thoughts?

Hey -- it seems that we might be facing a similar issue.  We're running 4.8.4 for a client, and we were originially running the ...03 AD provider but it would hang to a timeout whenever it had positive authentication, but only when Synchronize Roles was turned on.  Synchronize Roles was a desired behavior, as there are many authors on this site, so after upgrading to ...04 this morning, the clients are able to log in with Synch Roles on, but the roles associated with admin of various sections of the site seem to not correctly pull their permissions from AD.  (e.g. no Edit behavior shows up for them at their respective admin areas).  If we manually add a user to a role and that user logs in anew, it gets wiped back to where it was again (I would guess from the synchronization).

Perhaps this is a matter of an ill-configured setting either in IIS, AD, or DNN, but seeing as it appears to be a similar symptom, I thought I should post it and see if there's anything else that might be done about it.

Thank you.