I was looking at this post a couple of days ago:
http://dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/mid/2108/threadid/46595/scope/posts/Default.aspx#58605

... and found the below quote quite interesting, as I was experiencing what I (probably wrongly) interpreted as odd behaviour in 4.3.3:

So I am wondering in regards to this, would the following scenarios be correct?

a)
I have a normal user, called user1 that exists in Parent Portal A, and somebody registers with the same username/password in Parent Portal B. Once this is created it will be the same user account across both portals. If administrator of Portal A changes the credentials and details of user1, then the credentials and details of user1 from Portal B will in turn be changed without the administrator of Portal B's knowledge.

b)
If by coincidence an entirely different person tries to register a normal user called user1 with Parent Portal C, but with a different password they will get a user already created error. If that person decides to contact the administrator of Portal C and ask him about the availability of user1, Administrator of Portal C will look at the user accounts screen, and perceive that user1 is not registered as it is not being displayed.

c)
The username for all normal users must be unique across all portals of a DNN installation, unless they have the same password.

d)
If multiple portals are created with a default superuser name of admin with same password all the portals will be managed with that same superuser account. You can change this situation by adding additional administrator user accounts to each of the portals, but you can never get rid of the original admin user from that portal afterwards (as the default administrator can't be deleted via DNN). Note I'm experiencing this problem at the moment, the same administrator account is being shared across all portals, I want them to be seperate.

Is what I've written normal behaviour?

I don't think that there are any screens even when logged in as hosts that show which users are spread across multiple portals? I wonder if this behaviour can be changed with 4.3.3 via a setting?

Would you be in agreement in what I've written? Any comments?

Thanks

Alex

Thanks Cathal!

So would you agree the weakness with DNN 4.3.3 at present are:
(and note these are not major issues (this really is my major bugbear at the moment: DNNP-3708 ! : ))

1) If a username already exists with one portal, and the administrator or user tries to register the same username with different a password on another portal, the administrator will have no idea why the user can't register this account(unless they read this thread!). Ideally the administrator needs an appropriate error message that tells him that the user is already registered with other portal(s) and maybe that error message needs to state what those portal(s) are.

2) When you're logged in as host, you can see all users, but you cant see what portal(s) they're a member of. This functionality is going to be needed in a future DNN release for diagnosing user account issues. I guess this functionality could be extended so that the host can manage any user across multiple portals.

Cheers

Alex

p.s.

I am now wondering what would happen if a user that is spread across two or more portal gets deleted.
In DNN 4.3.3 would it be either:

i) The user account be deleted across all portal accounts it is registered with (not good).

ii)  The user account is simply removed from that portal and still remains across the other portals.

iii) Nothing happens or even worse an error message.

I guess I need to have an experiment with this!

I am extremely new to DotNetNuke so I am unsure of its various implementations but if this code is utilized to provide a portal service where a host can provide clients with their unique sites then it is somewhat strange to limit usernames to a single installation base. These "clients" may not be aware or even care of existing portals so they might be somewhat perturbed that their username selection is limited by other's selections.

Since Portals are given a Guid couldn't this be used as an extra layer of distinction when authorizing users similar to ASP.NET's implementation of Application ID's and to potentially utilize that as the Application Id that in the ASP.NET membership tables?

I would suggest that future versions provide the ability to determine if certain portals should have awareness of other portals (for web ring scenarios) or to have an encapsulated user base without restriction of username and password.

And while you are at it can I have the sun, moon and stars as well? ;)