First, I just wanted to say "thanks, Mike!" It's nice to see the AD provider back into active development (and well-documented to boot!).
Anyway, I just upgraded from 4.5.something to 4.8 and the AD provider 1.00.02 beta2 and I thought I'd share my experiences. This is on a virtualized Windows 2003 R2 Server w/ Service Pack 2.
I downloaded the provider from http://dnn.gmss.org/ADProvider/tabid/314/Default.aspx and installed per the instructions. On Admin, Authentication, Active Directory Settings: I got the "Error: is currently unavailable" and I was unable to choose any Authentication Type (delegation is what I wanted.) I did the following to fix it and I think the combination did the trick:
1. In the database, ModuleSettings table, I erased the SettingValue for all SettingNames starting with AD_
2. Then I set the SettingValue for AD_ProviderTypeName to "DotNetNuke.Authentication.ActiveDirectory.ADSI.ADSIProvider, DotNetNuke.Authentication.ActiveDirectory" (no quotes). I think this was wrong from previous upgrades (used AD auth since to dnn 3.x on this site.)
3. In Active Directory, I created a standard domain account called "dnn-impersonate". No special permissions.
4. On the web server, I added "dnn-impersonate" to the IIS_WPG group (group is on the server, not in AD). If you don't do this, later you'll get a "Could not load file or assembly 'CountryListBox' or one of its dependencies. Access is denied". See http://www.dotnetnuke.com/Products/Development/Projects/ModuleGallery/Forums/tabid/916/forumid/107/threadid/135580/scope/posts/threadpage/2/Default.aspx for more info.
5. Give "dnn-impersonate" modifiy rights to your dnn install. I also replaced permissions on all child entries so I had to redo permissions on the windowssigin.aspx. As an aside, my dnn install also has "Network Service" modify and "IUSR_COMPUTERNAME" read rights, though that may not be technically correct.
6. I have not given "dnn-impersonate" any other rights. No admin rights. No database rights. No special AD rights.
7. Edit the web.config file. This is exactly what my section looks like:
<!-- Forms or Windows authentication -->
<authentication mode="Forms">
<forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" />
</authentication>
<identity impersonate="true" userName="domainname\dnn-impersonate" password="putthepasswordhere"/>
<!-- <authentication mode="Windows">
</authentication> -->
8. Went back to Admin, Authentication, Active Directory Settings. Delgation was available in the dropdown box. I put in all the info and got the green light. I did not reuse "dnn-impersonate" here. I used a different, but standard AD account to talk to AD. Not sure if that's required or not, but that's how I had it before, so I left it.
9. Went to http://mydnnsite/DesktopModules/AuthenticationServices/Active Directory/WindowsSignin.aspx and login worked.
This works for me. I need to tinker a bit more, though. According to this: http://msdn2.microsoft.com/en-us/library/ms998358.aspx it would be better to use "a custom application pool with a custom service identity" rather than specify the username/password in the web.config.
I haven't tested group sync yet as we never counted on it working before. It's nice to see that it may work now.
Thanks again, Mike, for taking the time to document, answering questions in the forums, and doing the development work. It is much appreciated.