Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1162 Part VI Enterprise Data Management Another way to find this information is to open the SQL Server Errorlog and search for the line ˝ The NETBIOS name of the local node that is running the server is˝.This information becomes especially important during postmortem analysis. ■ Sometimes the DBA may not even know if the SQL Server 2008 instance she is administering is a clustered instance or a stand-alone instance. To find out if the current SQL Server instance is clustered, execute the following command: SELECT SERVERPROPERTY(’IsClustered’); If this is a SQL Server 2008 failover clustering instance, then it will return a value of 1; otherwise, it will return a value of 0. ■ To view the cluster nodes on which the SQL Server 2008 failover clustering instance can run, use the sys.dm_os_cluster_nodes dynamic management view (DMV) as shown: SELECT * FROM sys.dm_os_cluster_nodes; ■ To view the shared disks that the SQL Server 2008 failover clustering instance can access, use the sys.dm_io_cluster_shared_drives DMV as shown: SELECT * FROM sys.dm_io_cluster_shared_drives; A SQL Server 2008 failover clustering instance can only use shared drives for its databases. It cannot use local drives, not even for the tempdb database that is created every time SQL Server is started. The sys.dm_io_cluster_shared_drives DMV will display all the shared drives SQL Server 2008 can access. These are the drives that were selected during the installation. ■ To add a new shared drive, perform the following steps: 1. Open the Cluster Administrator tool in Windows 2003 Failover Cluster or the Failover Cluster Management tool in Windows 2008 Failover Cluster. 2. Move the shared disk to the SQL Server 2008 group. 3. Right-click the SQL Server resource and select Take Offline. This will disconnect the clients, so it should be planned in advance. 4. Right-click the SQL Server resource and select Properties. Click the Dependencies tab and select Modify. Add the new shared drive as a dependency to SQL Server. 5. Bring the SQL Server resource online. ■ For security reasons, you may want to change the default TCP/IP port number 1433 for a default SQL Server 2008 failover clustering instance, or you may want to assign a static TCP/IP port for your named SQL Server 2008 failover clustering instance. To assign a static TCP/IP port for a SQL Server 2008 failover clustering instance, follow these steps: 1. Launch SQL Server Configuration Manager from Start ➪ Programs ➪ Microsoft SQL Server 2008 ➪ Configuration Tools ➪ SQL Server Configuration Manager. 2. Expand SQL Server Network Configuration in the left pane and select Protocols for < INSTANCE>,where<INSTANCE> is the SQL Server instance name. 3. Double-click TCP/IP on the right pane to open the TCP/IP Properties page. 1162 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1163 Clustering 48 4. Click the IP Addresses tab, scroll to the bottom, and look at the IPALL section. Delete any value that might be there under TCP Dynamic Ports and enter a valid port number for the TCP Port option and click OK. 5. Restart the SQL Server service to enable this change. This will disconnect all client connections, so it must be planned in advance. ■ Sometimes it may be necessary to change the SQL IP address or the SQL network name for your SQL Server 2008 failover cluster. Changing the IP address or the network name can be very easily achieved by opening the Cluster Administrator tool in Windows 2003 Failover Cluster or the Failover Cluster Management tool in Windows 2008 Failover Cluster and changing the properties of the resource you want to change. Changing the SQL IP address or the SQL Network Name resource requires taking the SQL Server resource offline, so it needs to be planned in advance. Also, the change takes a few minutes to propagate through a corporate network. Although changing the SQL network name is allowed, the named instance name cannot be changed. For example, a SQL Server 2008 failover clustering instance named SQL2008VS1\INST1 can be changed to some other name, such as SQL2008VS2\INST1, but the named instance name INST1 cannot be changed. This is one reason to spend time proactively on the SQL Server 2008 failover cluster naming conventions. Troubleshooting a SQL Server 2008 failover cluster Troubleshooting SQL Server 2008 failover clustering is not always the same as diagnosing problems on a stand-alone SQL Server 2008 instance. SQL Server 2008 failover cluster technology is very complex and involves Windows failover clustering, the Windows operating system, the storage subsystem, clus- ter nodes, the network, hardware drivers, and SQL Server 2008 failover clustering. This makes trou- bleshooting a SQL Server 2008 failover cluster difficult and time consuming. Due to the dependence on so many components, troubleshooting a SQL Server 2008 failover cluster issue usually involves collabo- ration with the platforms, networking, storage, and SQL Server teams. If problems exist on the cluster nodes, then those problems may manifest themselves as issues with your SQL Server 2008 failover clustering instance. Unless it is obvious that the issue is related to SQL Server 2008, troubleshoot a SQL Server 2008 failover clustering issue in the following order: ■ Hardware ■ Operating system ■ Network ■ Security ■ Windows failover cluster ■ SQL Server 2008 Often, a lot of information is required to troubleshoot a SQL Server 2008 failover clustering issue. Here are some of the logs that are useful in getting to the root of the issue: ■ Windows application, system, and security event logs on all cluster nodes 1163 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1164 Part VI Enterprise Data Management ■ Cluster logs on all cluster nodes: The text file-based cluster.log (located in the %systemroot%\system32\LogFiles\Cluster folder in Windows Server 2003) is no longer in Windows Server 2008. It has been replaced by a much more sophisticated event-based tracing system. Event trace logging (. etl) is now enabled via Event Tracing for Windows (ETW). The cluster.exe tool enables you to dump the trace log into a text file. This file looks similar to the cluster log used in previous versions of failover cluster- ing. An example command to generate a cluster log on a Windows failover cluster named WIN2K8CLUSTER would be as follows: Cluster.exe /cluster: WIN2K8CLUSTER log /generate /copy "C:\temp" Navigate to the C:\temp directory where you will find the .log files for each node of your cluster. The cluster log can now be opened in Notepad. ■ SQL Server Error logs: Useful for troubleshooting SQL Server errors and SQL Server resource failures ■ SQL Server Agent logs: Useful for troubleshooting SQL Server Agent errors and SQL Server Agent resource failures Troubleshooting SQL Server 2008 setup issues is slightly different. Here are some steps that will assist in troubleshooting the failed installation: 1. Locate the relevant subfolder of the %ProgramFiles%\Microsoft SQL Server \100\Setup Bootstrap\Log folder with the latest timestamp to get to the latest installa- tion log files. 2. First, review the Summary.txt file. 3. Next, review the detail.txt file and look for the keywords ˝ at Microsoft˝ or ˝ threw an exception during execution˝ . 4. Finally, examine the detailed MSI log for the component that failed. a. When the installation fails because the MSI failed, find the ‘‘ Error:’’ string in the Detail.txt log. b. This error should then indicate which MSI and action failed. The action would be in the format install_sql_cpu32_action. c. Look into the corresponding MSI log and search for ˝ Return Value 3˝ to determine why the MSI installation failed. Summary High availability is paramount to the success of most database projects, and is becoming increasingly important in regard to business requirements. 1164 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1165 Clustering 48 This chapter explored the key enhancements in SQL Server 2008 failover clustering, installing SQL Server 2008 failover clustering, rolling upgrade and patching, and maintaining and troubleshooting a SQL Server 2008 failover cluster. SQL Server 2008 failover clustering is one of the high-availability options that Microsoft SQL Server 2008 offers. This is the only option that provides redundancy at the entire SQL Server 2008 instance level. Microsoft SQL Server 2008 offers other high-availability options such as log shipping, database mirroring, and replication. Review these options to determine which high-availability option or options work best for your environment. It is possible that you may need to use more than one option to suit your business requirements. 1165 www.getcoolebook.com Nielsen c48.tex V4 - 07/21/2009 3:21pm Page 1166 www.getcoolebook.com Nielsen p07.tex V4 - 07/21/2009 3:27pm Page 1167 Security IN THIS PART Chapter 49 Authenticating Principals Chapter 50 Authorizing Securables Chapter 51 Data Cryptography Chapter 52 Row-Level Secur ity T he Information Architecture Principle in Chapter 2 states in part: Information is an organizational asset, and, according to its value and scope, mustbeorganized,inventoried,andsecured In the last edition of this book, security was a single chapter in the Enterprise Database Management part. In this edition, I’ve given security its own part to give it the space and significance that it deserves. The basic model of principles and securables has remained constant throughout SQL Server history, but with new features and cryptology, the subject of security is growing more complex. This part also includes my solution for row-based security. If SQL Server is the box, then this part is about padlocking the box to keep out those who should be out, while extending welcome to those who should be allowed in. www.getcoolebook.com Nielsen p07.tex V4 - 07/21/2009 3:27pm Page 1168 www.getcoolebook.com Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1169 Authenticating Principals IN THIS CHAPTER Understanding SQL Server security Making sense of the many SQL logins Server-level security Server, database, and application roles W hen I was a data systems technician in the Navy, I spent almost two years at Combat System Technical School Command (CSTSC) in Mare Island, California. It was good. My class was one of the last groups to be trained on the AN-UYK-7 computer. The CPU was a drawer with about 50 small cards populated with transistors. We learned to troubleshoot the CPU to the logic-gate level. It was very cool. We shared the island with the Crypto-tech school. The sailors in crypto school had it rough; they couldn’t carry anything in or out of their school — no notes, no books, nothing. At least we could meet after hours in study groups. I was glad to be on the computer side of the com- mand. Security has never thrilled me, but the Information Architecture Principle clearly states that information must be secured. It’s common practice to develop the database and then worry about security. While there’s no point in applying security while the database design is in flux, the project benefits when you develop and implement the security plan sooner rather than later. Security, like every other aspect of the database project, must be carefully designed, implemented, and tested. Because security may affect the execution of some procedures, it must be taken into account when the project code is being developed. A simple security plan with a few roles and the IT users as sysadmins may suffice for a small organization. Larger organizations — such as the military, banks, or international organizations — require a more complex security plan that’s designed as carefully as the logical database schema. 1169 www.getcoolebook.com Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1170 Part VII Security If security is tightly implemented with full security audits performed by server-side traces, the SQL Server installation can be certified at C2-level security. Fortunately, SQL Server’s security model is well thought out, and, if fully understood, both logical and flexible. Whereas the tactics of securing a database are creating users and roles and then assigning permissions, the strategy is identifying the rights and responsibilities of data access and then enforcing the plan. The emphasis on security affects the initial installation. SQL Server installs locked down, and you, as the DBA, must enable features before they can be used. Even remote connections are disabled by default. The Surface Area Configuration facet of Policy-Based Management is used to enable features and components, thereby controlling the exposed surface area. It’s designed to be run after installation. Once configured, the DBA should rarely need to use the tool, which is covered in Chapter 4, ‘‘Installing SQL Server 2008.’’ The SQL Server security model is large and complex. In some ways it’s more complex than the Windows security model. Because the security concepts are tightly intertwined, the best way to begin is to walk through an overview of the model. SQL Server security is based on the concept of securables (see Chapter 50, ‘‘Authorizing Securables’’), objects that can be secured, and principals, objects that can be granted access to a securable. Principals are logins, users, and roles. Granting CONTROL SERVER to a login gives it equivalent rights to being a member of the sysadmin fixed server role. Logins can also be assigned to server roles. Users are assigned to roles, both of which may be granted permission to objects, as illustrated in Figure 49-1. Each object has an owner, and ownership also affects the permissions. FIGURE 49-1 An overview of the SQL Server security model shows how users are first authenticated to the server, followed by the databases, and finally the objects within the databases. The circles represent how the user is identified. LoginID Master SQL Server Security Model Windows Groups Windows User SQL Server User (Mixed Mode) UserID Guest Public Role User db Roles Fixed db Roles Server Roles SQL Server Instance Object Permission (Grant Revoke, Deny) User db’s 1170 www.getcoolebook.com Nielsen c49.tex V4 - 07/23/2009 2:00pm Page 1171 Authenticating Principals 49 Server-Level Security A user may be initially identified to SQL Server via one of three methods: ■ Windows user login ■ Membership in a Windows user group ■ SQL Server-specific login (if the server uses mixed-mode security) At the server level, users are known by their login name, which is either a SQL Server login, or a Windows domain and username. Once the user is known to the server and identified, the user has whatever server-level administrative rights have been granted via fixed server roles. If the user belongs to the sysadmin role, he or she has full access to every server function, database, and object in the server. Users also have permissions granted against server securables. A user can be granted access to a database, and his or her network login ID can be mapped to a database-specific user ID in the process. If the user doesn’t have access to a database, he or she can gain access as the guest user with some configuration changes within the database server. Database-Level Security At the database level, a user may be granted certain administrative-level permissions by belonging to fixed database roles, but the user still can’t access the data. He or she must be granted permission to the database objects (e.g., tables, stored procedures, views, functions). User-defined roles are custom roles that serve as groups. The role may be granted permission to a database object, and users may be assigned to a database user-defined role. All users are automatically members of the public standard database role. Certain database fixed roles also affect object access, such as the right to read from or write to the database. Object permissions are assigned by means of grant, revoke,anddeny. A deny permission trumps a grant permission. Revoke removes the permission assigned, regardless of whether it’s deny or grant, which overrides a revoke permission. A user may have multiple permission paths to an object (individually, through a standard database role, and through the public role). If any of these paths are denied, the user is blocked from accessing the object. Otherwise, if any of the paths are granted permission, then the user can access the object. Object permission is very detailed and a specific permission exists for every action that can be performed (select, insert, update, run, and so on) for every object. It’s entirely possible for a user to be recognized by SQL Server and not have access to any database other than master, msdb,andtempdb. It’s also possible for a user to be defined within a database but not recognized by the server. Moving a database and its permissions to another server, but not moving the logins, causes such orphaned users. 1171 www.getcoolebook.com . naming conventions. Troubleshooting a SQL Server 2008 failover cluster Troubleshooting SQL Server 2008 failover clustering is not always the same as diagnosing problems on a stand-alone SQL Server 2008 instance. SQL Server 2008. Notepad. ■ SQL Server Error logs: Useful for troubleshooting SQL Server errors and SQL Server resource failures ■ SQL Server Agent logs: Useful for troubleshooting SQL Server Agent errors and SQL Server Agent. for a SQL Server 2008 failover clustering instance, follow these steps: 1. Launch SQL Server Configuration Manager from Start ➪ Programs ➪ Microsoft SQL Server 2008 ➪ Configuration Tools ➪ SQL Server