SQL Server

SQL server 2008 : Managing Security - Schemas

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
10/24/2010 4:55:19 PM
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 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.
1. 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 1.

    Figure 1. New Database User Properties

  8. Click OK. Your newly created user will appear in the Users folder.

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.

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 2.

Figure 2. SQL Server-Level Logins

2. Create a SQL Server Login

You need to add a new SQL Server Login and it will be mapped to a domain account and be set up to access the AdventureWorks2008 database.

  1. In the SQL Server Management Studio, locate the security folder at the instance level.

  2. Under the security folder you will see a folder named Logins. Right-click on Logins and select New Login from the menu.

  3. In the “Login – New” window in the general section locate the domain account that you need to map to the login. Make sure that Windows authentication is selected.

  4. For the Default Database, select AdventureWorks2008.

  5. Now switch sections and select User Mapping.

  6. In the User Mapping section, locate AdventureWorks2008 in the “Users mapped to this login” section and check the Map column. Your entries should look similar to Figure 3 and Figure 4.

    Figure 3. General Section

    Figure 4. User Mapping Section

  7. Click on OK and you have completed creating a new SQL Server login.

Authentication Mode

When you are installing SQL Server 2008, the selection of an authentication mode for the database engine is required. The choices are either Windows authentication or mixed mode authentication.

If you select the Windows authentication mode, SQL Server authentication will be disabled. Selecting mixed mode authentication enables both Windows and SQL Server authentication. You cannot disable Windows authentication.

When selecting mixed mode authentication you are required to establish a strong password for the sa account. If you selected Windows authentication, the sa account will be created but disabled. It is important to remember this because if you change authentication modes at a later time, you will need to enable this account and establish a password at that point if you wish to use this account.

Changing the authentication mode can be done at anytime but it does require that you restart SQL Server. You can change the authentication mode by right clicking on the server in the SQL Server Management Studio and the change can be made under security in the Server Authentication section. See Figure 5.

Figure 5. SQL Server – Server Authentication Properties

Using Windows Authentication (integrated security) is recommended and considered to be more secure than using SQL Server logins or mixed mode. Windows accounts are subject to the built-in security features in Windows and are sometimes considered to be Trusted connections to SQL Server since Windows handles the authentication.

If you are using mixed mode, Any SQL Server Logins created that are not based on Windows user accounts are required to follow strong password guidelines. Database users using SQL Server logins will need to login using a user name and password every time they connect.

SQL Server logins offer the following password policies:

  • User must change password at next login – Established in the Log-in properties in the SQL Server Management Studio.

  • Enforce Password Expiration – Based on the maximum password age policy of the computer.

  • Enforce Password Policy – SQL Server enforces Windows password policies established on the computer. This is only available in Windows 2003 Server and later.

When you are establishing using SQL Serving authentication, it is important to be aware of the disadvantages and advantages. Here are some of the disadvantages:

  • A Windows domain user who has a Windows user id and password will have to also enter their SQL Server user id and password. The user will have to present the SQL Server credentials every time they connect, and maintaining multiple user ids and passwords can be troublesome for users.

  • SQL Server Logins cannot not take advantage of the Kerberos security protocol that is used by Windows.

  • SQL Server Logins cannot offer many of the additional Windows password policies.

Here are some of the advantages:

  • SQL Server can support older applications that require the use of SQL Server Logins.

  • Users in an environment of mixed operating systems where users are not authenticated by a Windows domain can connect to SQL Server.

  • Users can connect from unknown or untrusted domains.

  • Users can connect when creating their own identities in Web-based applications.

  • Software developers can distribute applications based on specific SQL Server Logins.

3. Change the Authentication Mode

You selected mixed mode authentication when you installed SQL Server 2008. You have done some research and have found that none of the applications connected to SQL Server are depending on SQL Server Logins so you want to make your environment more secure and have decided to switch the Authentication Mode to Windows Authentication exclusively.

  1. In the SQL Server Management Studio, right-click on the server and select Properties from the menu.

  2. In the Security Authentication section of the screen, select Windows Authentication. Your screen should look like Figure 6.

    Figure 6. Changing the Authentication Mode

  3. Click on OK to save the change.

  4. Restart SQL Server.

Other -----------------
- SQL server 2008 : Managing Security - Users
- SQL server 2008 : Managing Security - Roles
- SQL Server 2008 : Managing Remote Servers
- Linked Servers
- Adding, Dropping, and Configuring Linked Servers
- Mapping Local Logins to Logins on Linked Servers
- Obtaining General Information About Linked Servers
- Executing a Stored Procedure via a Linked Server
- Setting Up Linked Servers Using SQL Server Management Studio
- Encryption basics for SQL Server : Cryptographic Keys
- Encryption basics for SQL Server : Key Maintenance
- Encryption basics for SQL Server : Key Algorithms
- SQL Server 2005 : Performing Database Backups
- SQL Server 2005 : Restoring Data from a Backup
- SQL Server 2005 : Using Database Snapshots
- SQL Server 2005 : Automating Maintenance with Job Scheduling
- Other SQL Server XML Support
- SQL Server 2005 : Managing XML Data (part 2) - The xml Data Type and Methods
- SQL Server 2005 : Managing XML Data (part 1)
- SQL Server : Removing Unwanted Data
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us