Professional Documents
Culture Documents
20764C-ENU-Handbook-Module 03
20764C-ENU-Handbook-Module 03
OF F I C I A L M I C R O S O F T L E A R N I N G P R O D U C T
Contents Part 3 / 15
Module Overview
In the previous modules, you have seen how Microsoft® SQL Server® security is organized and how sets
of permissions can be assigned at the server and database level by using fixed server roles, user-defined
server roles, fixed database roles, and application roles. The final step in authorizing users to access SQL
Server resources is the authorization of users and roles to access server and database objects.
In this module, you will see how these object permissions are managed. In addition to access permissions
on database objects, SQL Server provides the ability to determine which users are allowed to execute
code, such as stored procedures and functions. In many cases, these permissions and the permissions on
the database objects are best configured at the schema level rather than at the level of the individual
object. Schema-based permission grants can simplify your security architecture. You will explore the
granting of permissions at the schema level in the final lesson of this module.
Objectives
After completing this module, you will be able to:
Authorize user access to objects.
Authorize users to execute code.
Configure permissions at the schema level.
MOC 20764C | Administering a SQL Database Infrastructure | Module 03 – Authorizing Users to Access Resources | 2 / 10
denial. You can use the GRANT statement to assign permissions on a securable to database users.
Similarly, you can use the REVOKE statement to remove the same permissions.
DENY
In ANSI (American National Standards Institute) SQL, if a user does not have permission to perform an
action, they cannot do so. Therefore, ANSI SQL does not provide a DENY statement.
Because SQL Server is closely linked with the Windows operating system and its group membership
system, a Windows user can receive permissions through their group membership. Therefore, there may
be cases where a user has a permission granted through their group membership that you might want to
remove for the individual.
To support this scenario, SQL Server provides the DENY statement, which you can use to explicitly deny a
user a permission that they may receive from membership of a group or role. This is very similar to the
process for denying permissions work in Windows. For a Windows example, consider that you could
decide that all members of the Salespeople group can access a color printer—except Holly (who is a
member of Salespeople), because she causes problems with it. You grant access to the Salespeople group
then deny it to Holly. SQL Server works in the same way. You could grant SELECT permission on a table to
every member of the Salespeople role, and then deny Holly access to that table.
As with Windows, you should use DENY sparingly. If you need to DENY many permissions, it might
indicate a potential problem with your security design.
Note: The REVOKE statement revokes both GRANT and DENY statements.
Securing Tables and Views
The permissions to access data that apply to tables
and views are SELECT, INSERT, UPDATE, DELETE,
and REFERENCES.
In the following example, SELECT permission on
the Marketing.Salesperson object (which is likely
to be a table or a view) is being granted to the
HRApp user in the MarketDev database:
Applying Permissions
USE MarketDev;
GO
Note that two forms of the command are shown. While the full terminology involves OBJECT:: as a prefix,
this is optional. In the second example, the same GRANT statement is shown without the OBJECT:: prefix.
It is not strictly necessary to specify the schema for the table or view, but doing so is highly recommended
to ensure that permissions are granted on the intended object. If the schema name is not specified, the
default schema for the user granting the permission is used. If the object is not found in the user's default
schema, the dbo schema is used instead.
REFERENCES
While the meaning of the SELECT, INSERT, UPDATE, and DELETE permissions will likely be obvious to you,
the meaning and purpose of the REFERENCES permission might not. You need to use the REFERENCES
permission before a foreign key relationship can specify the object as a target, and is only required if no
other permissions exist on the referenced object.
MOC 20764C | Administering a SQL Database Infrastructure | Module 03 – Authorizing Users to Access Resources | 4 / 10
Column-Level Security
In addition to assigning permissions at table or
view level, you can also allocate column-level
permissions. This provides a more granular level of
security for data in your database.
User1 can now access two columns in the Marketing.Salesperson table, but not the whole table.
CASCADE
The challenge of the WITH GRANT OPTION clause comes when you need to REVOKE or DENY the
permission that you granted to James using the WITH GRANT OPTION. You do not know which other
users James has already granted the permission to.
When revoking or denying a permission, you can use the CASCADE clause to also revoke or deny
permissions from any users who had been granted them by User1.
In this example, the REVOKE statement will fail if you omit the CASCADE clause, because the GRANT
statement included the WITH GRANT OPTION clause.
MOC 20764C | Administering a SQL Database Infrastructure | Module 03 – Authorizing Users to Access Resources | 6 / 10
In this lesson, you will see how to manage the security of stored procedures and functions. You will also
learn how to manage security for code that lives in .NET-managed code assemblies that are used with SQL
CLR integration. Finally, you will see how ownership chains affect the security relationship between code
and database objects.
Securing Stored Procedures
By default, users cannot execute stored
procedures that other users create unless you
grant them the EXECUTE permission on the stored
procedure. In addition, they might also need
permissions to access the objects that the stored
procedure uses. You will discover more about this
issue later in this lesson.
In addition to these permissions, there are scenarios where you also need to assign the REFERENCES
permission to users so that they can correctly execute a UDF. These scenarios include functions that:
MOC 20764C | Administering a SQL Database Infrastructure | Module 03 – Authorizing Users to Access Resources | 7 / 10
Functions often provide low-risk, basic capabilities within systems. Because of this, it is fairly common
practice to grant permissions on basic functions that are contained in a database to the public role of the
database. This means that any user in the database can use those functions without needing further
permission grants.
The following example shows how to grant execute permissions to the public role on the
dbo.FormatPhoneNumber function:
Note: Assigning permissions to the public role on stored procedures is not appropriate.
Securing Managed Code
Managed code is .NET Framework code that ships
in assemblies. Assemblies can exist as DLL or EXE
files; however, you can only load assemblies in DLL
files in SQL Server by using SQL Server CLR
integration. After you load an assembly, the
procedures, functions, and other managed code
objects appear as standard objects in SQL Server,
and the standard object permissions apply. For
example, users require EXECUTE permissions to
run a stored procedure, whether it originates in an
assembly or in Transact-SQL code.
Permission Sets
No matter what .NET Framework code is included in an assembly, the actions the code can execute are
determined by the permission set specified when creating the assembly.
The SAFE permission set strictly limits the actions that the assembly can perform and inhibits it from
accessing external system resources. Code using this permission set can access the local instance of
SQL Server by using a direct access path, called a context connection. The SAFE permission set is the
default.
The EXTERNAL_ACCESS permission set allows the code to access local and network resources,
environment variables, and the registry. EXTERNAL_ACCESS is even necessary for accessing the same
SQL Server instance if a connection is made through a network interface.
The UNSAFE permission set relaxes many standard controls over code so you should avoid using it.
The EXTERNAL_ACCESS and UNSAFE permission sets require additional setup. You cannot specify the
requirement for an EXTERNAL_ACCESS permission set when executing the CREATE ASSEMBLY statement.
You should flag the database as TRUSTWORTHY (which is easy, but not recommended) or create an
asymmetric key from the assembly file in the master database, create a login that maps to the key, and
grant the login EXTERNAL ACCESS ASSEMBLY permission on the assembly.
MOC 20764C | Administering a SQL Database Infrastructure | Module 03 – Authorizing Users to Access Resources | 8 / 10
Having the same owner for all objects in a schema (which itself also has an owner) simplifies permission
management. However, it is still important to understand that ownership chain problems can occur and
you should know how to resolve them.
Ownership chaining applies to stored procedures, views, and functions. The slide shows an example of
how ownership chaining applies to views or stored procedures.
1. User1 has no permissions on the table owned by User2.
2. User2 creates a view that accesses the table and grants User1 permission to access the view. Access is
granted as User2 is the owner of both the top level object (the view) and the underlying object (the
table).
3. User2 then creates a view that accesses a table owned by User3. Even if User2 has permission to
access the table and grants User1 permission to use the view, User1 will be denied access because of
the broken chain of ownership from the top level object (the view) to the underlying object (the
table).
4. However, if User3 grants User1 permissions directly on the underlying table, he can then access the
view that User2 created to access that table.
MOC 20764C | Administering a SQL Database Infrastructure | Module 03 – Authorizing Users to Access Resources | 9 / 10
Lesson Objectives
After completing this lesson, you will be able to:
Describe user-schema separation.
Describe the role of object name resolution.
Grant permissions at schema level.
Note: If you are upgrading applications from SQL Server 2000 or earlier versions, note that
schemas were not used then, and that the naming convention consisted of
Server.Database.Owner.Object. When upgrading databases, SQL Server will automatically create a
schema using the same name as the object owner.
You can assign a default schema to users; this is used when a user refers to an object without specifying a
schema name.
There are a few built-in schemas in SQL Server. The dbo and guest users have associated schemas
attached to their own names. The sys and INFORMATION_SCHEMA schemas are reserved for system
objects that you cannot drop or create objects in.
MOC 20764C | Administering a SQL Database Infrastructure | Module 03 – Authorizing Users to Access Resources | 10 / 10
SQL Server then has to determine which Product table to use. Most users have a default schema
that is inferred when a schema is not specified. If a user does not have a default schema, SQL Server
assumes the dbo schema.
In SQL Server 2012 and later versions, you can assign a default schema to a Windows Group to
accommodate users created from certificates.
Note: Creating users from certificates is an advanced topic that is beyond the scope of this
course.
When locating an object, SQL Server will first check the user’s default schema. If the object is not found,
SQL Server will then check the dbo schema. Therefore, it is important to include schema names when
referring to an object, as shown in the following example:
Locating Objects
Apart from rare situations, using multipart names leads to more reliable code that does not depend on
default schema settings.
Granting Permissions
USE MarketDev;
GO