mastering sql server 2000 security PHẦN 6 potx

More informationabout the configuration of the SQL Server Agent account is available inChapter 3, “Exploring Initial Security Parameters.” You configure the properties of the SQL Server

SQL Server Agent runs on any server that is running instances of MicrosoftSQL Server 2000 or earlier versions of SQL Server SQL Server Agent is theservice that allows you to automate administrative tasks As such, youmust start the SQL Server Agent service before your local or multiserveradministrative tasks can run automatically SQL Server Agent is also sup-ported on the Microsoft Windows 98 operating system, but SQL ServerAgent cannot be used with Windows Authentication when run on Win-dows 98 Windows Authentication can only be used after a login to theWindows 2000 domain Existing Windows 2000 users and groups aregranted access to SQL Server SQL Server Authentication requires thatlogins be created in SQL Server, and you must supply the password withthe account More information on Windows and SQL Server Authenticationcan be found in Chapter 4, “Establishing Login Security.”

SQL Server Agent is responsible for:

■■ Running SQL Server tasks scheduled to occur at specific times or

intervals (jobs).

Introducing the SQL Server

Agent Service

9

■■ Detecting specific conditions for which administrators have defined

an action, such as alerting someone through pages or email, or a task

that will address the conditions (operators and alerts).

■■ Running replication tasks defined by administrators (replication).

SQL Server Agent is similar to an auxiliary operator responsible for dling the repetitive tasks and exception-handling conditions definedthrough the other SQL Server automation components

han-This chapter first provides a review of the configuration of the SQL ServerAgent service account Then it moves to an overview of jobs, operators, andalerts This chapter also addresses specific security concerns related to jobs.The chapter then describes the email integration features of SQL Server.Finally, the chapter addresses replication and its security concerns

SQL Server Agent Service Account

The SQL Server Agent is started in and runs as a Windows service Thisservice appears in the list of installed services in the Services dialogue box.The Services dialogue box is available from the Control Panel

The two most important services to Microsoft SQL Server are the SQL

Server service and the SQL Server Agent service The SQL Server service handles all query processing and server configuration The SQL Server Agent service manages all the automated processes, which can include jobs,

operators, alerts, and replication

For Microsoft SQL Server and SQL Server Agent to run as services inWindows, they must be assigned a Windows user account to use whenthey start up This account is necessary for the service to log on to the sys-tem Typically, both SQL Server and SQL Server Agent are assigned thesame user account However, it is possible to customize the settings foreach service

You have two choices for the configuration of the service account: theLocal System Account and a Domain User Account For email, replication,and multiserver jobs to function correctly, the SQL Server Agent servicemust be configured to start with a domain account The account should be

a local administrator on the SQL Server machine, and all instances of SQLServer should be configured to use the same account More informationabout the configuration of the SQL Server Agent account is available inChapter 3, “Exploring Initial Security Parameters.”

You configure the properties of the SQL Server Agent service using SQLServer Enterprise Manager To configure the general properties of the SQLServer Agent service, you should perform the following steps:

1 Open Enterprise Manager.

2 Click to expand your instance of SQL Server

3 Click to expand the Management container

4 Right-click the SQL Server Agent and select Properties, as shown in

Figure 9.1

5 Configure the General, Advanced, and Connection tabs as you deemnecessary The Job System tab is described in more detail later in the

section Job Security The options for configuration are detailed next.

In the General tab, you can configure the location of the error log file,enable the recording of execution trace messages (for troubleshooting), andenable the error file to be written as a non-Unicode file (resulting in asmaller log file size) Recording of execution trace messages can generatelarge files You can also configure a recipient on the network to receive a NetSend pop-up message notification of errors recorded by the SQL ServerAgent service Configuring a mail session for the SQL Server Agent service

is covered later in this chapter in the section Setting Up SQLAgentMail.

To configure advanced properties of the SQL Server Agent service, clickthe Advanced tab in the SQL Server Agent Properties dialogue box asshown in Figure 9.2

Figure 9.1 The SQL Server Agent Properties dialogue box allows for the customization of the SQL Server Agent service.

Figure 9.2 The Advanced tab of the SQL Server Agent Properties dialogue box provides additional control over the SQL Agent Service.

