So, let's have a look at principals. There are two levels of principals - those that participate in the database (users and roles) and those that have access to the server (logins). Let's look at the principals at the database level first, by looking at [sys].[database_principals]:
name | This is the name of the database principal. This is the name that will be referenced for statements such as ALTER AUTHORIZATION. |
|---|---|
principal_id | This is the ID of the principal, referenced by principal_id columns. |
type | This is a single character that determines the type of the principal:
|
type_desc | This is the description that relates to the value in the type column. |
default_schema_name | This is the name of the default schema for the database principal. Note that a name is used rather than the ID, because otherwise there would be a circular dependency when creating principals and schemas with owners. Which came first, the |
create_date | This is the date on which the principal was created. |
modify_date | This is the date on which the principal was last modified. |
owning_principal_id | This is the ID of the database principal that owns the current principal. |
sid | This is the SID for SQL users, Windows users and Windows groups. |
is_fixed_role | This is 1 if the entry is one of the fixed database roles:
|
We get a good bit of information there, enough to re-create the database user / role if necessary. Let's look at the principals at the server level, this time looking at [sys].[server_principals]:
name | This is the name of the server principal - this will be referenced when creating a database user. |
|---|---|
principal_id | The is the ID of the server principal within the server. |
sid | This is the Security ID of the principal, which will be the same as the Windows SID for a Windows login / group. |
type | This is a single character that determines the type of the principal:
|
type_desc | This is the description that relates to the value in the type column. |
is_disabled | This is 1 if the login is disabled. |
create_date | This is the date on which the principal was created. |
modify_date | This is the date on which the principal was last modified. |
default_database_name | This is the name of the default database for this principal. |
default_language_name | This is the name of the default language for this principal. |
credential_id | This is the ID of the credential, in [sys].[credentials] that relates to this principal, if applicable. |
Now we have enough information to create both the user and login... almost. Note that passwords and other sensitive information are never available in metadata for security reasons (somewhat obviously). The other pertinent information that we want is the members of each role - for which we look to [sys].[database_role_members]:
role_principal_id | This is the ID of the database principal in [sys].[database_principals] that represents the role. |
|---|---|
member_principal_id | This is the ID of the database principal in [sys].[database_principals] that represents the role member. |
Excellent, just what we need, nothing more, nothing less.
Next time, we'll take a look at the key and certificate based views.