SQL Server

Managing Security Within the Database Engine : Creating SQL Server Principals

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
11/18/2010 7:18:21 PM

Creating SQL Server Principals

This section will discuss the server-level principals provided for you in SQL Server 2008. Once again, those principals are SQL Server logins and SQL Server roles. We also will touch on user creation for certificates, asymmetric keys, credentials, and Windows principals.

1. Creating Logins for SQL Server

SQL Server 2008 supports both Windows and SQL Server authentication. SQL Server authentication does the username and password validation for users attempting to gain access to SQL Server, while Windows handles the user validation for Windows-authenticated users. In order to use SQL Server authentication, you must configure your instance of SQL Server to utilize Mixed Mode authentication. Mixed Mode authentication means that the instance will support both Windows authentication and SQL Server authentication. While you can configure SQL Server to enable only Windows authentication, there is no way to enable SQL Server to use only SQL Server authentication without allowing Windows authentication as well.

Creating SQL Server logins using T-SQL follows the same basic syntax as credentials, certificates, asymmetric keys, Windows principals, and SQL Server-authenticated logins. The following syntax in Listing 8-1 shows you how to create SQL Server logins.

Example 1. Syntax for Creating SQL Server Logins

When creating a SQL Server login, you have to specify the login name, and depending on the type of SQL Server login you are creating, specify password options or another source with which to associate the username. The available password options allow you to supply a password in standard text or a hash value. If you supply a password in standard text, then SQL Server will convert the password to hash before storing it within the database. So don't worry about your password being compromised if you create an account with a password in standard text.

The password options available to you when creating SQL Server logins are as follows:

  • MUST_CHANGE: Specifies that users must change their password when they login.

  • CHECK_EXPIRATION: Determines if the password expiration policy is enforced. The default value is OFF.

  • CHECK_POLICY: Specifies if the Windows policies of the computer/server running SQL Server are enforced on the login. The default value is ON.

  • CREDENTIAL: Identifies the name of the credential to associate to the login.

  • DEFAULT_DATABASE: Specifies the default database for the new login. If you do not specify the default database parameter, SQL Server will assign the master database as the default database for the login.

  • Default_Language: Specifies the default language for the new login. If you do not supply the default language parameter, SQL Server will use the default language for the instance of SQL Server.

  • SID: Allows you to specify the uniqueidentifier that will be assigned to the newly created login. SQL Server will assign a random uniqueidentifier if you do not supply this parameter in the Create Login statement. The SID option is only valid for SQL Server logins.

The available sources in the FROM SOURCE clause are certificates, asymmetric keys and Windows. We will discuss associating SQL Server logins to certificates and asymmetric keys in the upcoming section "Associating Logins with Certificates and Asymmetric Keys." We will also discuss creating SQL Server logins for Windows principals in the next section.

2. Creating SQL Server Logins for Windows Principals

SQL Server 2008 permits Windows principals, local Windows users, or domain groups and users to gain access to SQL Server without resupplying a password. In order for Windows principals to access SQL Server, SQL Server uses Windows to confirm the identity of the user. Windows authentication is more secure and is the default authentication method for SQL Server. We recommend using Windows authentication whenever possible.

Creating Windows users and groups is outside of the scope of this book. However, after the creation of a Windows principal, granting access to that user within SQL Server is not complex. Using the syntax from Listing 8-1, in order to create a SQL Server user for a Windows user, you specify the SQL Server login name that you want to create, specify that the source is Windows, and then define the Windows options. The available Windows options allow you to define the default database and default languages if you want. The following code example creates a SQL Server login for a Windows principal.




Unlike previous versions of SQL Server, SQL Server 2008 starts restricting access to SQL Server for Windows users during the installation process. By default, you have to grant access to Windows users or groups to SQL Server 2008 in order for the user to have any access to SQL Server. Historically, users within the Windows administrator group would have administrator access to SQL Server, but that is no longer the case. During the installation process, you were given the opportunity to grant Windows users access to SQL Server. If access is not granted to Windows users during the installation process, then you will have go through a process similar to the preceding example to grant those users or groups access to SQL Server.

3. Creating SQL Server-Authenticated Logins

When creating SQL Server-authenticated logins, the usernames and passwords are stored within the database. Unlike Windows authentication, users have to supply their usernames and passwords to log in to SQL Server.

To create a SQL Server-authenticated login using the syntax in Listing 8-1, specify the login name and the password. Remember, you can provide a hash password or a standard text password. If you are creating a password for a person, you may want to utilize the MUST_CHANGE option. That way, you can provide the user with a simple password like Abc123#@ and require them to change it when they login. Finally, determine the default database, the default language, and whether you want the password policy and password expiration enabled. In order to enable password expiration, then you must enable the password policy. Review the following SQL Server script to create a standard SQL Server login.



4. Associating Logins with Certificates and Asymmetric Keys

In SQL Server 2008, you can associate SQL Server logins to certificates and asymmetric keys. Mapping a SQL Server user to a certificate or asymmetric key controls the application rights and access levels in SQL Server. We will review certificates and asymmetric keys in detail later on in this chapter. Here we briefly discuss and provide an example of associating users to Certificates and Asymmetric Keys.