In the Advanced tab, you can configure the SQL Server Agent service torestart automatically if it stops unexpectedly by selecting the Auto RestartSQL Server Agent if It Stops Unexpectedly checkbox This feature requireslocal administrator rights by the SQL Server Agent service account (either bygranting them to the domain user account or using the local system account)

By default, the SQL Server service is configured to restart automatically

In the SQL Server Event Forwarding group box, you can configure theSQL Server Agent service to forward some or all SQL Server events toanother server You can use this feature to enable centralized alert manage-ment for a group of servers Plan carefully, because this generates addi-tional network traffic and load on the centralized server, and creates asingle point of failure

N OT E When configuring SQL Server Event Forwarding, the server you set for messages to be forwarded to must be a registered server in Enterprise

Manager.

In the Idle CPU Condition group box, you can also define when theprocessor is considered idle You define the idle condition by specifying apercentage below which the average processor usage must fall for adefined length of time This feature requires local administrator rightsgranted to the SQL Server Agent service account (either by granting them

Figure 9.3 Jobs can be scheduled for a specific time or based on an event such as the SQL Server Agent service starting or the CPU becoming idle.

to the domain user account or using the local system account) Idle tions are used to schedule jobs One of the options for a job schedule is executing the job when the CPU becomes idle, as shown in Figure 9.3

condi-You configure the Connection properties of the SQL Server Agent service

by clicking the Connection tab in the SQL Server Agent Properties dialoguebox as shown in Figure 9.4

Figure 9.4 The Connection dialogue box is used to bypass the default connection options for the SQL Server Agent By default the SQL Server Agent connects to another server using the SQL Server service account.

By default, the SQL Server Agent service connects to the local SQL Server

2000 instance using the domain user account specified as the serviceaccount However, in the SQL Server Connection group box, you can specifythat all connections to the local instance use a SQL Server login accountthat is a member of the sysadmin server role You can also modify the logintimeout value from the default of 30 seconds Finally, if you have config-ured nondefault client Net-Libraries, you might need to specify a SQLServer alias that you previously created using the Client Network Utility.More details on aliasing and the Client Network Utility are addressed inChapter 7, “Implementing Front-End Application Security.”

Jobs, Operators, and Alerts

SQL Server Agent is a Windows service that executes jobs, notifies tors of actions on the server, and fires alerts Jobs, alerts, and operators(which are discussed separately in the sections that follow) run in the secu-rity context of the SQL Server Agent service Additionally, the full integra-tion of these features depends on email integration with Exchange Server

opera-or another compatible email system

on all SQL Servers being configured to start with the same domain useraccount

Anyone can create a job, but only its owner or members of the sysadminrole can edit a job More information about job security and configuration

is described later in this chapter in the section Job Security.

Jobs can easily be created in Enterprise Manager As you decide on thejob you would like to configure, you should consider the following:

■■ Jobs are made up of steps Each job can be configured to have one ormore steps Job steps can be Transact-SQL statements, ActiveX Scripttasks, replication-related events, and operating system commands.

■■ Each job has an owner The ownership of the job determines to someextent the security context the job steps will run in Ownership of

jobs is addressed in more detail later in this section

■■ Jobs can be scheduled After you create a job, it can be configured to

run immediately or scheduled for a specific time or event

■■ Jobs can notify operators of the resulting status of the action The

operator notification can be through email, pager notification, or

Net Send

To create a job for your instance of SQL Server you should perform thefollowing steps:

1 Open Enterprise Manager

2 Click to expand your instance of SQL Server

3 Click to expand the Management container

4 Click to expand SQL Server Agent

5 Right-click Jobs and select New Job

6 The New Job Properties dialogue box will appear as shown in

Defining Alerts

Alerts are useful in creating a proactive approach to database tion In far too many cases administrators spend time running aroundputting out the fires that result as applications that rely on SQL Server fail.Alerts allow the administrator some control over these errors and allow for

administra-a configured administra-action badministra-ased on the error received Alerts cadministra-an either be badministra-ased

on errors that have already occurred or they can be created on a based performance condition (threshold) Errors and messages, or events,are generated by Microsoft SQL Server and entered into the Microsoft Win-dows application log SQL Server Agent constantly reads the applicationlog and compares events to alerts that you have defined If no alert isdefined, then no action is taken The alert can be configured to notify anoperator or execute a job When an error occurs or a threshold is met, youcan fire an alert, which in turn executes a job to take an action to respond tothe event For instance, you may want to define an alert that monitors thepercentage of log space used on your production database When a thresh-old is met, such as 75 percent full, the alert is fired You could then have thealert execute a job that backs up the log (The backup log statement trun-cates the inactive portion of the log.) This job immediately responds to thealert, thereby avoiding a bigger problem later on

