hi Rodney

My portal is 455 upgraded most steps since 434 and I'm unable to have two users with the same name but different passwords on different portals. I'll just test it again right now to be sure, as I haven't done so in a while.

Yep, still the same. If I have this in one portal:

• Name: testuser
• Pass: testuser

Then in a second portal with a completely different domain name, I try and register:

• Name: testuser
• Pass: booboo

It fails with this message: That sign-in name is already in use. Please use another or retrieve the password for that account if it is yours and you have forgotten it. Contact support if you get stuck. (I should point out I've changed most messages in the language editor so that may not precisely match what others have there.)

I really assumed this was normal as I'd seen it mentioned in various threads. I'd like to be able to share users and have looked at all the options for this, but given that it's obviously sharing the data already I dont' see why it can't have an option to share the whole user without having to buy a pricey module.

Of course, if it's not supposed to work like this, then what gives?

Rob

We have looked at user sharing and found that there were a lot of problems in trying to implement it in a robust manner.  Things start breaking down quickly when it comes to user management including user profiles.  Since profile definitions are defined on a per portal basis, you have synchronization issues trying to keep profile data in sync.  Just looking at the db tables it also looks like you might have some conflicts with user locking.  There are "Approved" and "LockedOut" columns in the ASPNET_Membership table, which doesn't know about portals, and an "Authorized" column in the UserPortals table.  I think ultimately that we could extend the new Authentication Provider framework to "externalize" all authentication so that how a user is identified/approved is completely separated from the main functioning of the portal.  Once 4.6.0 is finally released we may be able to revisit this issue and see if there is a straightforward method for implementing SSO that won't require using a 3rd party auth system like LiveID or OpenID.