Is a .Net membership database portable, or are accounts somehow bound to the originating Web site or server?

Question

I have an ASP.Net Web site using .Net Membership with a SQL Server provider, so the users and roles are stored in the SQL tables created by Aspnet_regsql.exe.

Is this architecture totally self-contained and portable, or are users in it somehow bound to the specific Web site on which they create their account?

Put another way, if we create a bunch of users in dev or UAT, the back up and restore this database to another server, accessed under another domain name, should it still work just fine?

We're seeing some odd behavior when we move the database, like users losing group affiliation and such, and I'm curious how portable and environment-agnostic this database really is. I have a sneaking suspicion that something is bound to the machine key or the domain.

Answer 1

The users are bound to the application name. You could check it and see if the application name each user is linked to corresponds to the application name on the web.config on your production server.

Apart from that, when you are porting membership to another database, you should make sure that you are taking not only tables but all the stored procedures as well. If, for any reason, you are just porting your database schema, you should run Aspnet_regsql.exe before you port it.

Answer 2

Yes they should work fine.

Only place where you need to be careful is password management. .Net membership providers may use machine specific keys to encrypt or hash the passwords. But there's a work-around where in you tell the asp.net application to use specific machine key and not the auto-generated machine specific keys.

In my application, I keep my passwords encrypted and I have specified my machine-key as below for encryption/decryption. When I do this, I can port my development database to production server or also migrate database from one production server to another very much easily.

  <machineKey validationKey="<your-validation-key>" decryptionKey="<your-decryption-key>" validation="SHA1"/>

There's nothing else you need to worry about regarding migration while working with MembershipProviders.