Okay - so here is the web.config section for authentication:
<!-- forms or Windows authentication -->
<authentication mode="forms">
<forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies"/>
</authentication>
<!--
<identity impersonate="true"/>
<authentication mode="Windows">
</authentication>
-->
It seems that impersonation is disabled via commenting.
As far as the event log, there is nothing notable. There are no exceptions related to role addition, etc. It does notify for “User Role Created,” but it does not notify anything when it wipes the roles.
By the way, if I open parallel browsers, log into one as host and the other as another account that we set up to emulate Sherry’s, then with host manually add the test account to the appropriate AD-based DNN role, the test account has the correct privileges for the duration of its session. I used this observation to help conclude that the actual wiping occurs at login. Also, setting the role with host before the user logs in (and watching the account being allocated in the user list for the role), refreshing to make sure it’s still there 5 minutes later (it is), and then refreshing immediately after user login shows that the role-user relationship is no longer there at that point.
I have found one more piece of potentially interesting information: Although the login for the test account appears in the DNN log as a success, I see nothing in the Event Viewer on the server. I was under the impression that IIS-originated AD logins appeared in the viewer, so does it seem that something may be amiss there? The logins that I do see in that event viewer are the anonymous credentials for our IIS websites and application pools. The configured application pool for this particular site has “Predefined: Network Service” as its identity.
Also, the DNN AD provider is the beta …04 version, but I think you’ve already taken that in. I just wanted to clarify that in case replication proves impossible with …03 or if you think a solution might include jumping back down to …03. I was having timeout issues anytime a user got positive authentication with …03 but …04 fixed that, hence the jump.
Please let me know what additional information I can give.