SQL Server Security

There are several levels of security to SQL Server. At the a base level, in order to be granted get access to a SQL Server, a user is required to have a login account.

There are two modes of security to SQL Server, distinguished by which program provides the authentication. NT Authentication provides that Windows NT (and/or its successors) verify verifies the identity of a user logging in. In this mode, the SQL Server will ‘trust' that Windows NT has verified that the user is who he says he is. The second method, SQL Server authentication, it is SQL: Server that authenticates the identity of the user. SQL Server authentication is typically used for internet Internet connections, since not all internet Internet users have Windows NT, and not all NT domains are trusted.

In addition to identifying users, it is sometimes convenient to define roles at the server level. Since within an organization, there are groups of users with similar access needs and levels, it may be convenient to define roles with specific levels of permissions. Once you have defined a role, you can assign users to that role, and those users inherit all of the privileges assigned to the role.

There are two types of permissions assigned to individual users and roles. Statement permissions confer the right to execute certain types of T-SQL commands. Object permissions confer the right to access database objects directly.

Defining Logins Users, and Roles

Logins can be added either through the Database Properties Window (under Logins), or by invoking system stored procedures with appropriate parameters. The command
sp_addlogin loginname, password, databasename
will add a SQL Server authenticated login to the list;
sp_grantlogin ‘domainname/username'

will add an NT authenticated login to the list.

After the login has been allowed, you need to allow the user access to the database. This is done either through the Database Properties Window (under Users for that particular database) or with the command
sp_grantdbaccess loginname.

You can see the list of users using the command sp_helpuser or sp_helpuser username

To cancel a security account for a given database, use sp_revokedbaccess username

To remove an NT Login use sp_revokelogin ‘username' (note no domain), and to srop stop a SQL Server authenticated login, use sp_droplogin username .

To add a role to a database, use sp_addrole ‘clerical', and to add meAugust 16, 2005er ‘clerical', ‘username'. To delete a rolemember use sp_droprolemember username.

At the SQL Server level the rolenames are fixed, and cannot be changed, but users can be added using sp_addsrvrolemember username, dbcreator . To drop a rolmember, use sp_dropsrvmember username .

Granting permissions

The GRANT command is used to assign permissions to a security account. Statement permissions in this way: GRANT right TO username

where right can be any of the following:
CREATE DATABASE
CREATE DEFAULT
CREATE PROCEDURE
CREATE RULE
CREATE TABLE
CREATE VIEW
DUMP DATABASE
DUMP TRANSACTION

For object permissions, GRANT is also the command to use, but the grammar differs slightly:
GRANT action ON table/view/procedure name TO username

where action can be one of the following:
INSERT, DELETE, EXECUTE, SELECT or UPDATE

One can also apply these this permission to groups or roles as well as usernames. And it is also possible that a role can have a permission, but a member of that role be denied permission for a task. See the next discussion.

In all of the above commands, you can also explicitly deny permission using DENY in place of GRANT.

Note however that DENY is not the negation of GRANT . DENY explicitly excludes the user from that capability. The REVOKE command is used to remove both the permission and refusal.
Resources

• Article: How To Identify Your SQL Server Service Pack Version and Edition
This is an insightful article that discusses about SQL server pack version and edition.
• Tutorial: Using Access or SQL Server to Write your ASP Code
This tutorial discusses how SQL server can be used to write the ASP code.

Share/Bookmark

No comments: