Hướng dẫn học Microsoft SQL Server 2008 part 122 pdf

Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1172
Part VII Security
Windows Security
Because SQL Server exists within a Windows environment, one aspect of the security strategy must be
securing the Windows server.
Using Windows Security
SQL Server databases frequently support websites, so Internet Information Server (IIS) security and
firewalls must be considered within the security plan.
Windows security is an entire topic in itself, and therefore outside the scope of this book. If, as a DBA,
you are not well supported by qualified network staff, then you should make the effort to become profi-
cient in Windows Server technologies, especially security.
SQL Server login
Don’t confuse user access to SQL Server with SQL Server’s Windows accounts. The two logins are
completely different.
SQL Server users don’t need access to the database directories or data files on a Windows level because
the SQL Server process, not the user, performs the actual file access. However, the SQL Server process
needs permission to access the files, so it needs a Windows account. Three types are available:
■ Local user account: If network access is not required, this is a viable option. Local user
accounts cannot be used outside the server.
■ Local system account: SQL Server can use the local system account of the operating system
for permission to the machine. This option is adequate for single-server installations, but fails
to provide the network security required for distributed processing. The local system account
has more rights than even a member of the Administrators account because the local system
account has implicit privileges in the operating system and Active Directory that go beyond
membership in the Administrators group.
■ Domain user account (recommended): SQL Server can use a Windows user account created
specifically for it. The SQL Server domain user account can be granted administrator rights for
the server and can access the network through the server to talk to other servers.
The SQL Server accounts were initially configured when the server was installed. Installa-
tion is discussed in Chapter 4, ‘‘Installing SQL Server 2008.’’
Server Security

SQL Server uses a two-phase security-authentication scheme. The user is first authenticated to the server.
Once the user is ‘‘in’’ the server, access can be granted to the individual databases.
SQL Server stores all login information within the
master database.
1172
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1173
Authenticating Principals 49
SQL Server authentication mode
When SQL Server was installed, one of the decisions made was which of the following authentication
methods to use:
■ Windows Authentication mode: Windows authentication only
■ Mixed mode: Both Windows authentication and SQL Server user authentication
This option can be changed after installation in Management Studio, in the Security page of the SQL
Server Properties dialog, as shown in Figure 49-2.
FIGURE 49-2
Server-level security is managed in the Security tab of the SQL Server Properties dialog.
From code, the authentication mode can be checked by means of the xp_loginconfig system stored
procedure, as follows:
1173
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1174
Part VII Security
EXEC xp_loginconfig ‘login mode’
Result:
name config_value

login mode Mixed
Notice that the system stored procedure to report the authentication mode is an extended stored proce-
dure. That’s because the authentication mode is stored in the registry in the following entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
MicrosoftSQLServer\<instance_name>\MSSQLServer\LoginMode
A LoginMode value of 1 is for Windows authentication; 0 is for mixed mode. The only ways to set the
authentication mode are to use either Management Studio or RegEdit.
Windows Authentication
Windows Authentication mode is superior to mixed mode because users don’t need to learn yet another
password and because it leverages the security design of the network.
Using Windows Authentication means that users must exist as Windows users in order to be recognized
by SQL Server. The Windows SID (security identifier) is passed from Windows to SQL Server.
Windows Authentication is very robust in that it will authenticate not only Windows users, but also
users within Windows user groups.
When a Windows user group is accepted as a SQL Server login, any Windows user who is a member
of the group can be authenticated by SQL Server. Access, roles, and permissions can be assigned for the
Windows user group, and they will apply to any Windows user in the group.
Best Practice
I
f the Windows users are already organized into groups by function and security level, using those groups
as SQL Server users provides consistency and reduces administrative overhead.
SQL Server also knows the actual Windows username, so the application can gather audit information at
both the user level and the group level.
Adding a new Windows login
Windows users are created and managed in various places in the different Windows versions. In
Windows Vista, local users can be managed by selecting Control Panel ➪ Administrative Tools ➪
Computer Management, as shown in Figure 49-3. Domain users are managed with tools such as the
Active Directory Users and Computers snap-in.
1174
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1175
Authenticating P rincipals 49
Once the users exist in the Windows user list or the Windows domain, SQL Server can recognize them.