system-Alerts are also easily configured through Enterprise Manager To create

an alert you should perform the following series of steps:

1 Open Enterprise Manager

2 Click to expand your instance of SQL Server

3 Click to expand the Management container

4 Click to expand SQL Server Agent

5 Right-click Alerts and select New Alert

6 The New Alert Properties dialogue box will appear as shown in Figure 9.6

7 Configure the General tab to include the name, type of alert (event

or performance condition), and historical information

8 Use the Response tab to configure Operator notification and the execution of jobs as a response to the alert

Operators

Operators are objects for notification of job status and alert firing Theoperator is a representation or a user or group An operator can be used forthree types of notification:

Figure 9.6 New alerts are created from this dialogue box page to act on SQL Server errors

or performance conditions.

■■ Email notification depends on the integration of email services SQL

Agent Mail must be configured to use this option The details of the

email configuration are addressed later in this chapter in the section

Setting Up SQLAgentMail.

■■ Pager notification depends on pager integration software SQL Server

and Microsoft Exchange Server do not include pager software If

your organization has a pager software solution, this option can be

used

■■ Net Send notifications are pop-up messages that are configured to pop

up on the computer screen They are beneficial because they interruptwhatever the user is doing They cannot be relied on as the only

notification, because if the machine isn’t on or the user isn’t logged

on, the message cannot be received

Operators should be configured using Enterprise Manager To configure

an operator, follow these steps:

1 Open Enterprise Manager

2 Click to expand your instance of SQL Server

3 Click to expand the Management container

Figure 9.7 Use the New Operator Properties dialogue box to add a new operator to notify

of specified alerts or job status.

4 Click to expand SQL Server Agent

5 Right-click Operators and select New Operator

6 The New Operator Properties dialogue box will appear as shown inFigure 9.7

7 Operators must be given a name and email, pager, and Net Sendinformation

N OT E The primary attributes of an operator are name and contact

information It is recommended that you define operators before you define alerts If operators are set up first, they are visually available in Enterprise

Manager when you create the alerts, so notification configuration of alerts

is easy.

Job Security

Using SQL Server Agent, you can create and schedule jobs that automateroutine administrative tasks In this section, you learn to create simple and

complex jobs You learn to configure permissions for jobs owned by userswho are not members of the sysadmin server role You learn to executethese jobs manually or according to a schedule You also learn to use oper-ators for notification of the success, failure, or completion of a job Finally,you learn to review job properties and job execution history.

Implementing Jobs

Database administrators create jobs to perform predictable administrativefunctions (such as backing up databases or importing data) either accord-ing to a schedule or in response to events and conditions Jobs can be sim-ple operations containing only a single job step or they can be extremelycomplex operations containing many job steps with control of flow logic.SQL Server Agent is responsible for the management and execution of alljobs SQL Server Agent must be running for jobs to execute Jobs can be cre-ated on the local server or on one or more target servers in a multiserveradministration configuration

Types of Job Steps

SQL Server 2000 supports jobs containing operating system commands,CmdExec commands, Transact-SQL statements, Microsoft ActiveX scripts,and replication tasks A single job can contain all of these types of com-mands, although each job step can contain only a single type of command

It is common for a single job to consist of multiple steps

N OT E Have a design for the steps that need to be included with the job.

Evaluate your needs before you add the job The logic and troubleshooting will

be easier if you are clear on what you need to accomplish.

■■ Operating system commands (such as bat, cmd, com, or exe) mustcontain the absolute path to the executables, the executable com-

mand (including switches and options), and a process exit code All

operating system commands issue an exit code upon completion of

execution indicating the success or failure of the command An exit

code of 0 (zero) indicates that the command completed successfully

Any other exit code indicates a type of command failure Responses

to different types of failures can be programmed into the job logic

Chapter 11, “Managing Data Transformation Services,” provides an

example of using the DTSRUN command to execute a DTS package.DTSRUN is an example of an operating system command More

information on operating system commands and exit codes can befound in SQL Server Books Online.

