Microsoft SQL Server 2008 R2 Unleashed- P34 ppt

The SQLCLR Context Connection When you need to connect to SQL Server 2008 from within a managed stored procedure, function, or trigger known as SQLCLR code, which is possible only with

For VB NET, you use this:

Imports System.Data.SqlClient

And for JScript NET, you use this:

import System.Data.SqlClient;

Note that the NET provider supports a variety of connection string styles, including

ODBC, OLE DB, and OLE DB/SNAC, and you can mix and match some of their respective

connection string keywords For example, Database and Initial Catalog mean the same

thing to ADO.NET, and so do Server and Data Source But don’t let this fool you: Under

the covers, only the NET provider is always in use (This is probably why changing the

value passed to the Provider keyword seems to have no noticeable effect.)

Applications built on NET Framework 1.0 and 1.1 can access SQL Server 2008 databases

without issue The only caveat is that those earlier versions of ADO.NET can’t make use of

certain SQL Server 2008 features, such as asynchronous command execution, cache

synchronization, bulk copy, and the new data types (However, implicit conversions such

as from varchar to xml and from UDTs to varbinary allow their use as T-SQL input from

.NET Framework 1.1 applications.) ADO.NET 2.0 applications, however, have access to the

full gamut of new functionality in SQL Server 2008

The following is an example of two connection strings (in different styles) that both turn

on the MARS feature for ADO.NET 2.0 applications:

The following is in ODBC style:

Driver={SQL Native Client 10.0}; Database=AdventureWorks2008;

Server=MyServer/SQL08;

Encrypt=yes; Trusted_Connection=yes; MARS_Connection=yes

The following is in OLE DB style:

Provider=SQLNCLI10; Database=AdventureWorks2008; Server=MyServer/SQL08;

Encrypt=yes; Trusted_Connection=yes; MultipleActiveResultSets=true

Notice the use of the keywords MARS_Connection (MultipleActiveResultSets also works)

and Encrypt (which requests connection encryption from the server)

The SQLCLR Context Connection When you need to connect to SQL Server 2008 from

within a managed stored procedure, function, or trigger (known as SQLCLR code), which is

possible only with NET 2.0 or greater, you use a special type of connection, known as a

context connection This feature prevents you from having to open a new connection

because the code itself is already running within the context of an open connection

The connection string for context connections is extremely easy to use (”context

connec-tion=true”), as the C# example in Listing 10.1 illustrates

LISTING 10.1 Using the Context Connection from a Managed Stored Procedure

using System;

using System.Data;

using System.Data.SqlClient;

using System.Data.SqlTypes;

using Microsoft.SqlServer.Server;

public partial class StoredProcedures

{

[Microsoft.SqlServer.Server.SqlProcedure]

public static void ContextConnectionTest()

{

using (SqlConnection Context =

new SqlConnection(“context connection=true”))

{

using (SqlCommand TestCommand =

new SqlCommand(“SELECT TOP 10 * FROM Person.Person”, Context)) {

using (SqlDataAdapter Adapter = new SqlDataAdapter(TestCommand)) {

using (DataSet MyData = new DataSet()) {

Adapter.Fill(MyData);

} } }

}

}

}

For more information on building SQLCLR client libraries, see Chapter 43, “SQLCLR:

Developing SQL Server Objects in NET”

Using MDAC

MDAC contains the OLE DB provider for SQL Server (SQLOLEDB) and the ODBC driver for

SQL Server MDAC is officially part of the operating system, and, as mentioned earlier,

MDAC and SNAC are distributed and developed on separate tracks: MDAC with the

oper-ating system and SNAC with SQL Server They do interrelate, however, in that

applica-tions that use SNAC can make use of the core services provided by MDAC, including

support for connection pooling, client-side cursors, ADO support, and memory

manage-ment As mentioned earlier, to make use of the latest SQL Server 2008 functionality, you

need to use SNAC

TABLE 10.2 Implicit Type Conversions for SQL Server 2008 Data Types

SQL Server 2008 Data Type Converted to Data Type

TIP

If, at any time, you want to discover which version of MDAC is installed on a machine,

you can simply check the value of the following Registry key (using regedit.exe or

from code):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DataAccess\Version

Note also that the planned MDAC version 10.0 release has been killed and

super-seded by SNAC

If you choose to upgrade from MDAC to SNAC, it’s important to note some key

differ-ences between the two that could affect your applications:

Return values from SQL Server 2008 to MDAC applications are implicitly type

converted, as shown in Table 10.2

