SQL Server 2005 - Managing Permissions

SQL Server 2005 - Managing Permissions

In this tutorial you will learn about Managing Permissions in SQL Server 2005. Authorization features determine the level of access rights once the user’s logon process is successfully completed. A significant aspect of SQL Server 2005 authorization mode is the user-schema separation. The schema forms the namespace boundaries and no two objects residing in the schema can have the same name.

The objects also have four distinct parts—ServerName, DatabaseName, SchemaName and ObjectName. Secondly all objects within the schema have the same owner. The schema can be owned by a database roles and Windows groups. The schema name is not equivalent to the name of the database user and this eliminates many of the problems associated with this design. As a result of this kind of schema definition, application specific schemas can be created and consistent schema names can be assigned.

An SQL Server 2005 database contains a number of automatically created schemas corresponding to pre-defined database users and to fixed database roles. The list of schemas can be viewed in the catalog view.

Default schema on a per database user basis can also be created using the DEFAULT_SCHEMA option of CREATE USER and ALTER USER T-SQL statements. Object names specified in a non-fully qualified format can be resolved using the default after a check of the sys schema. The use of default schema makes for a common name resolution mechanism.

A new schema can be created using the CREATE SCHEMA T-SQL statement with the AUTHORIZATION clause giving the user or role as the owner. The ALTER SCHEMA statement can be used to change the role or owner.

The module execution context feature of SQL Server 2000 is still applicable in SQL Server 2005. This is called ownership chaining or a process whereby the application checks whether the owner of one object has the right to access another object which is located in another module. This type of ownership chaining has limitations by the fact that it applies only to Data modification language statement and not data definition language statements or dynamic queries. SQL Server goes ahead to provide the DBA with an ability to alter the execution context with the EXECUTE AS clause which is part of the definition of stored procedures, functions, queues and triggers. This impacts the user accounts that is used to evaluate permission required by objects referenced by the running module. The caller will still require permissions for invoking the module.

The EXECUTE AS clause has the following values which are maintained in the sys.sql_modules catalog view.

EXECUTE AS CALLER is the default value which executes in the context of the caller. Access to objects is evaluated on the basis of standard ownership chaining mechanism. However, since objects are part of schemas and are not owned by individuals, users can have roles assigned to them. The value can also be applied to functions, stored procedures, DDL and DML, triggers and in Service Broker queues.

EXECUTE AS USER provides the security context of a specific database user for the duration of the module execution. The permissions on all referenced objects are evaluated against the user_name that originally called the object. This value can be assigned to functions, stored procedures, DML and DDL and trigger with database scope as well as queues. The creator must be a member of the SysAdmin server role, db_owner database role or have Impersonate permissions on the user account for the module to work.

The EXECUTE AS SELF assigns the user creator with the security context required to execute the module. The ID of this user is stored as metadata and is referenced during module execution. The value can be applied to functions, stored procedures, DDL and DML triggers and queues.

The EXECUTE AS OWNER ensures that the owner of the module is the person with the security context for executing the module. The owner must be an individual user and not a member of the Windows group or database role. The Principal ID value is stored in the execute_as_principal_id column in the sys.sql_modules catalog view and can be referenced during module execution. This can be applied to functions, stored procedures and data modification language triggers with data base scope.

Granular permissions have been enhanced in SQL Server 2005. Though fixed server and database roles introduced in SQL Server 2000 are still supported, custom database roles, application roles, server logins and database users can be granted granunar permissions in the new environment. All securable objects have been grouped into server, database or schema scopes. While server level permission applies to logins, database level permissions are to be assigned to users. The Server level permissions are stored in sys.server_permissions catalog view and Database permissions reside in sys.database_permissions catalog view.

Permissions can be granted, denied or revoked. The permissions at higher levels are reflected granularly at the lower levels. This simplifies the implementation rule of least privilege. The common permissions of SQL Server 2000 and earlier such as EXECUTE, SELECT, or TAKE OWNERSHIP have been extended to offer new possibilities of implementation. Several new permissions have also been introduced in the Beta version. CONTROL gives all permissions to the object owner. ALTER permits the object owner to alter the properties of the object. This can be limited by the scope. ALTER TRACE allows the user run the Profiler without being a member of the SysAdmin fixed server role. IMPERSONATE permits the owner to impersonate another. VIEW DEFINITION provides a read access to an object’s metadata via catalog views.

Users are no longer permitted to directly access tables. Instead they are given access through views that encompass the server and the database settings. The permissions are set on row level. Owners can see the objects they own through catalog views and the content can be reviewed using the ANSI INFORMATION_SCHEMA views. Catalog views can be accessed using the GUI or referencing the sys.system_views using a T-SQL statement.

The SQL Server Agent operations in SQL Server 2005 has been divorced from the local Administrators group. It is no longer necessary because multiple proxy accounts can be created and separate ones assigned to individual steps of any SQL server Agent job. The required permissions and their configuration options have been changed as well. The user is required to be a member of SQLAgenetUserRole in msdb if he must create or execute jobs. Members of the SysAdmin alone can create or manage proxy accounts or define job steps that run in the security context of the SQL Server Agent account.

SQL Profiler auditing covers SQL Server 2005 activities and events generated by SQL Server 2005 Analysis Services. Enhanced auditing features also make it possible to assign triggers to Data Definition Language operations such as CREATE, ALTER and DROP.

SQL Server 2005 signatures also offer security for codes and modules. A resource can be accessed only by those who have the authority via a designated module (such as stored procedure). The new digital signatures can be executed without concern about ownership chaining, or granting direct access to underlying table or view. The access module is signed with a private key contained in a certificate to which the user is assigned permissions. When the module is launched, the certificate is added to the user’s access token.