To add a new login to SQL Server using Object Explorer, follow these steps:
1. Open the Security ➪ Logins node under the server and use the context menu to select New
Login.
2. In the General page of the Login-New dialog (see Figure 49-4), use the Search button to locate
the Windows user.
3. You may enter a username or group name or use the Advanced button to search for a user.
FIGURE 49-3
Windows users are managed and assigned to Windows groups by means of the Computer Management
tool.
The user may be assigned a default database and language at the bottom of the SQL Server Login Prop-
erties dialog. Note that assigning a default database does not automatically grant access to that database.
The user may be granted access to databases in the Database Access tab. (Database access is discussed
in the next section.)
To use T-SQL code to add a Windows user or group, run the
CREATE LOGIN command. Be sure to use
the full Windows username, including the domain name, as follows:
CREATE LOGIN ‘XPS\Joe’
To view Windows logins using code, query the sysserver_principals catalog view.
1175
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1176
Part VII Security
FIGURE 49-4
Use the General page of the Login-New dialog to create and edit user logins at the server level.
The Login-New dialog is also used to manage existing users. To open the Login Permission version
of the dialog for an existing user, select the user under the Security ➪ Logins node and use the context
menu’s Properties command or double-click the user.
Removing a Windows login
Removing a windows login from SQL Server is simple enough with Management Studio. Select the login
in Object Browser and use the context menu to delete the user. Of course, this doesn’t delete the user

from Windows; it only removes the user from SQL Server.
To remove a Windows user or group from SQL Server, use the
DROP LOGIN command. The Windows
user or group will exist in Windows; it just won’t be recognized by SQL Server:
DROP LOGIN ‘XPS\Joe’
1176
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1177
Authenticating P rincipals 49
Denying a Windows login
Using the paradigm of grant, revoke, and deny, a user may be blocked for access using ALTER LOGIN
for Windows users and DENY CONNECT for Windows groups. This can prevent users or groups from
accessing SQL Server even if they could otherwise gain entry from another method.
For example, suppose the Accounting group is granted normal login access, while the Probation group
is denied access. Joe is a member of both the Accounting group and the Probation group. The Probation
group’s denied access blocks Joe from the SQL Server even though he is granted access as a member of
the Accounting group, because deny overrides grant.
To deny a Windows user or group, use the
DENY CONNECT command. If the user or group being
denied access doesn’t exist in SQL Server, then
DENY CONNECT adds and then denies him, her, or it:
DENY CONNECT ‘XPS\Joe’
To restore the login after denying access, you must first grant access with the sp_grantlogin system
stored procedure.
You can deny the ability to log in using T-SQL.
Setting the default database
The default database is set in the Login Properties form in the General page. The default database can be
set from code by means of the
ALTER LOGIN command:
ALTER LOGIN ‘Sam’, ‘OBXKites’

Orphaned Windows users
When a Windows user is added to SQL Server and then removed from the Windows domain, the user
still exists in SQL Server but is considered orphaned. Being an orphaned user means that although SQL
Server still has the Windows account listed within SQL Server, it doesn’t exist any longer in the domain;
therefore, no access is provided as a result. Even if the Windows account is recreated, it will have a new
SID and GUID, and therefore won’t match up.
The
sp_validatelogins system stored procedure locates all orphaned users and returns their
Windows NT security identifiers and login names. In the following code example, Joe was granted
access to SQL Server and then removed from Windows:
EXEC sp_validatelogins
Result (formatted):
SID NT Login

0x010500000000000515000000FCE31531A931 XPS\Joe
This is not a security hole. Without a Windows login with a matching SID, the user can’t log into SQL
Server.
To resolve the orphaned user:
1. Remove the user from any database access using
DROP LOGIN.
2. Revoke the user’s server access using
sp_revokelogin.
1177
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1178
Part VII Security
Security delegation
In an enterprise network with multiple servers and IIS, logins can become a problem because a user
may be logging into one server that is accessing another server. This problem arises because each server
must have a trust relationship with the others. For internal company servers, this may not be an issue,

but when one of those servers sits in a DMZ on the Internet, you may not want to establish that trust,
as it presents a security hole.
Security delegation is a Windows feature that uses Kerberos to pass security information among trusted
servers. For example, a user can access IIS, which can access a SQL Server, and the SQL Server will see
the user as the username even though the connection came from IIS.
A few conditions must be met in order for Kerberos to work:
■ All servers must be running Windows 2000 or later, running Active Directory in the same
domain or within the same trust tree.
■ The ‘‘Account is sensitive and cannot be delegated’’ option must not be selected for the user
account.
■ The ‘‘Account is trusted for delegation’’ option must be selected for the SQL Server service
account.
■ The ‘‘Computer is trusted for delegation’’ option must be selected for the server running SQL
Server.
■ SQL Server must have a Service Principal Name (SPN), created by
setspn.exe, available in
the Windows 2000 Resource Kit.
Security delegation is difficult to set up and may require the assistance of your network domain adminis-
trator. However, the ability to recognize users going through IIS is a powerful security feature. Executing
SETSPN to add or delete an SPN does require domain admin rights.
SPN is a powerful security feature, but it does weaken security because the user is being impersonated.
Therefore, its use should generally be restricted to those cases where it’s absolutely necessary. Uncon-
strained delegation should be avoided at all costs.
SQL Server logins
The optional SQL Server logins are useful when Windows authentication is inappropriate or unavail-
able. It’s provided for backward compatibility and for legacy applications that are hard-coded to a SQL
Server login.
Best Practice
I
mplementing SQL Server logins (mixed mode) will automatically create an sa user, who will be a member

