I have learned an extraodinary amount of information during the last few months in rolling out DotNetNuke to an entire school district. While the rollout is only in its initial phase, there have been some interesting developments.
First, in order to maintain stability and to prevent one school portal from adversely affecting another one, I decided to have a separate portal installation for each school. While this presents its own problems in maintaining the code base and upgrades, I feel that I gain a better control over accidental damage by portal admins. At this point, it is certainly a trade-off I am willing to make. In some preliminary training and presentations, I found that a portal admin who is inexperienced in portal administration can and will easily damage an entire portal installation (files and database).
I am running DotNetNuke (DNN) version 4.02 for each portal right now. I attempted to run version 4.03, but initial deployment tests proved that the caching optimizations in our environment had undesirable results.
One thing I found to be highly important is the need to develop site templates and an installation template. During the installation process, one of the first steps is normally to create an installation directory to point your virtual directory to. (The home for your portal.)When doing this, if you are going to be creating more than one portal you should first do this in an "installation template" folder. This will allow you to make all of the necessary adjustments just ONCE to the file(s) and not need to again. As you apply fixes or patches to files you can make the update here as well to apply them on a fresh installation.Now you will want to make some adjustments in the Install folder to create a custom installation. This has some immediate and necessary security benefits. First, this will allow you to get rid of the easily guessed "host" and "admin" accounts. This will also save you some time in initial set-up and configuration after the installation process takes place.
By default, this is your "host" section in the /Install/Dotnetnuke.Install.Config file:
Now, if you have installed DNN at least once, you already know the Superuser account username is probably "host". This is already one step in the right direction to allow unauthorized visitors access to your superuser account. It would be better to edit this node to be something like the following:
Obviously, you would want to replace the text above to reflect your information. :)
You can do the same with most of the other information in this XML file. However, the most important would be the portals node which by default looks like this:
<keywords>DotNetNuke, DNN, Content, Management, CMS</keywords>
You would want to make any initial changes to make the set-up of your portal go quicker, but you want to certainly change the admin information to reflect the appropriate admin information that you would be changing this to later anyway. Many times, you may not know who the admin is going to be, so you can make yourself another "admin" account in the meantime. You can always add another admin account later.
<portalname>My Portal Name</portalname>
<description>My Portal Web Site</description>
<keywords>portal, web, site, website</keywords>
This could be a great start to a more secure DNN installation. Have fun with it and I suggest going through a handful of installations prior to actually deploying your DNN site. There is a lot of trial and error that can be learned from prior to deploying a half-broken DNN installation. This is especially true for an Intranet installation. There simply is not enough documentation for DNN as a whole, but the Active Directory project is especially light when it comes to step-by-step configuration.
Have fun and happy programming! (How cliche is that?!) Hehehe...