Professional Documents
Culture Documents
Resources
TechNet Belgium & Luxembourg
www.microsoft.com/belux/technet/
Users
CREATE USER [jan] FOR LOGIN
[FlexcomAzlan\jan]
Roles
CREATE ROLE Accounting
Password Policy
Problem with trusted connections
Firewalls
Application can’t choose security context
Sql authentication solves these problems but is less secure
in SQL 2000 because there is no password policy.
SQL 2005 allows you to use the Windows Password Policy
(Complexity requirements, expiration, history …) for sql
logins.
Example:
CREATE LOGIN [Joris]
WITH PASSWORD=N'a_complex_1_password',
DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=ON,
CHECK_POLICY=ON
Securable scopes
Server
Logins, HTTP Endpoints, Certificates,
Databases …
Database
Users, Roles, Tables, Views, Functions,
Assemblies …
Schema
Tables, Views, Functions, Procedures
Examples of using scope
Server scope
GRANT ALTER ON DATABASE :: pubs TO userAlice
GRANT ALTER ANY DATABASE TO loginAlice
Database scope
GRANT SELECT ON DATABASE :: pubs TO jan
GRANT INSERT ON SCHEMA :: test TO jan
Schema scope
GRANT SELECT ON OBJECT :: test.authors TO piet
GRANT SELECT ON dbo.righttest TO piet
Schema
What?
Namespaces for database objects
SQL2000 FQN
<linked server>.<database>.<owner>.<object>
SQL2005 FQN
<linked server>.<database>.<schema>.<object>
Why?
In SQL2000 owner has all the rights on
a object and users can not be dropped
when they own objects, the owner
name is thus not a good candidate to
classify objects by there name.
By using the schema scope you can
manage all similar objects as one unit
Schema scenario
A database contains tables for production,
human resources and sales
Some users do work on production,
human resources and sales
All related tables should have same owner
(authorized user).
Solution:
Create schemas for the production, human
resources and sales tables
Give users (roles) the necessary rights on the
correct schema
Set defaults for users so they can use the
object name
If needed you can move objects to other
schemas or give them different owners
Schema scenario (cont.)
Create a schema
CREATE SCHEMA Production AUTHORIZATION admin
Set the search path for objects to
production.<name> then
dbo.<name>
ALTER USER alice WITH DEFAULT_SCHEMA=Production
Create objects in a schema
(automatically owned by admin)
CREATE TABLE Production.Products (nr int, …)
Schema scenario (cont.)
Give a user (role) select rights on all
the tables in a schema
GRANT SELECT ON SCHEMA :: Production TO managers
Move objects to another schema
ALTER SCHEMA HumanResources TRANSFER
Person.Address
Change the owner of a table
ALTER AUTHORIZATION ON OBJECT::Product to admin
Server level permissions
Delegation of administrative work
SQL2000 (Server roles)
Limited to changing membership of
server roles
SQL2005 (Server level permissions)
Server roles still supported
Possibility to give right on objects in the
server scope or even the server itself
Every permission is now grantable
Examples:
GRANT CONTROL SERVER TO alice
GRANT CREATE ANY DATABASE TO joris
Execution context
SQL2000
The only way to give users rights to execute a
stored procedure (function), even if they have
no rights on the objects used in the stored
procedure, is by a unbroken chain (all objects
references has the same owner as the SP)
SQL2005
You can specify the execution context of a SP
(function) to the following values
CALLER (execute using the identity of the user who
executes the SP (is the SQL2000 case))
SELF (execute using the creators identity)
OWNER (execute using the owners identity)
User_name (specified user)
Execution Context (cont.)
Examples:
Included columns
Partitioning of indexes
Disabling of indexes
Snapshots
Page restore
Online restore
Mirroring