I've been testing with the built-in AD auth module in DNN 3.2, and I thought I'd post the results of my testing in hopes it may help someone else out until the new docs are posted. All of this is on a Win2003 server with a fresh install of DNN 3.2 with a Windows 2000 Native mode Active Directory. The documentation from tttcompany.com for the DNN 3.0.13 module was a big help.
Forms auth against AD:
Will let DNN users or AD users login. AD passwords are synched, groups are not synched after the first login. Uses the default DNN login screen.
How I config'ed:
Under Admin, Authentication:
1. Checked "Windows Authentication".
2. Checked "Synchronize Role?"
3. Provider is "ADSIAuthenticationProvider"
4. AuthType is "Delegation"
5. Domain was set as so: dc=contoso,dc=com
Another example, if your AD domain was msn.microsoft.com, you would use dc=msn,dc=microsoft,dc=com
6. Username is netbiosdomainname\username
Example: contoso\dnn-adauthaccount
The account just needs read rights to the AD accounts you want to authenticate.
7. Password and confirm password is obvious.
8. Email domain example: @contoso.com
9. Clicked "Update".
10. You should get:
Accessing Global Catalog:
OK
Checking Root Domain:
OK
Accessing LDAP:
OK
Find all domains in network:
1 Domain(s):
contoso.com (CONTOSO)
11. Now any Security Roles that you want to use to set permissions must match the AD groups. With forms authentication, they are only synched on first time account creation. Logout and try logging in with an AD account. Be sure to use the form netbiosdomain\useraccount, although I could login without the domainname\ prefix, but it would create two different user accounts. This script can auto-add the domainname\ for you: http://forums.asp.net/ShowPost.aspx?PageIndex=31&PostID=1041887#1041887. It worked for me using SnoMan's modification (allow host/user login) to caelen98's script.
So that's forms authentication. What if you want your AD users to login automatically? Tam calls this Windows/Forms Mixed Authentication.
Pros:
1. Groups automatically are added after they are changed in AD, however, they will not unenroll from DNN after being removed from a group in AD.
2. In certain situations inside the network with users won't have to type a username/password to login.
3. You can still use accounts that aren't added in AD.
Cons:
1. To autologin, you have to use this link instead of the regular DNN login link:
http://dnnsite/admin/security/windowssignin.aspx
2. Outside of your network, users will have to type their authentication info into a box determined by their browser. Usually, you have to include the domainname\username info (unless you use basic auth--which is a no-no without some SSL around it)
To set Windows/Forms Mixed Authentication up:
1. Follow the above steps for Form-based auth.
2. Go into IIS manager. Go to properties on DNNsite\admin\security\WindowsSignin.aspx. File Security, Edit. Uncheck "Enable anonymous access". Check "Integrated Windows Authentication".
3. Open up explorer (file, not Internet) and browse to your dnn site. Go to properties on DNNsite\admin\security\WindowsSignin.aspx. Security tab, Remove the anonymous user access (IUSR_Server name and/or Users). Add a group for the people who you want to allow to autosign in (ex: Domain Users).
4. Open up the Internet Explorer and add the following to your dnn site url:
/admin/security/windowssignin.aspx. You should auto-login with IE. If it prompts for a username/password, you may need to add it to a "local intranet" or "trusted site" in IE security.
For auto-login
It looks like this is primarily for intranet users (your users are always logged in, but outside your network everyone will be prompted for a user/pass to view the site) you uncomment the lines in the web.config. This I did not test, but appears to work for others.
Notes
1. I did not have to touch the web.config to set the above two authentication modes up.
2. Integrated authentication is a bit touchy depending on the situation and proxy servers and other things, but it is predictable. You may have issues that have nothing to do with DNN. IE will cache your credentials with integrated auth until you close your browser. I've seen similar behavior with integrated auth in Exchange 2000. Be sure you are clearing cookies and synching your AD servers when testing. Also, I believe (need to retest) that if there is a "." in the URL, IE will treat it as an internet site, go through a proxy if configured, and not pass the Windows authentication automatically. The solution is to manually add the site to local intranet or add it to "do not use a proxy server for these addresses".
3. The http handler in the web.config appears to just pass any attempts to access the website to windowssignin.aspx first. If you don't want people to be auto-logged in, don't uncomment those lines.
4. Groups autoupdate with Windows Auth. They do not autoupdate with Forms Auth after the user is created. With either authentication type, a user won't be removed from a security role after they are added. So if they are no longer a member of an AD group, they will still be in the DNN security role until you remove them. Oliver has code to fix this problem(http://www.dotnetnuke.com/Community/ForumsProjects/tabid/795/forumid/89/threadid/6591/scope/posts/Default.aspx), so hopefully his code will be integrated into the source in the near future.
5. What if you don't want a user to have access to login to the web site with forms auth? I've found that in AD Users and Computers, Security tab for an account, if you deny Read access to the dnn authentication account, that specific account cannot login to the site (they get a bad password message). It'd be better if you could specify a subset of AD in the domain under Admin/Authentication instead (ex: ou=Teachers,ou=Staff,dc=contoso,dc=com), but deny rights gets the job done. Of course, WindowsAuth can be controlled with permissions on windowssecurity.aspx, but that won't work for forms auth.
6. Windows XP AND Windows 2000. I could access Global Catalog and Root Domain, but not LDAP (Accessing LDAP: FAIL) unless I set Identity impersonate="true" in web.config and change the IIS Anonymous user to a domain user, not a local machine account. See http://support.microsoft.com/default.aspx?scid=kb;en-us;329986#3 and/or the documentation from tttcompany.com for the DNN 3.0.13 module. If I didn't make these changes, the LDAP check would fail.
7. Password storage. With forms authentication against AD in 3.2, DNN appears to be storing the AD password in the database. You can verify this by clicking the password reminder button on the login screen. DNN then emails you your AD password. Since I think it's impossible to extract the password from AD, only compare a hash, DNN must be storing a copy of what is typed in the login box. This is a deal breaker for me and many others I'm sure. I'm still testing Windows authentication to check its behavior, but since IIS appears to handle the auth using integrated auth, I'm betting no password is stored. I'm looking at the source to try to find a fix, but I've never used ASP on this level before so it's slow going.
I appreciate the effort that has been put into DNN and this module. I've spent a lot of time trying to piece together how this works. The new integration into the core is great. Unfortunately, I think a lot of people would be less frustrated with DNN across the board if documentation were as important as the actual code. I hope this helps someone.