Users Users are database-level principals that are created in order to access resources within a database.. After you have created a login to SQL Server, you create a database user in or
Trang 1a user’s access, thus posing a significant security risk Make sure that you are familiar with what access has been granted to that role or what that permission enables
a user to do If the user does not need to do sysadmin tasks, the user should not
be added to the sysadmin group The same goes for the database-level roles; if they only need to select data from a table, the db_datareader should be sufficient
Not every user needs to be at the db_owner permission level If a user is granted permissions beyond the scope of their specific need, this principle has been violated
TesT Day Tip
Be familiar with the “Principle of Least Privilege” and how that applies
to granting permissions to SQL Server resources.
Users
Users are database-level principals that are created in order to access resources within a database Database Users are typically mapped to a login, certificate, or asymmetric key After you have created a login to SQL Server, you create a database user in order to provide permission to a database and the objects contained within
In order to more easily tie users back to logins, it is recommended that the Log-in and User names match To aid in managing the organization of users permissions, users can be added to any one or more of the available database roles or to new roles that you create
Users can be added to a database using the SQL Server Management Studio
or by syntax such as:
CREATE USER user_name
[ { { FOR | FROM }
{
LOGIN login_name
| CERTIFICATE cert_name
| ASYMMETRIC KEY asym_key_name
}
| WITHOUT LOGIN
]
[ WITH DEFAULT_SCHEMA = schema_name ]
See Figure 4.4
Trang 2Database schemas are collections of objects such as tables, views, and procedures
that enable a powerful way to manage permissions As demonstrated in the
AdventureWorks2008 database, schemas have been set up for business areas such
as Human Resources, Sales, and Purchasing Although all the objects associated
with each business area are contained within the same database, the objects are
logically grouped within the respective schemas, enabling greater control through
permissions As seen in the User section, one schema or multiple schemas can be
Figure 4.4 Database Users
exam Warning
Make sure that you understand the difference between a User and
Login and their permissions scope.
Trang 3granted to a user making it unnecessary to permission each object individual to the user The user is limited to the schemas to which they have been granted access, preventing a user from being able to access objects owned by another user Schemas must be transferred to a different user or role if the schema owner needs to be deleted
ExERciSE 4.2
aDD a New User
You need to explicitly add a SQL Server Login to the
AdventureWorks2008 database so that a user can select data from all the user tables in the Sales schema.
1 in the SQL Server Management Studio, locate the Users folder in the Security folder for the AdventureWorks2008 database.
2 Right-click on the Users folder and select New User from
the menu.
3 in the Database User – New window, you will be mapping your
Login to create this new user, so enter your instancename\your
name in the User name text box.
4 Browse to your Login to complete the Login name text box.
5 Select the Sales schema as the Default schema.
6 Select Sales in the Owned Schemas section.
7 Select db_datareader in the Role Members section Your window
should look similar to Figure 4.5.
8 click OK Your newly created user will appear in the Users
folder.
Trang 4Users versus Logins
We have already touched on the definition of both Users and Principals We will
now take a look at Logins and how they relate to users and other instance and
database securables
When you are setting up users and logins it is important to distinguish between
Authentication: identifying users and determining if they are who they say they are,
and Authorization: what level of access should the user have, what permissions do
they have, and to which resources do they have access
Logins are created at the instance level and can be mapped to a Windows user
account, a domain account, a Windows group, a domain group, or an isolated login contained within SQL Server Setting up a SQL Server Login provides a user
access to the SQL Server instance While setting up a login, you can provide
access to one or more databases Logins do not provide access to the objects
contained within the database Permissions to access database objects are at the
database user level
Figure 4.5 New Database User Properties
Trang 5When the SQL Server instance has been set up to use Windows Authentication mode, referred to as “integrated security,” mapping a Windows account, group or domain account, or group to a login enables a Windows user to login into SQL Server using their Windows credentials They do not need a separate SQL Server Login If a SQL Server specific login has been created when the SQL Server instance has been set up to use mixed mode authentication, the Windows user will need to log in into their Windows account and then be prompted to enter their SQL Server user name and password when accessing SQL Server This can be a nightmare for both the DBA and user if attempting to keep Windows and SQL Server Logins in sync SQL Server logins cannot not be used if the server is using the Windows Authentication mode
Mapping the Windows account, group or domain account, or group to a SQL Server login will eliminate multiple logins since SQL Server will validate the user
by checking their Windows credentials Maintenance of user passwords is done within Windows and if mapping groups to a login, the adding and deleting of users from the group is transparent to the DBA
An example of logins can be seen in Figure 4.6
Figure 4.6 SQL Server-Level Logins