Please forgive me if this question has been asked and answered elsewhere.  In my searching, all the answers I have found did not address our scenario and even if close, many seemed several versions out of date.  What I am looking for is some guidance, preferably step by step instructions on configuring DNN as follows.

We are testing out DNN as a possible portal solution for a client who wants to use it for an internal staff portal.  They use internet explorer and will be connecting from desktops that are already authenticated on the domain.  Consequently we want to use integrated authentication where IE will automatically provide the users credentials to DNN for authentication against AD w/o prompting them.  Note that we only want to use AD for authentication.  We still wish to use DNN's build in role and user management for authorization purposes.  Simply put, the IT department at this organization does not wish to grant those who will be administering the site any access to AD to manage groups and group membership therein.  It is desired that the DNN administrator will do all provisioning via DNN.  Our only tie in with AD is to keep users from needing to log into the DNN site after having already logged into the desktop.  Lastly, there will be no users other than domain users.  There is no need to support any other mode of authentication.   We are okay with needing to manually add each user to DNN.  The organization is small enough that there is no need for any sort of automated synchronization with AD, thought that could be a nice bonus.

Mike, thank you for the prompt reply.  Yes we are using DNN 5.6.  Currenlty I have it installed on my windows 7 development box, but Server 2008 R2 will be the ultimate destination.  Search as I might, somehow I did not find that AD Provider manual yesterday.  I gave it a shot this morning but the part on IIS settings (pg 6) seems out of date for IIS 7.5.  It calls for changing the permitted authentication mode for the WindowsSignin.aspx file.  I am familiar with doing this for directories but not that  the individual file level.  In the IIS 7 management console, one can only right click on an individual file in the "Content View" and the the properties dialog (actually labeled "Permissions..." on the context menu) securities tab only permits you to set the file ACLS, not the windows authentication mode.  The windows authentication mode in only accessible from the "Features" view which operates at the folder level of granularity.

Perhaps you can shed some light on the purpose of these changes.  If I understand how this is supposed to work, an unauthenticated user is supposed to get a 302 redirected to the WindowsSignin.aspx page, which being secured to only permit windows authentication, will send a 401 to the browser, the browser will respond with the windows credentials, IIS validates those against AD, permits the call through to the aspx page which then takes then grabs the Windows Principal/Identity from the call context and logs the user into DNN.  Is that correct?

Mike,

We are continuing to work on this installation, as you may have noticed from some of my other posts on related topics.  We have integrated authentication up and working as desired, and are now attempting to get automatic user creation and role synchronization working.  It appears to be correctly configured but is not working at all.  We have installed a source code version of the ADSI Auth Provider and are able to debug it and what we discovered leads us to believe that our problem is not with user/role synchronization but with how we are doing authorization, so I am coming back to this thread.  Let me explain how we have this set up and what our debugging has reveals and hopefully you can shed some light on how to proceed.

This is a clean DNN 5.6.1 pro trial version install with all the modules and extensions installed except for razor.  It is currently running on Windows 7 with IIS 7.5.  After installation we setup the ADSI Auth Provider as detailed in the user's guide.  At this initial point we turned off the automatic creation of users and automatic role synchronization.  Note that we did not find it necessary to use the "Classic .Net App Pool"  Rather we are using the ASP.Net v4.0 pool.  Secondarily, we set up DNN in its own website with the following ACLS on the site's folder:  Local Admins and System had full control.  The app pool account had read/write/modify access and the local IUSR account had read only access.  The site was configured to permit Forms and Anonymous authentication while the WindowsSignin.aspx was configured as identified in the manual for IIS 7.5.

Thereafter, we were able to log into the site as host using forms authentication and create accounts with user names matching their domain logon (DOMAIN\username) and any user so created was then able to log in using their domain credentials.  So active directory authentication was working at this point.

Next we wanted to enable integrated authentication, meaning that a user already authenticated on the domain would have their credentials automatically passed to the site by Internet Explorer and be authenticated without any end-user interaction.  To accomplish this, we configured the entire website in IIS to use windows authentication only and added an authorization rule to deny access to all anonymous users.  We removed IUSRs access to the file system and granted Domain Users read access in its place.  At this point, integrated authentication appeared to be working.  Any user already logged into their desktop on the domain and for which an existing DNN account existed, could navigate to the DNN site and they were seamlessly logged in w/o having to take any further action.

Interestingly at this  point, any domain user that did not have an account in DNN, when navigating to the site would get caught in an infinite redirect (http 302) loop from the root url back to the root url.

At this point we turned on automatic user creation and role synchronization and again attempted to access the site with a domain account that was not yet in DNN.   The infinite redirect loop persisted.  We did the usual resets of the app pool, cleared the browser history and cookies, etc.  Eventually we installed the source code version of the auth provider to debug the situation.  In doing this we discovered that the provider does not even load into memory (in the debugger, no symbols are loaded) until we navigate to the auth providers configuration page.  It seemed that the provider was not participating in authentication at all at this point.  We have confirmed this by uninstalling the auth provider.  At this point the provider is not installed but integrated authentication is still working.

So our conclusion is that IIS configured for window authentication only, in combination with DNNs build in authentication code is sufficient to enable integrated authentication.  However, the result of this arrangement is that the Auth provider gets taken out of the loop and is not able to perform its user creation and role synchronization functions at initial user signon.

That being the case, our current question is, how do we get integrated windows authentication working with role synchronization and user creation?  We turned on site-wide windows authentication because we want the user to be authenticated automatically no matter which page they initially land on and wish to maintain that functionality.