We are a non-profit and a major project of ours has now been spun off as its own non-profit corporation. We need to take the project's child portal and transfer it to another environment, a new DNN site, as a parent portal.

How do we ensure that authentication works for them but that they don't have access to the mother ship, so to speak?

We use Evotiva backup script which should make it very easy to create a "copy" in a dev environment and do the changes necessary to make the child a parent (That part is not that complicated as far as I can see.)

My question is how to ensure the authentication works for them after the transfer but that they can't get admin access to the original parent portal. My understanding is that if we don't hand over our machine validation and decriptions keys, they  won't be able to log on. And if we give them our keys, then what risks would we run? These are currently two, compatible, sister organizations, but we have no way of predicting what paths they will follow in the future.

Is it possible to split off a child in such a way that the passwords still function without creating a security risk for the original parent?

Thanks.

I guess my question about the machine key boils down to this: Is there a security risk if some other ISP has a site that happens to use the same machine key as yours? Given that the critical passwords would be changed, would this really be much of a problem?

Upon reflection, the identity of the "machine" seems to matter much more within an environment of several "machines,"   more than it would matter from one organization to another. Is that right, or would that really make us more vulnerable?

After seeing the security notes about 4.8.2, I am inclined to pay attention to this. Here's what I did to accomplish it:

1) Create a new DNN Install. Make sure the new host account has a userid distinct from any userid in the old site.

2) Save a backup of the db

3) "Restore" the transferred data using Evotiva BackupScript (or copy the db)

4) Insert the host rows, using the data from the saved db, in the Users, aspnet_membership, aspnet_users tables using the newly created application id (one row per table)

5) Use the NEW machine key.

Now, the only password that works is the new host ID. Tools like DNN Masters Membership Management can be used to reset all the passwords and send out notices with new passwords. A message can be put on the login page as well that informs the user the passwords have changed and to click "password reminder" etc etc. The marketing department can give the users a reason to visit and change ther password, etc.