SQL Server Security and User Administration

Basic concepts of SQL Server security Authentication modes Logins Database components

Every user that connects to SQL Server must have a valid login id, and that login id must be registered with SQL Server.

SQL Server Security and User Administration

Training Division New Delhi

Basic concepts of SQL server security

SQL server security starts with login, the server and its databases

Databases

Access to SQL Server

Clients (users/applications) connect to SQL Server by having a login that SQL Server can authenticate. That login may be a SQL Server login or a Windows NT login.

There are two kinds of logins: SQL Server and Windows NT

Logins
SQL Server Windows NT NT Groups NT Users

Logins
SQL Server logins consist of a login name and password that are stored in SQL Server. Windows NT logins are Windows NT user names or groups that are registered by the system administrator within SQL Server. With Windows 95 and 98, all you can use are SQL Server logins.

Logins can have two levels of access, the server level and the database level

Server Roles

Database Users and Roles Application Roles

Permissions

Database Objects

Authentication and Permission

Once a login has access to a particular SQL Server, the user may perform server-level tasks or database-level tasks.

Authentication and Permission

At the database level, all the data in a database is stored in and accessed by database objects. Every object in a database is owned by some entity, called the database object owner. These object owners are identified in the database as database users, though not all database users must own objects. Database users, in turn, can be associated with database roles.

Authentication and Permission

In addition to database users and roles, SQL Server 7 also introduces application roles, which contain sets of privileges that an application can switch to after logging in. To gain access to database objects, every login must be mapped either to a database user or to an application role.

Note
The upshot is that to gain access to a database, every login must have some explicit or implicit mapping to a database user application role in that database.

Implementing security
When you log into a fresh SQL Server installation, SQL Server security can seem invisible. When you use the sa login, or you use a trusted connection and your NT login belongs to that machine's NT administrators group, you can immediately access all the databases and their objects (tables, views, stored procedures, and so forth).

Implementing security
BECAUSE every database object in all the standard databases is owned by a database user, present in each database, called dbo (abbreviation for database owner), and those privileged logins automatically map to the dbo of every database.

Implementing security
BECAUSE every database object in all the standard databases is owned by a database user, present in each database, called dbo (abbreviation for database owner), and those privileged logins automatically map to the dbo of every database.

Note
Any login with system administrator rights can immediately see all the database objects of every database in the server. Therefore, implementing SQL Server security consists of using logins other than sa or an NT login with local Administrator rights.

Warning
If you only use the sa login or an NT login that belongs to the local machine's Administrators group, you are bypassing SQL Server security.

Authentication Modes
SQL Server really has three total security authentication modes:
SQL Server authentication only (Windows 9x ) "standard security SQL Server and Windows NT authentication "mixed" security Windows NT authentication only "integrated" security

SQL Server Logins

SQL Server comes preinstalled with one SQL Server login, sa, short for system administrator. The sa login automatically has administrative rights over the entire SQL Server and its databases.

SA login
Every SQL Server login requires a password. In the case of sa, it is initially set to blank (no password at all). Dont leave it blank, change it for security reasons.

Server Roles
In prior releases of SQL Server, you would have to log into SQL Server as sa in order to do any kind of maintenance activity. With SQL Server 7, the sa functionality has been subdivided into a set of server roles. These server roles stand between the logins and the server.

Server roles stand between logins and the server

Server Roles
Logins
SQL Server Windows NT NT Groups NT Users

Fixed Server Roles

sysadmin All system administrative functions serveradmin Administer server configurations setupadmin Administer replication and extended stored procedures securityadmin Administer security processadmin Administer processes dbcreator Create, alter, and rename databases diskadmin Administer disk files

Fixed Server Roles

The sysadmin server role is equivalent to the sa login; in fact, the sa login is automatically given the sysadmin server role and cannot be removed from it. The addition of server roles makes it possible to delegate server administrative tasks to other logins and keep the number of people who must use the sa login or the sysadmin role to a minimum. The number and nature of the server roles is fixed. You cannot add or modify their properties.

Warning
The Administrators group of the server computer automatically has a login into the server and belongs to the sysadmin server role. So if an NT user belongs to the administrators group of the local machine, that user can immediately log into the SQL Server and has sysadmin (and therfore sa) privileges. You can deny access to the BUILTIN\Administrators group to deny such users access to the server.

Every database contains database objects, user and roles

Server Roles
Logins
SQL Server Windows NT NT Groups NT Users

Database roles Database users

Database Objects

Database Access
SQL Server data is contained in databases. Just connecting to SQL Server will not by itself allow access to the server's data. Consequently, there must be some means of mapping authenticated logins to data in databases. The way SQL Server accomplishes this is by three components inside a database: database objects, database users, and database roles.

Each login is mapped to one user per database

Server Roles
Logins
SQL Server Windows NT NT Groups NT Users

Database roles Database users

Database Objects

Database Objects
The database objects are the tables, indexes, triggers, defaults, constraints, riles, views, and stored procedures in the database.

Database Users
Database users are the names of the owners and users of the database objects.