■■ Transact-SQL statements must identify the database in which thestatement will execute and provide the statement, function, storedprocedure, or extended stored procedure to be executed A single jobstep can contain multiple batches of Transact-SQL statements withembedded GO commands Members of the sysadmin role can writejob steps to run on behalf of another database user

■■ ActiveX scripts must identify the scripting language used by the jobstep and provide the ActiveX script commands An ActiveX scriptcan also be compiled and run as a CmdExec executable CommonActiveX Scripting languages include VBScript and Jscript

Permissions and Ownership of Jobs

By default, jobs are owned by the creator of the job and operate in the rity context of that login, regardless of who executes the job A member ofthe sysadmin role can modify ownership when necessary A system admin-istrator can assign a job to any owner regardless of the owner’s securitycontext

secu-Ownership of a job, by itself, does not grant the right to execute any ticular job step Permission to execute each Transact-SQL job step is veri-fied by the SQL Server service using permissions granted within SQLServer By default, permission to execute CmdExec and ActiveX job steps isgranted only to jobs owned by members of the sysadmin server role If this

par-is not changed, only members of the sysadmin role will be able to own jobsthat include ActiveX or CmdExec job steps When owned by a member ofthe sysadmin role, these job steps run in the security context of the SQLServer Agent service account

Permission to run CmdExec and ActiveX scripting job steps can begranted to users who are not members of the sysadmin fixed server role.These job steps owned by a nonsysadmin role run in the security context of

a specified Windows account called the proxy account and inherit the rights

granted to that account

Configuring the Proxy Account

If you plan to create jobs containing CmdExec and ActiveX job steps thatwill be owned by (or executed in the context of) users who are not mem-bers of the sysadmin server role, you must configure the proxy account

Figure 9.8 You can configure the proxy account to allow nonsysadmin job owners to configure operating system and ActiveX Script job steps.

1 Open Enterprise Manager

2 Click to expand your instance of SQL Server

3 Click to expand the Management container

4 Right-click the SQL Server Agent and select Properties

5 Select the Job System tab as shown in Figure 9.8

6 Click the Only Users with SysAdmin Privileges Can Execute

CmdExec and ActiveScripting Job Steps checkbox

N OT E The account information provided for the proxy account must be an

existing local or domain user account You should then assign this account the

permissions you want nonsysadmins to inherit when their jobs are run If the

service account used by the SQL Server service does not have administrator

privileges, you will be prompted for the user credentials of an administrator.

Multiple Job Steps and Job Responses

Each job can have a workflow configured for the execution of job steps Ajob step either succeeds or fails You can determine the order in which your

job steps run based on the status of another step For instance, on the cess of a job step, you can configure the job step to continue to the next step

suc-or a specific job step You can also configure the job step to quit and repsuc-ortsuccess or failure For example, you could have a job step that was respon-sible for executing a DTS package that will transfer data from one server toanother If this process succeeds, you may want to execute another stepthat backs up the database If the job step fails, you may want to dump thedata to a text file so it is at least accounted for You would define the backupstep and the dump-to-text file as different steps You would then need toconfigure the workflow so that if the DTS package executed successfully,the backup step runs If the DTS package fails, then the workflow wouldexecute the task to dump the data to a text file In this case workflow isimportant because you don’t want both the backup and the dump-to-textfile steps to run

You can configure operators to be notified of the success, failure, or pletion of the job Without operators who are designated to receive notifi-cation, the reports of success and failure of the job do not get transmitted tousers Operators are configured through Enterprise Manager, similar tojobs Operators can be notified via an email, a pager notification, or a NetSend message The email option depends on the SQLAgentMail configura-

com-tion, which is addressed later in this chapter in the section Setting Up SQLAgentMail Otherwise, by default, failure of a job is automatically

logged to the Windows application log, which can be viewed in EventViewer

Reviewing Jobs and Job History

The Details pane of the Jobs container in SQL Server Enterprise Managerdisplays information regarding all jobs for the SQL Server 2000 instance.Information regarding each job is displayed in columns Click a columnheading to sort the jobs based on that column Notice the Enabled column

If you are troubleshooting a job that does not run, verify that it is enabled.Information is displayed regarding the status of a job (such as executing ornot running), the last time a job ran, and the next time it is scheduled Youcan view the job history by right-clicking a job and selecting Job History asshown in Figure 9.9

Job Properties

To view or modify the properties of a job, right-click the job and then clickProperties (or double-click the job) Users who are not members of thesysadmin server role can only view or modify jobs they own

