All,

Since DNN 3.2 has entered with tighter AD integration, I noticed one slight flaw in the archicture.  At least from my point of view.

When a new user is authenticated via AD, the system checks if the user exists, if not it AUTOMATICALLY adds them as a user to the site.

This is good for an internet site, or a company wide site, however for smaller departmental intranets, this can pose a problem as you don't want users from another department accessing your sites.  One way to do this is to change the File Structure security underneath the site to narrow the access, although this restricts access to all portals sharing the same code location.

I used this method in DNN 3.1.1, but have taken a different approach in DNN 3.2.

I have made a few CORE changes to enable a checkbox to be added to the AD module, which states to automatically create new users.  It defaults to checked, which has the same effect as the current core.  If you remove the check, it will NOT automatically authenticate the user, but set them as an unauthorized user, in the way the non AD modules do, where you can add a module to your home page for non authorized users stating this is a private site, etc....

I have a screen shot of the addition here: http://www.registrars.kent.edu/home/dotnetnuke/ADCoreMod.gif

I have also created a zip file of the files that were changed with documented changes, and the screenshot.  This can be found here:
http://www.registrars.kent.edu/home/dotnetnuke/dnn32ad.zip

This has only been changed on DNN 3.2 since I do not run DNN 4.x yet, although, performing a diff on the files from their origional versions, the code should be fairly easy to implement on DNN 4 as it is basically an IF statement wrapper checking for that flag before adding the user.

Note: That this IS a CORE change, and has the possibility of being overwritten when another core is released. 

To The CORE TEAM, this is a small incremental change that could be easily implemented and provides a little more security control over an AD site, without affecting the origional functionality of the site.  Please consider adding this small change to the AD core.

There has been a lot of changes since 3.2 I wouldnt be surprised if it breaks somethign you did.

You might want to check it out.

All,

I have found a slight bug in the Auto Create Users Logic.  There is a modification that also needs done to the SignIn.aspx.vb page under admin\security. 

Inside the WindowsAuthorization function,

Change the following:

If (Not objAuthUser Is Nothing) AndAlso (objUser Is Nothing) Then

Dim createStatus As UserCreateStatus

Dim objAuthUsers As New DotNetNuke.Security.Authentication.UserController

' Windows/DNN password validation should be same, check this status here

strMessage = UserController.GetUserCreateStatus(createStatus)

To:

If (Not objAuthUser Is Nothing) AndAlso (objUser Is Nothing) Then

Dim _config As DotNetNuke.Security.Authentication.Configuration = DotNetNuke.Security.Authentication.Configuration.GetConfig()

If _config.AutoCreateUsers Then

' Add this user into DNN database for better performance on next logon

Dim createStatus As UserCreateStatus

Dim objAuthUsers As New DotNetNuke.Security.Authentication.UserController

' Windows/DNN password validation should be same, check this status here

End If

The BOLD lines are the additions.  This will also wrap the Login.aspx page's Login Button functionality.  Without this, if you have auto Create Users turned off, they may be redirected to the Login control and if they would click Login, it would still create an empty account for caching purposes.  However, this account lacks a few properties, such as Full Name and Email address, so it also causes the User Accounts Control to error out.

Wrapping the inside of the If statement with the check for the auto create users, will not auto create the cached account and return a username/password error like it should.

I have updated the zip file for any new users who implement this.