Warning and error messages and message handling differ between MDAC and SNAC

SNAC requires that T-SQL parameters begin with the @ character; MDAC does not

SNAC, unlike MDAC, is not compatible with Visual Studio Analyzer or PerfMon

For further details, see the Books Online topic “Updating an Application to SQL Native

Client from MDAC.”

Using ODBC with MDAC You can configure an ODBC connection by using a connection

string or DSN that specifies the Microsoft ODBC driver for SQL Server

For connection strings, you use the keyword-value pair Provider={SQL Server}

To use a DSN, you run the Data Sources (ODBC) applet, as mentioned earlier When

choosing a driver, you select the one simply named SQL Server

Using OLE DB with MDAC You can access SQL Server 2008 databases by using the

Microsoft OLE DB provider for SQL Server (SQLOLEDB) In connection strings or property

values, you use the Provider keyword and the value SQLOLEDB

NOTE

Unlike with SNAC’s OLE DB provider, with SQLOLEDB you can access both SQL Server

data and data from non–SQL Server data sources Also, SNAC is not dependent on any

particular version of MDAC because it expects that a compatible MDAC version will be

present on the operating system, as enforced by its own installation requirements

Using JDBC

Microsoft released a freely downloadable, JDBC 4.0-compliant, Type 4 driver for use with

SQL Server 2008 It can be used from all types of Java programs and servers via the J2EE

connection API

The following is the basic syntax for a JDBC connection string:

jdbc:sqlserver://ServerName\InstanceName:port;property=value[;property=value]

For complete details on using JDBC, check out Microsoft’s JDBC product documentation

at http://msdn.microsoft.com/en-us/library/ee229547(v=SQL.10).aspx You might also find

the newsgroup microsoft.public.sqlserver.jdbcdriver helpful

General Networking Considerations and Troubleshooting

This section provides guidelines for solving some common connectivity issues You can

perform the following steps as a first line of defense when your connections fail:

1 Check whether the server is configured (via SSCM, as detailed earlier in this chapter,

in the section “Server Network Protocols”) to accept remote connections

2 Ensure that the SQL Browser service is started

3 Determine whether clients are specifying the correct port (for using fixed ports with

named instances) in the server alias or connection string

4 Check whether the client’s network protocols are enabled and configured to correctly

handshake with those of the server They should use SSCM on both sides, as

explained earlier in this chapter, in the section “Client Configuration Using SSCM.”

5 Be sure you have permission to connect on the server’s endpoints

6 When using encryption, be sure the server and client certificates match (that is,

check their Common Name (CN) and any other relevant attributes) and are installed

and configured correctly on both sides (See the section “Connection Encryption,”

earlier in this chapter.)

7 Make certain that your firewalls are configured to permit the required network

traffic (See the following section, “Firewall Considerations.”)

8 Check to see whether your users have permission to log in to the server and access

the specified database

9 Make sure that your clients’ choices of providers support the SQL Server 2008

features they are trying to use

10 Make sure the provider, driver, DSN, server alias, or other connection mechanism is

still valid and hasn’t been altered or removed from the system

FIGURE 10.10 Creating port exceptions for SQL Server 2008, using Windows Firewall

11 Network administrators are no longer added to the SQL Server sysadmin role by

default If the user trying to connect is a network administrator, he or she must be

granted explicit permission with SQL Server 2008 See the topic named “Database

Engine Configuration - Account Provisioning” in Books Online for more information

Firewall Considerations

For clients to successfully connect through a firewall, it must be configured to allow the

following:

Bidirectional traffic on UDP Port 1434—This is required only for

communica-tions to and from the SQL Browser service; when SQL Browser is not in use, you can

close this port

Bidirectional traffic on any TCP port used by SQL Server—Be sure to open port

1433 for default instances and also open any fixed ports assigned to your named or

default instances (TCP high port numbers must be opened only when dynamic ports

are used by named instances Using dynamic port numbers for named instances is

not recommended.) You can determine the ports currently in use via SSCM

When using Windows Firewall, you can easily open these ports To do this, you run

Windows Firewall from the Control Panel, and on the main screen that appears, you click

the Exceptions tab Then you click the Add Port button and enter the required names

(either SQL Server or SQL Browser, for example) and port numbers, one at a time, on the

Add a Port screen that appears (see Figure 10.10)

Tools for Testing Connections

It’s always helpful to have a few tools on your belt for testing client connectivity

SSCM is a tool that is usually easily accessible, and you can use its Connect to Server

