Hello, people,

I just decided to use Windows Authentication with my 4.5.5 DotNetNuke intranet, after using Mixed authentication with auto login for a year. So I did the following:

1. Set IIS Authentication to "Integrated Security" for the whole web site.
2. Changed DotNetNuke web.config to use <Authentication mode="Windows" /> instead of Forms.
3. Commented out HttpModule.Authentication: <!--add name="Authentication" type="DotNetNuke.HttpModules.AuthenticationModule, DotNetNuke.HttpModules.Authentication" /-->

And, voila! I entered the address in my browser and there I was, logged on automatically! I tried to log out, but I couldn't - just as expected.

But when I created a new user in Active Directory, logged on to windows as that user and tried to visit DNN website. BAM! I was being redirected from Default.aspx to Default.aspx, all the time, the loading progress bar of IE was flickering and nothing was happening. When I created new user in DotNetNuke with the same username, I logged on immediately.

So I came to conclusion: "If I use Windows authentication with my DotNetNuke, new users created in AD won't be able to log on DotNetNuke until I add them manually". Is this correct?

Also, if I use Windows Authentication, any users won't have their role membership snychronized with Active Directory! Is that also correct?

If you wonder why I switched from Mixed to Windows authentication: Mixed authentication with auto login worked well most of the times, but sometimes, users would got kicked out of DotNetNuke. For no reasons whatsoever. They would have to log in manually and then it would all work nicely for a couple of days/weeks/months, until they got kicked out again. My boss didn't find that amusing. :-(

I would really appreciate any feedback from you, guys.

Thanks!

When I used Forms Authentication I did not use impersonation at all. Do you think that could've been the reason for kicking out my users? What is the reason I should use impersonation? AFAIK, impersonation means that logged on user's credentials would've been used to access file system (specifically, I believe we're  talking about admin/security/windowssignin.aspx, right?) instead od NETWORK SERVICE's credentials?
 
When I was using Forms Authentication, I did a little experiment: I scheduled a request to my http://intranet.mycompany.com/Default.aspx webpage every 1 minute. I was getting the following responses 99% of the time:
 
--- REQUEST BEGIN ---
Resolving intranet.mycompany.com... 10.100.100.123
Connecting to intranet.mycompany.com|10.100.100.123|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://intranet.mycompany.com/Admin/Security/WindowsSignin.aspx?tabid=36
Reusing existing connection to intranet.mycompany.com:80.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to intranet.mycompany.com:80.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to intranet.mycompany.com:80.
HTTP request sent, awaiting response... 302 Found
Location: http://intranet.mycompany.com/Home/tabid/36/logon/windows/Default.aspx
Reusing existing connection to intranet.mycompany.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 45.350 (44K) [text/html]
--- REQUEST END ---
 
And that is fine. But at 1% of requests ended up with "500 Internal Server Error" instead of "200 OK" - and that's when users got logged off. I think those 500 errors were actually request time-outs because windowssignin.aspx did not respond.
 
Does that make any sense to you?

I'm getting the same thing with impersonation and windows authentication on 4.07.  If I switch the web.config back to forms authentication I can get in (i guess that would be obvious).  Also in the obvious category--no user account is created.

I thought this impersonation setting had solved most of my problems until I found out that most users were getting a flickering progress bar.  I deleted my account and now get the same thing they do.  The only way I can get in now is with forms authentication.  The solution you mention above is not workable in our network environment because of security concerns.

I should also say that this does not seem to be unique to your new provider.  I've gotten this in older versions of DNN but I don't remember how I resolved it.