Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | SQL Server merge replication security |
|---|---|
| Date: | Wed, 3 Jan 2007 15:42:04 +0200 |
Hi Everyone
I am involved in a development project where we are hoping to use Microsoft SQL Server replication. The system will consist of clients running a custom application and MSDE 2000. The client MSDE installations will be subscribed to a merge publication on a central server SQL 2000 server. The users will typically work in disconnected mode and be able to initiate synchronization from the custom application when they can connect to the main server. The replication is being configured using Enterprise Manager and every effort is being made to stick with Windows Authentication (although most replication guides/documents on the Internet seems to use SQL authentication).
For the purpose of this explanation, assume there is a table in the database called AppAdmin containing data that certain users must be allowed to change (insert, update and delete via stored procedures created for this purpose). These changes need to be propagated to all users. Regular users must not be allowed to change this table. Anyone is allowed to make changes to the data in other tables and these changes must be propagated to all users.
The difficulty is that the users (please correct me if I am wrong) need to have the sysadmin role on their local database to initiate the synchronization. They can be prevented from making certain changes to their local databases via the application, but there is nothing to prevent them from using another database access tool, making changes and then synchronizing with the central database - and the changes then being propagated to other users.
The AppAdmin table cannot be removed from the publication as then the required users would not be able to update it - and additionally the other users would not receive the changes.
A couple solutions considered so far (that did not seem optimal) are as follows: 1. Create 3 publications instead of 1: A merge publication without the AppAdmin table for regular users. 2. A snapshot publication of only the AppAdmin table for regular users. 3. A merge publication of the whole database for the 'admin' users. Set the allowed users for each of these publications.
2. Use a stored procedure to initiate the synchornization that a non sysadmin user would have permission to execute. (Not sure how to do this or if this is possible).
What is the best way to deal with this situation? Any help, advice or references to useful documentation would be appreciated. Thanks.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Secure Remote access - windows 2003, James D. Stallard |
|---|---|
| Next by Date: | Re: SQL Server merge replication security, Thor (Hammer of God) |
| Previous by Thread: | SecurityFocus Microsoft Newsletter #323, mfossi |
| Next by Thread: | Re: SQL Server merge replication security, Thor (Hammer of God) |
| Indexes: | [Date] [Thread] [Top] [All Lists] |