Logins, Roles and Credentials Lesson 14

Skills Matrix

SQL Server Logins A SQL Server key—a login—gives your users access to SQL Server as a whole, not to the resources (such as databases) inside. If you’re a member of the sysadmin or securityadmin fixed server, you can create one of two types of logins: –Standard logins –Windows logins

Standard Login Only clients with a Windows account can make trusted connections to SQL Server (where SQL Server trusts Windows to validate the user’s password). If the user (such as a Macintosh or Linux client) for whom you’re creating a login can’t make a trusted connection, you must create a standard login for him or her.

Windows Login A Windows login can be mapped to one of the following: –A single user –A Windows group that an administrator has created –A Windows built-in group (for example, Administrators)

Items Common to All Logins When users first log in to SQL Server, they connect to the default database. –In all types of logins, you can grant database access at create time. –If you create a Windows login using sp_grantlogin, you can’t set the default database or language. –In addition, you can add users to a fixed server role at the time you create them You do this on the Server Roles tab in SQL Server Management Studio.

Database User Accounts In much the same way, you need to give users access to databases once they have logged in to SQL Server. You do so by creating database user accounts and then assigning permissions to those user accounts. Once this process completes, your SQL Server users also have more than one key: one for the front door (the login) and one for each file cabinet (database) to which they need access.

Database User Accounts You may have noticed that two user accounts already exist in your databases when they are first created: –DBO –Guest Members of the sysadmin fixed server role automatically become the database owner (DBO) user in every database on the system.

Roles Roles are analogous to groups in the operating system. A user can be added to a role to inherit the permissions of the role. In this manner you can simplify your administrative load: create a role and design the necessary security protocol. Users can then be added or removed easily maintaining your security plan.

Fixed Server Roles Bulkadmin Dbcreator Diskadmin Processadmin Public Securityadmin Serveradmin Setupadmin sysadmin:

SysAdmin Members of the sysadmin role have the authority to perform any task in SQL Server. SQL Server automatically makes operating system BUILTIN\Administrators a member of the sysadmin server role, giving SQL Server administrative rights to all of your Windows administrators.

Database Roles Although granting permissions to single users proves useful from time to time, it’s better, faster, and easier to apply permissions via roles. You have three types of database roles to consider: –Fixed –Custom –Application

Fixed Database Roles Fixed database roles have permissions already applied; that is, you need only add users to these roles and the users inherit the associated permissions

Fixed Database Roles db_accessadmin db_backupoperator db_datareader db_datawriter db_ddladmin db_denydatareader db_denydatawriter db_owner db_securityadmin public

Custom Database Roles Fixed database roles cover many—but not all—of the situations that require permissions to be assigned to users. When you create this new role, you assign permissions to it and then assign users to the role –The users inherit whatever permissions you assign to that role. –You can make your custom database roles members of other database roles. This refers to nesting roles.

Application Roles The application role—grants you a great deal of authority over which applications can be used to work with the data in your databases. To enable the application role, the application executes the sp_setapprole stored procedure (which writes to the application at design time). Once the application role has been enabled, SQL Server no longer sees users as themselves. –it sees them as the application and grants them application role permissions.

MSDB Roles Additional roles of value are found in the MSDB system database. –Databas UserRole –db_ssisadmin –db_ssisltduser –db_ssisoperator –dc_admin –dc_operator –dc_proxy –PolicyAdministratorRole

MSDB Roles –RSExecRole –ServerGroupAdministratorRole –ServerGroupReaderRole –SQLAgentOperatorRole –SQLAgentReaderRole –SQLAgentUserRole –TargetServersRole

Ownership Chain In the physical world, people own objects, with which they can do as they please, including lending or giving them to others. SQL Server understands this concept of ownership. When users create an object, they own that object and can do whatever they want with it. This works well, until you consider ownership chains. An object on loan still belongs to the owner; the person who borrows it must ask the owner for permission before allowing another person to use it. –Acting without such permission describes a broken ownership chain.

Credentials A credential record contains the authentication information (credentials) required to connect to a resource outside SQL Server. –SQL Server uses this information internally. –Most credentials contain a Windows user name and password.

Summary This lesson examined the processes of creating and managing logins, groups, and users. You learned how to create a Standard login and a Windows user or group login using SQL Server Management Studio or T-SQL, and you learned when to use each type. If you have a well-designed security plan that incorporates growth, managing your user base can be a nearly painless task.

Summary To limit administrative access to SQL Server at the server level, you learned you can add users to a fixed server role. To limit access in a specific database, you can add users to a database role; and if one of the fixed database roles isn’t to your liking, you can create your own. You can even go as far as to limit access to specific applications by creating an application role.

Summary To limit administrative access to SQL Server at the server level, you learned you can add users to a fixed server role. To limit access in a specific database, you can add users to a database role; and if one of the fixed database roles isn’t to your liking, you can create your own. You can even go as far as to limit access to specific applications by creating an application role.

Summary You then learned about chains of ownership. These are created when you grant permissions to others on objects you own. Adding more users who create dependent objects creates broken ownership chains, which can become complex and tricky to manage. You learned how to predict the permissions available to users at different locations within these ownership chains. You also learned that to avoid the broken ownership chains, you can add your users to either the db_owner database role or the db_ddladmin database role and have your users create objects as the DBO.

Summary You can grant permissions to database users, as well as database roles. When you add users to a role, they inherit the permissions of the role, including the public role (to which everyone belongs). The only exception occurs when a user has been denied permission, because Deny takes precedence over any other right, no matter the level at which the permission was granted.

Summary And finally you learned you can access resources outside of SQL Server by creating credentials.

Summary for Certification Examination Understand roles. Be familiar with the various fixed server and database roles and what they can be used for in the real world. You also need to know when to create a custom database role instead of using the built-in roles. A good example happens when you need to allow users to insert, update, and select on a table but not to delete. No built-in role allows this, so you would need a custom role.