30 for 3.0 - Dotnetnuke is coming fast.

Well, the program for the DNN 3.0 beta is finally here. The site located at http://30.dotnetnuke.us states the nature of the program as:

“If you're a serious module developer you're going to appreciate the changes in DotNetNuke

version 3.0. We invite you to experience them before anyone else!

All developers committed to delivering 3.0 versions of existing modules are invited to register for the “30 for 3.0!“ program. As registered participants in the program, these are just a few of the benefits you’ll enjoy:

• Privileged access to this website for DotNetNuke module developers
• Early versions of source code for DotNetNuke 3.0 and any subsequent stabilization release
• Early documentation and support resources
• Forums specifically dedicated to 3.0 module development issues and participants interested in the same things you are
• Guidance on how to make your modules “3.0 ready” (taking advantage of new core Interfaces and features)
• A Bronze level listing in the DotNetNuke.com resource directory for your business (if applicable).

As a participant in the program you’ll have the option to submit your 3.0 modules for a “readiness review”. All module submissions are eligible for the following benefits:

• A Bronze level listing in the DotNetNuke.com resource directory for every module which passes the “3.0 Ready” review
• Special recognition from the DoteNetNuke.com website (a page will be devoted to promoting “3.0 Ready” modules)

Modules receiving the “30 for 3.0!” designation will enjoy the following additional benefits:

• A Silver level listing ($100 value) in the DotNetNuke.com resource directory for every module receiving the “30 for 3.0!” designation
• Special recognition from the DotNetNuke.com website (a page will be devoted to promoting the 30 for 3.0! program results)
• Your logo in rotation on the 30 for 3.0! program page of the DotNetNuke.com website (this page will be linked directly from the home page)“

As you can see there is quite an opportunuty for the module developers. While DotNetNuke is open-source software, the project is managed in a hybrid fashion between the pure open-source projects where the code repository if free for all to use and abuse and a private software company where source code is safely and strictly maintained and only particular folks have access to modify the core application.

DotNetNuke is managed in a “best of both worlds“ concept. while many folks find this offensive, it appears they lack to understand that the core team is attempting to maintain some integrity of the software and reduce bugs. my advice. Chill out! The software is free and so is the decision on how to manage it. while I do think that some folks could use an immersion in managing an truly open-source repository for community contribution directly, I know one thing. It is NOT my choice. So until you are in the drivers seat of this project, sit down and relax. There are plenty of other ways to contribute to the community and not belittle it in a futile attempt to bring it down.

Enough of the soapbox. coming DNN 3.0...

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....

Mixed Windows Authentication

I knew there was a reason I love the DotNetNuke community! ;)

Thanks to the willingness to hear suggestions by Tam of TTTcompany.com, he is releasing a new version of the Windows Authentication component for DNN 1.0.10 and DNN 2. Tam is addressing a number of issues including some security concerns. The per portal implementation should give the large majority of the folks the flexibility they need with modifiying several different versions of the core modifications.

It also appears that this feature may make it into the final release release of DNN 2.0. Notice I said MAY. It has not been conclusively decided, however I think the more folks that can pitch in and help Tam test the component, the better the chances.

Great work Tam, as always!

Active Directory Searcher Limits

While working on Active Directory authentication mechanism for DotNetNuke, I ran across an issue when I was attempting to sync the DNN users table from AD. I could never load more than 1000 users when the service would stop processing.

Well, long and short of it is that by default Microsoft has capped the Active Directory searching to 1000 objects. This means that if you are attempting to read a large domain, you won't be able to get it all at once.

There are two ways to address this, one is by modifying the search limit in the Active Directory container properties, of course only a domain admin or above can do this. Not a great option if you are a developer with no control on the AD side of things. The second way is to add a key to the registry. Now, I found this information on another website, but I don't seem to have the URL. I did find an additional way to make this work.

The article references changing the HKEY_CURRENT_USER.... hive. While this would affect the current user, it does not necessarily affect the user that ASP.NET is running as to access AD. Yes, you could find the user and modify the key but why do that. For us, our web servers are the ones accessing AD. What we found is that if you add the following to the HKEY_LOCAL_MACHINE.... it works just as well and will be good for anything running on that machine.

As you can imagine, this information is provided as just that. I/we take no responsibility for any damages arising from use of this or any other information on this site. Do NOT use this in production environments, etc....

Start regedit.

Go to the

HKEY_CURRENT_USER\Software\Policies\Microsoft

registry entry.

From the Edit menu, select New, Key.

Enter

Windows

Select the Windows key, and from the Edit menu, select New, Key.

Enter

Directory UI

Go to the Directory UI key, and from the Edit menu, select New, DWORD Value.

Enter

QueryLimit

and press Enter.

Double-click the new value, and set the decimal value.

Click OK.

Close the registry editor.

An example of code is below:

Dim root As New DirectoryEntry(strRootForest)
SetADsSecurity(root)
Dim searcher As New System.DirectoryServices.DirectorySearcher(root)
searcher.SizeLimit = 5000
searcher.PageSize = 1000
searcher.ClientTimeout = System.TimeSpan.FromMinutes(10)
searcher.ServerTimeLimit = System.TimeSpan.FromMinutes(10)
searcher.ServerPageTimeLimit = System.TimeSpan.FromMinutes(10)
searcher.SearchScope = SearchScope.Subtree
searcher.ReferralChasing = ReferralChasingOption.All
searcher.PropertiesToLoad.AddRange(LoadProps)
searcher.Filter = ADsFilter
Dim search As SearchResultCollection = searcher.FindAll
Return search
 

Now, no matter what you set the SEARCHER.SIZELIMIT, if you set it above the AD or reg key search limit, this setting does not do anything. You are still limited to the AD of reg key limit. So, in conclusion, the SizeLimit attribute is only usable is set to the same or less than the current AD or Reg Key search limit.

Whew! It took a while but thought I would share so you may be able to not go through the headache I did on this. ;)