Figure 9.9 Job History is used to troubleshoot jobs that are not executing properly.

Job History Log

To review the execution history of a job, right-click the job and then clickJob History as shown in Figure 9.10 Information is displayed regardingeach time the job was run, its result, who invoked the job, and whetheroperators were notified

Figure 9.10 A job history helps to troubleshoot a failed job.

N OT E While viewing a job history, it is beneficial to show the job step details This displays the details for each of the steps taken In many cases, this is the only place an error message is displayed.

Setting SQL Server Mail Services

SQL Server 2000 can connect with Microsoft Exchange Server and other mailservices to provide two email options: SQL Mail and SQLAgentMail Bothservices require a MAPI client application (such as Microsoft Outlook) on thelocal SQL Server 2000 computer and a MAPI messaging profile A MAPImessaging profile requires the use of a domain user account The SQL Serverservice and SQL Server Agent services should both be configured to use thedomain user account In many cases, SQL Mail and SQLAgentMail use thesame domain user account for administrative convenience

SQL Mail is the mail service of the SQL Server service This is useful inallowing the developer to programmatically use the email functions TheSQL Server service uses the xp_sendmail extended stored procedure tosend email from Transact-SQL batches, scripts, stored procedures, and trig-gers It establishes a mail session only as needed; therefore, the systemoverhead for SQL Mail configuration is minimal

The following example uses the xp_sendmail extended stored procedure

to send an email message to Andy regarding the current SQL Server 2000performance This query could be scheduled to run periodically to notify aDBA of the current performance information

EXEC xp_sendmail ‘Andy@Softouch.trn’ ,

@subject = ‘Performance Information’ ,

@query = ‘SELECT * FROM master.dbo.sysperfinfo’

The content of the email sent can include several types of information.The following is a list of contents that can be used for sending xp_sendmailmessages

■■ A result set from a query

■■ A message string

■■ A Transact-SQL statement or batch for execution

■■ A page for an electronic pager

SQLAgentMail is the mail service of the SQL Server Agent service This

is the more common of the mail services and is essential for many of the

processes described in this chapter Email notification to an Operatordepends on this service The SQL Server Agent service starts a mail sessionwhen the service starts By default SQLAgentMail is not configured andwill not start until you complete the configuration process This service isthen used as the basis for job and alert notification processes.

Configuring a Messaging (Mail) Profile

Both SQL Mail and SQLAgentMail require the installation of a MAPI client(such as Microsoft Outlook) on the local SQL Server 2000 computer Afterinitial testing and installation, this client should not be used because ofpossible conflict The mail services of SQL Server use the mapi32.dll foremail functions This is the same dll used by Outlook Using them both onthe same machine increases the chances of corrupting the mapi32.dll Thiscould result in either Outlook or your SQL Server services to stop working.Typically, on your production server this is not a problem because a user isnot using the server as a workstation

Next, you must create a messaging profile (also called a mail profile) forthe domain user account used by the SQL Server services and SQL ServerAgent services First this requires an email account configured in ExchangeServer or your messaging system You can create the messaging profile byusing Outlook or the Mail program located in the Control Panel If the ser-vices use a different account during startup, then two profiles must be gen-erated In general, you must log on to Windows 2000 as the domain user toconfigure the messaging profile for that domain user A messaging profileincludes information about the email account such as email server, per-sonal address books, and email storage information

When you create a profile using either the MAPI client or the Mail gram in Control Panel, the default messaging profile name in the ProfileName text box for a domain user is MS Exchange Settings You can use thexp_get_mapi _default_profile extended stored procedure to determine thedefault profile name (if any) for the SQL Server service domain useraccount The mail program can be used to edit any of the profile properties

pro-Setting up SQL Mail

After configuring and testing the messaging profile for the SQL Server vice domain user account, you are ready to set up SQL Mail You configureSQL Mail by following these steps:

ser-1 Open Enterprise Manager

2 Click to expand your instance of SQL Server

3 Click to expand the Support Services container.

4 Right-click SQL Mail and select Properties The SQL Mail tion dialogue box will appear

Configura-5 Select the appropriate profile and click the OK button

If the messaging profile does not appear in SQL Server Enterprise ager, verify that the SQL Server service is using the domain user accountfor which the messaging profile was created Also verify that the domainuser account has full control permissions on the HKEY_LOCAL_MACHINE\SOFTWARE \Clients\Mail Registry key