dialog to select a protocol to test (as described earlier in this chapter, in the section “Client

Data Access Technologies”) You can also use SQLCMD with the -S parameter to connect to a

particular server This is the syntax:

SQLCMD -Sprotocol_prefix:ServerName,PortNumber -E

In this syntax, protocol_prefix takes one of the following values:

np (for named pipes)

tcp (for TCP/IP)

lpc (for shared memory)

via (for VIA)

In the following example, -E indicates the use of a trusted connection:

SQLCMD –Stcp:.\SQL08,1435 -E

When all else fails, you can use telnet to test the openness of a port on the firewall

Here’s an example:

telnet IP_Address Port_Number

Summary

This chapter covers a lot of ground regarding client-side (and even a bit of server-side)

communication with SQL Server 2008 Some of the sections are admittedly dense enough

to bear rereading, and you probably have questions about your specific setup You can

always refer to the sections presented in this chapter to pick up tips on how to best

configure and troubleshoot the varying environments you may encounter And you can

(and should) use the extremely helpful Usenet groups that are devoted to the subject (for

example, microsoft.public.sqlserver.clients or microsoft.public.sqlserver.programming)

Now that your client configuration is complete, you can move on to Chapter 11, “Security

and User Administration,” to learn how to securely administer the Database Engine

ptg

Security and User Administration

What’s New in Security and User Administration An Overview of SQL Server Security

Authentication Methods Managing Principals Managing Securables Managing Permissions Managing SQL Server Logins Managing SQL Server Users Managing Database Roles Managing SQL Server Permissions

The Execution Context

Securing your database environment and providing the

right type of access to your users are critical administrative

tasks This chapter examines the security features in SQL

Server 2008 that relate to user administration and the

objects that users can access

What’s New in Security and User

Administration

Several new security enhancements have been added to SQL

Server 2008 to help make it more secure than any prior

version These enhancements build upon the myriad of

security-related changes made in SQL Server 2005 and

follow the policy of “least privileges” that Microsoft has

been pushing Several of these new changes follow:

BUILTIN\Administrators—This local Windows

group is no longer included in the SQL Server

sysadmin fixed server role In prior versions, the

BUILTIN\Administrators account was part of this role,

which meant that network administrators could

access the SQL Server instance even though they were

not given explicit permission You still have the

option of manually adding this group to the sysadmin

role, but it is not installed this way by default

Surface Area Configuration (SAC)—This GUI tool,

which was introduced in SQL Server 2005, has been

removed in SQL Server 2008 It was used to enable or

disable SQL Server features and options, but it has

been replaced in part by the new Policy-Based

TABLE 11.1 SQL Server 2008 Security Components

Windows: GRANT/REVOKE/DENY Server Scope

Management feature and in part by an enhanced SQL Server Configuration Manager

Right-click on the server instance in Object Explorer and choose Facets You get a

quick look at the number of settings available via facets that are part of Policy-Based

Management If you select Server Configuration from the drop-down, you see

features such as CLR Integration (that is, CLRIntegrationEnabled) that you could

have set in the past with the Surface Area Configuration tool

Local Groups Removed from sysadmin—Several local network groups that were

added to the sysadmin server role in past versions are no longer added to this role

These accounts include SQLServerMSSQLUser$ COMPUTERNAME $ INSTANCENAME and

SQLServerSQLAgentUser$ COMPUTERNAME $ INSTANCENAME Only the SQL Server

Service and SQL Server Agent Service accounts are added to the sysadmin role

An Overview of SQL Server Security

The SQL Server 2008 security model is the best place to start to understand SQL Server

security The model is based on three categories that separate the basic elements of security:

Principals—Principals are the entities that request security to SQL Server resources

They include Windows users, SQL Server users, and database users

Securables—Securables are the SQL Server resources to which permissions can be

granted

Permissions—Permissions link principals with securables.

Table 11.1 shows the security components contained in each tier of the SQL Server 2008

security model The columns are ordered from left to right, based on the way security is

established

TABLE 11.1 SQL Server 2008 Security Components

Binding VIEW DEFINITION Fulltext Catalog TAKE OWNERSHIP Certificate

VIEW CHANGE TRACKING Symmetric Key

Contract Schema Schema Scope Table View Function Procedure Queue Type Synonym Aggregate XML Schema Collection

The implementation of the security model is relatively straightforward: you choose the

principal from Column 1, the desired permission from Column 2, and the securable to

assign the permission from Column 3 For example, a SQL LOGIN (the principal) needs to

CREATE (the permission) databases (the securable) Together, these three elements represent

a complete security assignment