of the sysadmin fixed server role and have all rights to the server. An sa user without a password is very
common and the first attack every hacker tries when detecting a SQL Server. Therefore, the best practice is
to disable the sa user and assign different users, or roles, to the sysadmin fixed server role instead.
1178
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1179
Authenticating P rincipals 49
To manage SQL Server users in Management Studio, use the same Login-New dialog used when adding
Windows users, but select SQL Server Authentication.
In T-SQL code, use the
CREATE LOGIN command. Because this requires setting up a user, rather than
just selecting one that already exists, it’s more complex than adding a
sp_grantlogin. Only the login
name is required:
CREATE LOGIN ‘login’, ‘password’, ‘defaultdatabase’,
‘defaultlanguage’, ‘sid’, ‘encryption_option’
For example, the following code adds Joe as a SQL Server user and sets his default database to the
OBXKites sample database:
EXEC sp_addlogin ‘Sam’, ‘myoldpassword’, ‘OBXKites’
The encryption option (skip_encryption) directs SQL Server to store the password without any
encryption in the
sysxlgns system table. This option tells SQL Server that the value being passed is
already encrypted, so the password won’t work. Avoid this option.
The server user ID, or SID, is an 85-bit binary value that SQL Server uses to identify the user. If the
user is being set up on two servers as the same user, then the SIDs need to be specified for the second
server. Query the
sys.server_principals catalog view to find the user’s SID:
SELECT Name, SID
FROM sys.server_principals
WHERE Name = ‘Sam’

Result:
Name SID

Sam 0x1EFDC478DEB52045B52D241B33B2CD7E
Updating a password
The password can be modified by means of the ALTER LOGIN command:
ALTER LOGIN ‘myoldpassword’, ‘mynewpassword’, ‘Joe’
If the password is empty, use the keyword NULL instead of empty quotes (‘ ’).
Removing a login
To remove a SQL Server login, use the DROP LOGIN command:
DROP LOGIN ‘Joe’
Removing a login also removes all the login security settings.
1179
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1180
Part VII Security
Setting the default database
The default database is set in the Login Properties form in the General page, just as it is for Windows
users. The default database can be set from code by means of the
ALTER LOGIN command:
ALTER LOGIN ‘Sam’, ‘OBXKites’
Server roles
SQL Server includes only fixed, predefined server roles. Primarily, these roles grant permission to
perform certain server-related administrative tasks. A user may belong to multiple roles.
The following roles are best used to delegate certain server administrative tasks:
■ Bulkadmin: Can perform bulk insert operations
■ Dbcreator: Can create, alter, drop, and restore databases
■ Diskadmin: Can create, alter, and drop disk files
■ Processadmin: Can kill a running SQL Server process
■ Securityadmin: Can manage the logins for the server

■ Serveradmin: Can configure the serverwide settings, including setting up full-text searches and
shutting down the server
■ Setupadmin: Can configure linked servers, extended stored procedures, and the startup stored
procedure
■ Sysadmin: Can perform any activity in the SQL Server installation, regardless of any other
permission setting. The sysadmin role even overrides denied permissions on an object.
SQL Server automatically creates a user, BUILTINS/Administrators, that includes all Windows users in
the Windows Admins group and allows a choice of what groups or users are added during setup. The
BUILTINS/Administrators user can be deleted or modified if desired.
If the SQL Server is configured for mixed-mode security, it also configures the sa account to be disabled.
The sa user is there for backward compatibility.
Best Practice
D
isable or rename the sa user, or at least assign it a password, but don’t use it as a developer and DBA
sign-on. In addition, delete the BUILTINS/Administrators user. Instead, use Windows authentication
and assign the DBAs and database developers to the sysadmin role.
A user must reconnect for the full capabilities of the sysadmin role to take effect.
The server roles are set in Management Studio in the Server Roles page of the Login Properties dialog
(see Figure 49-5).
1180
www.getcoolebook.com
Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1181
Authenticating P rincipals 49
FIGURE 49-5
The Server Roles page is used to assign server administrative rights to users. Here, the Windows
Admin group is granted the sysadmin role.
In code, a user is assigned to a server role by means of a system stored procedure:
sp_addsrvrolemember
[ @loginame = ] ‘login’,
[ @rolename = ] ‘role’

For example, the following code adds the login ‘‘XPS\Lauren’’ to the sysadmin role:
EXEC sp_addsrvrolemember ‘XPS\Lauren’, ‘sysadmin’
The counterpart of sp_addsrvrolemember, sp_dropsrvrolemember, removes a login from a
server fixed role:
EXEC sp_dropsrvrolemember ‘XPS\Lauren’, ‘sysadmin’
1181
www.getcoolebook.com