Man-Setting Up SQLAgentMail

After configuring and testing the messaging profile for the SQL ServerAgent service domain user account, you are ready to set up SQLAgentMailthrough the following procedure:

1 Open Enterprise Manager

2 Click to expand your instance of SQL Server

3 Click to expand the Management container

4 Right-click SQL Server Agent and select Properties The General tab

of the SQL Server Agent Properties dialogue box will appear

5 Click the drop-down box to select the appropriate mail profile asshown in Figure 9.11 After the profile has been selected, you cantest the profile

Figure 9.11 The SQLAgentMail requires a valid MAPI profile.

This section of the chapter introduces the security concerns related to cation The first part of the section introduces replication to build a foun-dation that is necessary to explain the security references First you will beintroduced to the replication components; then the security considerationsfor replication will be addressed More information about the steps neces-sary for configuring replication can be found in SQL Server Books Online

repli-Replication Components

The components discussed in the following sections are the core of SQLServer replication Although the three components are separate logically, asingle server can have multiple components configured It is common forthe machine that plays the role of the publisher to also be configured as thedistributor In a multimaster replication model (all machines can updateand receive changes), it is common for a single server to be configured as apublisher, distributor, and subscriber

Publisher

The Publisher is a server that makes data available for replication to other

servers In addition to being the server where you specify which data is to

be replicated, the Publisher also detects which data has changed and tains information about all publications at that site Usually, any data ele-ment that is replicated has a single Publisher, even if it may be updated byseveral Subscribers or republished by a Subscriber The data is made avail-able to the Subscriber by configuring a Publication The Publication is thetable or subsets of a table that are available for replication

main-Distributor

The Distributor is a server that contains the distribution database and stores

metadata, history data, and transactions The Distributor can be a separateserver from the Publisher (remote Distributor), or it can be the same server

as the Publisher (local Distributor) The role of the Distributor variesdepending on which type of replication you implement, and in general itsrole is much greater for snapshot replication and transactional replicationthan it is for merge replication

Subscribers are servers that receive replicated data Subscribers subscribe to

publications, not to individual articles within a publication, and they scribe only to the publications that they need, not necessarily all of the pub-lications available on a Publisher Subscribers access data from thePublication by creating a Subscription The Subscription can be either a push

sub-or pull subscription The push subscription is configured from the Publishermachine and the overhead for the distribution of data is performed at thePublisher It the Subscription is a pull subscription, the overhead and con-figuration are performed from the Subscriber machine

Types of Replication

SQL Server supports three types of replication: snapshot, transactional,and merge Each type of replication is explained below in more detail

Snapshot Replication

Snapshot replication is a full replication and therefore is typically just used as

a starting point for transactional and merge replication Snapshot replication

is implemented by the Snapshot Agent and the Distribution Agent TheSnapshot Agent prepares snapshot files containing schema and data ofpublished tables and database objects, stores the files in the snapshotfolder, and records synchronization jobs in the distribution database on theDistributor By default, the snapshot folder is located on the Distributor,but you can specify an alternative location instead of or in addition to thedefault (For more information, see the section later in this chapter labeled

Alternative Snapshot Locations.)

The Distribution Agent moves the snapshot held in the distributiondatabase tables to the destination tables at the Subscribers The distributiondatabase is used only by replication and does not contain any user tables

Transactional Replication

Transactional replication is incremental in nature and has been around since

the early versions of SQL Server It is the most common form of replication.Transactional replication is implemented by the Snapshot Agent, LogReader Agent, and Distribution Agent The Snapshot Agent prepares snap-shot files containing schema and data of published tables and database

objects, stores the files in the snapshot folder, and records synchronizationjobs in the distribution database on the Distributor.

The Log Reader Agent monitors the transaction log of each databaseconfigured for transactional replication and copies the transactionsmarked for replication from the transaction log into the distribution data-base The Distribution Agent moves the initial snapshot jobs and the trans-actions held in the distribution database tables to Subscribers

Merge Replication

Merge replication is new to SQL Server 2000 Merge replication is

imple-mented by the Snapshot Agent and Merge Agent The Snapshot Agent pares snapshot files containing schema and data of published tables, storesthe files in the snapshot folder, and inserts synchronization jobs in the pub-lication database The Snapshot Agent also creates replication-specificstored procedures, triggers, and system tables

