Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

12.5. Database Schemas and the DBO User

Many of the previous topics assume that you have sufficient privileges to install the application services schemas on your database server. If you or a database administrator have rights to create databases (that is, you are in the db_creator server role), or have "dbo" rights in a preexisting database, then you can just run the aspnet_regsql tool without any worries.

However, there is a very important dependency that the current SQL-based providers have on the concept of the dbo user. If you look at any of the .sql installation scripts in the Framework's installation directory, you will see that all the tables and stored procedures are prepended with dbo:

CREATE TABLE dbo.aspnet_Membership
CREATE PROCEDURE dbo.aspnet_Membership_CreateUser

and so on.

Furthermore, the code inside of all the stored procedures explicitly references object names (that is, tables and stored procedures) using the explicit dbo username:

EXEC dbo.aspnet_Applications_CreateApplication ...
SELECT  @NewUserId = UserId FROM dbo.aspnet_Users ...

and so on.

If you disassemble any of the SQL providers with a tool like ildasm, you will also see that the providers themselves use the dbo owner name when calling stored procedures:

SqlCommand cmd = new SqlCommand("dbo.aspnet_Membership_GetUserByEmail",...);

If you install the database schemas as a member of the System Administrators role, or as a member of the Database Creators role, none of this will affect you because an SA ...