By default, the connection parameters for your database will be determined by the connection string named "DefaultConnection", which you quote in your question.
The name of the corresponding connection string to use can actually be changed in the constructor of the ApplicationDbContext class, changing from -
public ApplicationDbContext() : base("DefaultConnection", throwIfV1Schema: false) { }
To -
public ApplicationDbContext() : base("SomeOtherConnection", throwIfV1Schema: false) { }
(The throwIfV1Schema property is obviously an addition in the second version and will not be present in the first version)
However, simply changing the "DefaultConnection" connection string data to the details of another database (and the user account with the corresponding credentials) is usually sufficient if there is no previously existing connection string that you want to split / reuse.
By default, ASP.NET Identity will create tables (if they do not already exist) the first time an ASP.NET Identity context tries to interact with a database — for example, by registering or logging in. If you just changed the connection strings and started the application, there is a chance that he did not try to create the tables - you will need to explicitly perform the action associated with the user.
In your case, you want to create tables yourself.
You can map ASP.NET Identity classes and properties by overriding the OnModelCreating event. It will look something like this:
protected override void OnModelCreating(DbModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); var user = modelBuilder.Entity<IdentityUser>().HasKey(u => u.Id).ToTable("User", "Users");
Using "ToTable" for each object and "HasColumnName" for each property, you should be able to map your own database tables.
What you may wish to do if you do not already have custom database tables, just create a new schema (for example, "Users") inside your database, draw ASP.NET to use this (the ToTable method has an overload that accepts the schema) and let him create the tables as usual. Thus, you can be sure that this will not affect existing tables, stored procedures and database functions (as always, however, backing up).
Alternatively, you can create tables yourself using SQL scripts. It was easier for me to create a new empty MVC (this can be web forms, if necessary), the application downloads a sample NuGet project , updates the ASP.NET Identity and Entity Framework for the stable versions that I used, and point them to the empty database - then try to log in. This will give you all the table and schema information you need for the script.
I described in detail the steps required to match the entities in the created script database in my question in November 2013. Creating Identity ASP.NET tables using an SQL script that you may find useful for reference, although you should remember that the schema is from those has changed with the release of ASP.NET Identity 2 and 2.1, and the properties that we added in 1.0 are now standard in version 2.0 and higher. Other properties added by us will not be displayed at all. The answer will be a method reference rather than just a copy and paste solution.
Keep in mind that while you can learn about Identity ASP.NET tables in your main Entity infrastructure context, it should not interact with them outside of the read. You will encounter problems when both ASP.NET Identity contexts and the main Entity infrastructure data context are updated or inserted into the same tables at the same time, and there will be no change tracking in the contexts.
Hope this helps.