132 Chapter4•ManagingSecurity a 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. Te s T Da y Ti p 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. ManagingSecurity•Chapter4 133 Schemas Database 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 ex a m Wa r n i n g Make sure that you understand the difference between a User and Login and their permissions scope. 134 Chapter4•ManagingSecurity granted 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 aD D a Ne w Us e r 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. ManagingSecurity•Chapter4 135 Users 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 136 Chapter4•ManagingSecurity When 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 . 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. 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. 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