Duplicating Effort?

Wow, just finished my previous post and just received and email from Tam about a new Authentication component for DNN allowing “Mixed-Mode Authentication”. Boy, that sounds familiar.. ;)

According to Tam's documentation “

This component provides Mixed Authentication for DotNetNuke. With just one DotNetNuke website you could have both Authentication Modes (Forms and Windows). Features including:

· Single logon for DotNetNuke portal with Windows Authentication mode. When user login to portal, he/she has already been authenticated with Windows network. ADSI pass all login process and checks if user exists in Users database, if not user information will be obtains from Windows Active Directory and insert as a new user in DotNetNuke database. In DotNetNuke 2.0 (TTT.DotNetNuke.ADSI.dll.2.0), this component has been fully rewritten to take advantage features of the new framework. All known issues from the previous version have been fixed.

· Separate authentication mode for each child portal, you could have parent portal running Windows Authentication while child portal running Forms Authentication. In complex Active Directory network with multi domain & authorization rules, we could have different settings for each child portal.

· Easy to switch between modes. You could change your Authentication mode permanently in no time with just one click. You also could temporary switch from Windows -> Forms

· ADSI Settings GUI, previous version Username & Password to access ADSI was stored in web.config, which let ADSI admins in some strictly Windows network not very happy (?!). No web.config modification required in this version, Active Directory settings are stored encrypted in database, a GUI combined with DNN Site Settings allows Admin to change Ads configuration easier than previous version.

· ADSI also works in Windows network without Active Directory implemented. A minimum required information from User login name to be used to create DotNetNuke user account.

· Active Directory User/Group membership is updated in User/Role membership in DotNetNuke. This feature works only if Active Directory Group has corresponding Security Role exists in DotNetNuke database. (A separate custom module will provide a GUI for importing Group into DotNetNuke).

· User account in child portal: Previous version did not include method to create user in child portal if user had already exists in parent portal, this issue has been solved in this release

· ADSI also handles portals switching (which was not available in previous version).

· Logon/off link was visible in previous version. With this version this link will be invisible if DotNetNuke is in Windows Authentication mode”

DotNetNuke Mixed Mode Authentication

This part of the project is going very well so far. We now have DotNetNuke attempting a Windows authentication via an ASPX page through IIS Integrated Windows Authentication option. If we get a good access token we log the user into requested portal. Since we are deploying this as a single site with many sub-portals, we ensure that when we log the user in that they have a UserPortal record for every portal on this instance. This allows one user account to access multiple portals.

There are still two items on the todo list:

1. DNN User account passwords. Since AD uses a one way hash for password and you cannot, nor would you want, to retrieve the users actual password, we need to figure out how to best handle passwords in the DNN database versus AD. Some installation may wish to have DNN change the AD passwords to keep them “in-sync“, however in many corporate environments, this is not a valid option.
   
   This leaves us with a couple of options.
1. Tam's WA modifications enter the string “password“ as the password for all accounts. This was done since the DB does not allow nulls for password and you cannot read the AD password. Obviously when using a “mixed-mode“ authentication scheme, this is less than desirable.
2. Upon user account creation, a random password is generated and created for the user in DNN. If the user ever needs to access their portal using forms authentication, they may use the “send passwrod reminder“ option to get the password. They may change this to whatever they wish. Negatvie aspects include this password possibly being different than the users AD password. There is no synch mechanism to AD.
2. How to handle Windows Authentication Failures. What I mean is there are a couple schools of thought so far. If the automatic Windows authentication fails, we allow anonymous access. User then clicks login link and enters username and password. Two thoughts on the next steps are:
1. Attempt to authenticate against AD using the form entered credentials. If access token granted, set the security principal and log user into portal as the ad user. If fail AD forms authentication, then attempt to match against DNN Users table as the normal DNN functionality works.
2. Windows authentication is automatic or does not happen at all. Form credentials are only matched to DNN Users Table.

Still working on the best scenario but I believe we are going to approach this a bit carefully. More to come....