SQL Server logins enclosed in double pound signs (##) represent internal logins created from certificates. The installation process will create users like ##MS_PolicyEventProcessingLogin##, so do not be alarmed when you see them on your server.

You specify the login name that you would like to create, then reference the certificate or asymmetric key that you are associating the user to, and you are all set. Make sure the key or certificate that you are associating the user to resides in the master database. Review the following example of a certificate creation followed by a user that is created using the certificate.

Use master;

WITH SUBJECT = 'book',
START_DATE = '01/01/2009',
EXPIRY_DATE = '12/31/2010'

CREATE LOGIN apressCertUsr

5. Linking Credentials to Logins

SQL Server 2008 allows you to create SQL Server logins and associate them to credentials. Credentials contain authentication information for connecting to resources outside of SQL Server. Credentials generally contain Windows username and password information used internally by SQL Server to access an outside resource. You can associate credentials to Windows and SQL Server-authenticated logins; however, the information stored within a credential allows SQL Server-authenticated users to connect to resources outside of SQL Server. Picture this: A user connects to SQL Server using their SQL Server login account, and then they need to perform an action on the server using the credential that they are associated with to access that resource. SQL Server will use the username and password from the credential to fulfill the request. You can map multiple SQL Server logins to the same credential.

In this example, you are going to link a credential to a SQL Server login. Following the syntax in Listing 8-1, you can see that linking a login to a credential is straightforward. The first thing you do is supply the username that you want associated to the credential and the password, and then specify the credential name that you are assigning the user to. (See the following code sample.) The example also shows you how to create a credential.

WITH IDENTITY = 'sylvester',
SECRET = 'password'

CREATE LOGIN apressCredUsr
WITH PASSWORD = 'P@ssw0rd!',
CREDENTIAL = apressCred

Generally, we recommend that you use Windows authentication because it provides the benefits of user administration and increased security. In most organizations, domain accounts or local server accounts have password policies in place that force users to have strong passwords as well as modify their passwords in a predetermined amount of time. Luckily, if you are unable to use Windows authentication, SQL Server 2008 has the ability to set password expiration and enforce strong passwords for SQL accounts.


According to SQL Server Books Online, strong passwords have a minimum of eight characters, have numbers, characters, and symbols, are not found in the dictionary, are not the names of commands, are not a username, are not the name of a person, are significantly different than the last password, are not the computer name, are changed regularly, contain or start with a space, and start with a $ or @ sign. SQL Server 2008 can enforce the same password policy as Windows 2003, which is not quite the same as what Books Online recommends. If you choose to enforce the same password policy as Windows 2003, then each password must not contain all or part of the account name, the password must be eight characters long, must include a capital letter, a lower case letter, a number, and a non-alphanumeric character.

Enabling the password enforcement policy adds additional security to SQL Server accounts. Still, we recommend using Windows authentication when possible. Removing additional user account administration from your long list of daily tasks enables you to spend more time doing fun DBA stuff, like tuning queries and solving performance problems. No one enjoys the repetitive task of constantly resetting user passwords.

6. SQL Server-Level Roles

SQL Server 2008 has predefined roles or groups that enable you to manage permissions for SQL Server logins throughout the server. Microsoft defines the server roles, and you cannot create additional roles beyond what Microsoft has defined. Logins added to sever-level roles have the ability to add or delete other users from the role. The available server-level roles are as follows:

  • SysAdmin: Allows users to perform any activity on the server.

  • ServerAdmin: Permits users to manage configuration options on the server and shut down SQL Server.

  • SecurityAdmin: Gives users the ability to grant, revoke, and deny server- and database-level permissions. They can also manage users and passwords, as well as reset passwords of other users.

  • ProcessAdmin: Allows users to end processes running on an instance.

  • SetupAdmin: Creates linked servers.

  • BulkAdmin: Performs bulk-insert statements.

  • DiskAdmin: Manages the disk files.

  • DBCreator: Creates, alters, or drops any databases.

  • Public: The default role that server logins belong to.

6.1. Adding Logins to Server-Level Roles

In T-SQL, adding logins to server-level roles occurs via a stored procedure sp_addsrvrolemember. The stored procedure expects two parameters: a login name for the user that you want added to the role and the name of the role. Try the following code sample to add a login to a server-level role.

EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity',_
@rolename = N'serveradmin'
EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity', _
@rolename = N'securityadmin'
EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity',_
@rolename = N'processadmin'
EXEC master..sp_addsrvrolemember @loginame = N'apressSecurity',_
@rolename = N'dbCreator'

6.2. Removing Logins from Server-Level Roles

In T-SQL, removing logins from server-level roles also occur via a stored procedure sp_dropsrvrolemember. The stored procedure also takes two parameters; a login name that you want removed from the server-level role and the role name that you want to remove the login name from.

Other -----------------
- SQL Server 2008 : Performance Tuning - Locks, Blocking, and Deadlocks
- SQL Server 2008 : Performance Tuning - Tracing
- SQL Server 2008 : Implementing Error Handling - Managing and Raising User-Defined Errors
- SQL Server 2008 : Implementing Error Handling - Understanding Errors
- Implementing SQL Server Objects Using Managed Code (part 2)
- Implementing SQL Server Objects Using Managed Code (part 1)
- Encryption Catalog Views
- Built-In Cryptographic Functions
- SQL server 2008 : Managing Security - Permissions
- SQL server 2008 : Managing Security - Schemas
- SQL server 2008 : Managing Security - Users
- SQL server 2008 : Managing Security - Roles
- SQL Server 2008 : Managing Remote Servers
- Linked Servers
- Adding, Dropping, and Configuring Linked Servers
- Mapping Local Logins to Logins on Linked Servers
- Obtaining General Information About Linked Servers
- Executing a Stored Procedure via a Linked Server
- Setting Up Linked Servers Using SQL Server Management Studio
- Encryption basics for SQL Server : Cryptographic Keys
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us