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