pre-The Merge Agent applies the initial snapshot jobs held in the publicationdatabase tables to the Subscriber It also merges incremental data changesthat occurred at the Publisher or Subscribers after the initial snapshot wascreated, and reconciles conflicts according to rules you configure or a cus-tom resolver you create

The role of the Distributor is limited in merge replication, so ing the Distributor locally (on the same server as the Publisher) is common.The Distribution Agent is not used at all during merge replication, and thedistribution database on the Distributor stores history and miscellaneousinformation about merge replication

implement-Security Considerations

When considering security in Microsoft SQL Server 2000, replication issimilar to other applications in SQL Server 2000 Your determining factorswill be a balance between how secure the data needs to be and how acces-sible the data needs to be for your environment In many cases the needsfor security have to be compared with the overhead of the additional con-figuration Replication is a prime example of this

Replication security is one of the biggest concerns with the replicationprocess In many cases, troubleshooting replication depends on yourunderstanding of the replication security issues detailed in Table 9.1 Sev-eral of the security issues described in the table are more fully explained inthe sections that follow

Table 9.1 Replication Security Issues

Role Requirements By mapping user logins to specific SQL Server 2000

roles, SQL Server 2000 allows users to perform only those replication and database activities authorized for that role Replication grants certain permission to the sysadmin fixed server role, the db_owner fixed database role, the current login, and the public role Connection to Distributor SQL Server 2000 provides a secure administrative

link between the Distributor and Publisher.

Publishers can be treated as trusted or nontrusted clients.

Publication Access Lists Publication access lists (PALs) allow you to

determine which logins have access to publications SQL Server 2000 creates the PAL with default logins, but you can add or delete logins from the lists.

Agent Login Security SQL Server 2000 requires each user to supply a valid

login account to connect to the server Replication Agents are required to use valid logins when connecting to Publishers, Distributors, and Subscribers However, agents can also use different logins and security modes when connecting to different servers simultaneously.

Password Encryption Passwords used in SQL Server 2000 replication are

encrypted automatically for greater security.

Security and Replication Filtering replicated data can be used to increase

Options data security, and there are additional security

considerations when using dynamic snapshots, immediate updating, and queued updating.

Security and Replication over Different types of replication over the Internet have the Internet different security levels Additionally, when

transferring replication files using FTP sites, precautions must be taken to secure the sites and still make them accessible to Replication Agents.

SQL Server Agent Service Configuration

The SQL Server Agent service (SQLServerAgent) at the client should notuse the Local System account It should be configured to use a standarddomain account The SQLAgent account is the security context underwhich the Snapshot Agent, Merge Agent, and Distribution Agent are

running by default Replication Agents use the SQL Server Agent serviceaccount for their security context If the service account is configured as theLocal System account, many of the agents and replication processes willnot work.

N OT E The Replication Agents are processes that run on behalf of the user to

perform the necessary functions for the replication process Some of the

agents, like the Snapshot Agent, need to be started before the replication

process will function correctly.

Each SQL Server Agent service connects to one or more servers lisher, Distributor, or Subscribers, depending on the agent) and must have

(Pub-a v(Pub-alid login to th(Pub-at inst(Pub-ance of SQL Server to complete the connection Theagent login will determine the success status of replication If the SQLServer Agent service is started with an account that is a local administrator,the Replication Agents will default to that security context and thereshouldn’t be any problem Replication is easiest to configure and managewhen all servers involved in the process use the same domain account forthe SQL Server Agent service

Replication Agent Login Security

Replication implements login security by requiring a user to have a validlogin account and password to connect to a Publisher, Distributor, or Sub-scriber Replication Agents run under SQL Server Agent service and usethe associated logins and passwords to connect to the various replicationobjects and to perform their roles in the synchronization process

Snapshot Replication

The Snapshot Agent connects to the publication database on the Publisherand to the distribution database on the Distributor The Snapshot Agentalso writes to the snapshot folder when storing the snapshot files The SQLServer agent service must have access to both of these locations

Transactional Replication

The agents used in transactional replication must have the following functionality:

■■ The Log Reader Agent connects to the publication database at the

Publisher and to the distribution database at the Distributor

■■ With a push subscription, the Distribution Agent is, by default,

located on the Distributor and connects first to the distribution

database on the Distributor While connected to the Distributor, the