Interstingly, I have another similar but different project where I will be using the SqlMembershipProvider. But I'll be importing an initial userbase from an external system (not AD this time). The Usernames from that system will be familiar to the user, were suitable for their former location and use, but not something we want to stick them with permanently in the new system. However, it is important that we have strong identity integrity to the former system.
So I'm thinking to import and contact users to log on, and give them one opportunity to update their username. I'll store their initial username in a read-only location, and that will both provide the link to the previous system plus play a role in the permission to change the username(if same as current username, they can change it; if different, they already did. Saves me the effort of toggling an indicator.)
So I will wrap in a transaction the update of aspnet_user and user tables, and build a form in Enterprise forms which will execute a stored procedure to do the update either upon submit or upon an approval work flow step.
I know that the UserID, not the username, is the real key identifier for a user account. Thus I expect that it won't be a problem to change a username in this manner (even though it is not a built-in capability in DNN) while the user is logged on.
Does anyone more familiar with internals than I see a problem with this? Thanks -