Not always but it seems to be a hit or miss situation that I can't explain. I've had multiple installs on my dev in the past where one will need impersonation and the other won't.

However I would look @ this post by Dan Ball... http://www.dotnetnuke.com/Resources/Forums/forumid/89/threadid/402659/scope/posts.aspx. I've had success with it myself.

Lee,

When I initially tested the provider on a Server 2008 system I had to give my impersonation user admin rights on the server. With Dan's procedure you don't have to do that so if you have to use impersonation you can use a plain vanilla domain user account (I'd never consider using an account that was an admin on the domain). That's why I pointed you to that thread.

The reason you sometimes have to use impersonation is because your website is running under the AppPools user account in 2008 (previous OSes usually ran under the Network Service account) and because the account is local to the computer the domain's Active Directory denies access to itself. Using impersonation means that the website talks to AD as the user account specified. Why sometimes it has to be used and other times it doesn't is a question for Microsoft.

But in the end, I wouldn't worry about using an impersonated user as long as that account is locked down with a minimum of rights. That's how I have to run our production site and I at least know that if, by some miracle, the web.config was somehow compromised anyone getting that impersonation accounts credentials wouldn't be able to do anything with it.

Also, I haven't looked at it in a long time but I think you can setup your AppPool in IIS7 to run under a different account. That might work if you're concerned about having the user account/password listed in the web.config.