Hi - I had problems with this issue months ago and have decided to live with it.  I see new builds of the AD provider, and I'm looking for a quick answer on whether it has been fixed.

Short case: A user is logged in automatically via this provider.  He/she spends a minute entering content to an announcements module, and when Save is clicked, it just opens up the edit screen again and doesn't post.  I've gotten in the habit of copying the HTML immediately prior to clicking save and exit so that the work wouldn't be lost.  If the entire edit takes some short (arbitrary) amount of time, there is no problem submitting...

Thanks!

Kel, is this a case of you being logged in as an admin user (standard DNN account) and then being kicked over to your AD user?

I'm just wondering because I did a test this morning before leaving for a meeting and when I tried to submit after leaving the page on an Announcement Edit screen for about an hour and a half it failed when I tried to submit. Just a while ago I tried again with the full intention of leaving it for only a minute but people came into my office and I got sidetracked. I finally remembered a few minutes ago and I was able to submit just fine (I started at 2:12 my time and submitted at 2:40 (so almost 30 minutes)). This was done while logged in as my AD user with Edit rights on the Announcements module. That's what lead to my question above.

Well crap. I was doing it with my AD user as an admin too. What version of DNN are you using? I can't remember which version it was but there was one where there were some cookie changes done. My testing was on a 4.8.2 install so if you're using an earlier version I'd have to go back and to a test on one of those.

As for the not logging in part..... is there a chance these users have logged off the site the last time they were there? What happens in the code is the cookie for the site is read and it checks the WindowsAuthentication. If it's set to Undefined then it tries to do a redirect to WindowsSignin.aspx. If it reads that it's set to Windows then it assumes that the user is already logged in and blows past the redirect (otherwise the site would get stuck in an infinite loop). I guess I could try to see if the user is logged in or not but I "think" that this happens before the user would be logged in on a normal basis. Anywho, if the user logs out the cookie still has that the authentication is set to Windows so until the cookie has expired it'll blow past the redirect to WindowsSignin.aspx.

I'm still working with a lot of the original code that I inherited and, going by memory here, there is a section for when a user Logs off but it's commented that it needs to be checked out on why that procedure never gets called. It's on my "to do" list but if you could log an bug report in the Public area on the Gemini site (http://support.dotnetnuke.com) it'll keep me honest and serve as a reminder to look into it.