Database Roles
Database roles are groupings of users. Both database users and roles can be granted and denied permissions to the database objects.

Database Access
Every database object is owned by exactly one database user. The only way you can access a database object is by either being the object's owner or having access to the object granted to you by the object's owner. Every database has at least one database user the dbo. The dbo owns all the system tables in a database, as well as all objects created by the sa login or sysadmin role.

Note
When you log in as sa or have a login that gives you the sysadmin role, you can automatically see all the objects in a database that are owned by dbo. These include all the system databases such as master, msdb, model, and tempdb, as well as the entire pubs databse. Then all objects you create under such logins become owned by dbo.

Mapping a login to a database

A SQL Server login gains access to a database object by having a login that maps to a database user. The sa login, NT user logins that are part of the local Administrators group, and any logins with sysadmin server roles are all automatically mapped to the dbo users in every database. Every other login must either be explicitly mapped to a database user to gain access to a database or implicitly mapped to the guest user or public role.

Note
The key concept here is that without the mapping of a login to a database user, no login can access a database's data. You can map a login to only one database user per database, but you can map that login to more than one database at a time.

Database User dbo

Every database has at least one database user, namely the database owner, or dbo. The dbo owns all the system tables in the database. Every sa login or any NT login with the sysadmin server role automatically becomes the dbo in the database.

Database User guest

An optional database user is assigned the keyword guest. If you add a database user with that name to the database, then all logins that are not already mapped to some other user in the database become implicitly mapped to the guest database user. You can use the guest database user to establish a minimal public sort of access to a database.

Database users contd.

Every database user can be given a set of permission to the database objects. The dbo starts out automatically with all permissions, but you must explicitly set all permissions for other database users. However, you can take a shortcut by making your users members of one or more database roles.

Database Roles
Database roles are ways of grouping users together so that they inherit the permissions of the roles, so that you do not have to explicitly grant permissions for each database user.

Database roles
Fixed standard Server Subdivisions of dbo rights supplied by SQL Server Custom standard Roles created by the database administrator Application Roles for applications that bypass database users

Fixed database roles

db_owner db_accessadmin db_datareader db_datawriter db_ddladmin db_securityadmin db_backupoperator db_denydatareader db_denydatawriter All dbo rights Administer user, NT groups, and NT users Read access to all data in the database Write access to all data in the database Create, alter, and drop rights to all database objects Manage roles, role membership, and permissions Manager backups and restore Cannot read data, but can make schema changes Cannot change any data in the database

The database user, dbo, is automatically a member of the db_owner role. You cannot add new fixed database role.

Custom standard roles

With custom standard database roles, you define your own database roles and then grant permissions to each role. All permissions granted to these roles are inherited by their members, unless explicitly denied.

Application roles
Application roles are a special kind of role that can be used to switch the permissions that a login would normally have, based on a password sent to the system. In this way, someone running an application could get permissions to database objects that they would never get using their own login.

Application roles
If the users log in without the application, you might deny them access to the database objects. However, when they run the application, the application can assume the application role that does give access to the database objects.

Application roles
Application can use the application role to gain new security without logging off and logging into SQL Server.

Permissions
After a database has database users and roles, you can grant permissions to database objects through them.

You can set permissions to database objects for both database users and database roles

Server Roles
Logins
SQL Server Windows NT NT Groups NT Users

Standard roles Database users Application roles

Database Objects

Permissions
Every object in a database has an owner, and an object owner is always a database user. Database objects include tables, views, and stored procedures etc. Normally the creator of the object is its owner. The owner of an object can grant and deny permissions to the object.

Note
The full name of every database object includes the database name, the owner name (a database user), and the object name. Two different users can each create a table or object with the same name in a single database

Assigning permissions
Any login with the sysadmin or securityadmin server roles (therefore including the sa login) can assign permissions to database users and roles, Permissions are assigned with the GRANT, REOVKE , and DENY commands , and the content of the permission is chosen in the body of the command.

GRANT, REVOKE & DENY

These can be applied to a database user or a database role on two levels the database level the object level

GRANT
Applies to the database user or a role. If the role has the GRANT permission, and the permission is not otherwise denied, every database user will inherit the GRANT permission from the role.

REVOKE
When you REVOKE a permission, it removes the prior GRANT permission, if there was one, but does not explicitly prevent a database user from inheriting a GRANT from a database role.

DENY
The DENY action takes precedence over the GRANT action. When you deny a permission to a database user or role, the permission is explicitly removed. Further the deny status overrides all other GRANT permissions in the various roles to which a database user may belong.

Database permissions
You can grant all of the following CREATE or BACKUP statement or a subset of them, to a user or role. CREATE BACKUP
DATABASE DEFAULT PROCEDURE RULE TABLE VIEW DATABASE LOG

Object-level permissions
Table or view
SELECT INSERT UPDATE DELETE DRI

Stored procedure
EXECUTE

Security functions
A full set of security functions exist to find out the login name, user name, and role memberships for each login. You can use these functions to add a further level of security.

Security functions
Some useful security functions : Is_member() suser_sname() user() is_srvrolemember()