You might be well aware that DNN allows you to create multiple Portals based on the same physical installation and the database. It even allows the users to be managed independently across Portals, restricting users to the Portal they registered for.

However, there is a less publicized aspect of this feature of DNN. Let’s see it in action before I desribe it theoretically. For this, you would need a DNN installation with atleast 2 portals on it (the Parent/Child status of the Portals does not matter). If you dont’ have it, first create  a test installation with 2 portals. Keep the registration public on both. I will call them http://p1.com, and http://p2.com, for this example.

Browse to http://p1.com, and click the Register link. Create a dummy username say “test”, and give any password (but remember it). Let’s say your password is “master”. Login to the portal http://p1.com with your username, test. You see everything works normally.

Now logout of p1, and browse to http://p2.com. Again click the Register link. Give “test” as the username, but give some other password, let’s say “second”. When you click Register, notice that DotNetNuke shows you an errors, and does not create your account. No matter, what you do, if you want to register with username “test” on http://p2.com, the password provided should be “master” (the one we provided for p1).

Now the above leads to a very major conclusion. There is an implicit built-in assumption in DotNetNuke, that 2 users trying to register with the same username on 2 portals on the same installation, are actually the same human (or bot, if your site is not protected against automated registrationsWink).

Thus, 2 different people cannot use the same username on different portals of the same installation.

There are some other extentions also to this aspect. Although DotNetNuke allows you to maintain your Profile per portal, but your username, password, first name, and last name are uniquel maintained across multiple portals, meaning that if you change them on one portal, the changes are automatically reflected in the other portals.

This last point is important. If you change your pssword on one portal (or username/first name/last name), they are changed across all portals.

Physically this is so, because these values are not stored per portal but once in the Users/aspnet_Membership tables.

Logically, this makes sense to me, as I would normally expect different portals on the same installation to be related to each other in some way.