运行 REPLMERG.EXE 所需的权限
我们在我们的一个程序中使用合并复制，我希望允许我们的用户根据需要强制他们的笔记本电脑与发布者同步（我们正在使用推送订阅）。我使用 REPLMERG.EXE 完成了这项工作（请参阅我之前的问题）。
然而，当用户尝试运行该脚本时，他们收到以下错误消息：
只有 sysadmin 或 db_owner 角色的成员才能执行此操作。
...
执行 sp_MSreplcheck_subscribe
...
如果我将用户的组登录名添加为本地订阅数据库上的 db_owner，则脚本可以正常工作。问题是他们最终还可以完全访问本地数据库中的每个表，这不是我们可以忍受的。
允许合并复制拓扑中的用户按需同步其本地推送订阅，而不给予他们对数据库的全面控制似乎是一个非常简单的用例，但我无法让它工作。
We use merge replication in one of our programs and I would like to allow our users to force synchronization of their laptops with the publisher on an as-needed basis (we are using push subscriptions). I got this working using REPLMERG.EXE (see my previous question).
However, when the users trid to run the script they received the following error message:
Only members of the sysadmin or db_owner roles can perform this operation.
...
exec sp_MSreplcheck_subscribe
...
If I add the users' group login as a db_owner on their local subscription database then the script works correctly. The problem is that they also end up with full access to every table in their local database, which is not something we can live with.
Allowing users in a merge replication topology to synchronize their local push subscriptions on-demand without giving them full-blown control of the db seems like a pretty straightforward use case, but I can't get it working.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
来自复制代理安全模型：
因此，合并复制的记录要求是运行复制代理 (replmerge.exe) 的帐户必须是 db_owner 的成员。如果这不适用于您的情况，那么合并复制不是适合使用的技术，因为它有一个您无法满足的要求。
现在理论上，一个应用程序可以执行另一个应用程序中 REPLMERGE 所做的任何事情，并且您可以利用代码签名的强大功能来运行一组包装程序，这些程序通过代码签名授予 dbo 权限，因此不需要提升的登录名，但这只是理论因为复制过程并不完全易于使用，也没有在重新实现代理所需的级别进行记录......
From Replication Agent Security Model:
Therefore is a documented requirement of Merge replication that the account running the replication agent (replmerge.exe) be member of db_owner. If you this does not work for you situation, then Merge replication is not the right technology to use, since it has a requirement you cannot fill.
Now int theory an application can do whatever REPLMERGE does from another application, and you can leverage the power of code signing to run a set of wrapper procedures that are granted dbo privileges via code signing, thus not needing the elevated login, but that's just theory since the replication procedures are not exactly easy to use nor are they documented at the level one needs to re-implement the agents...
订阅者必须有权复制发布者上发送的数据定义指令。其中一些指令甚至可能导致订阅者重新初始化，这需要删除\重新创建相应数据库的权限。在这种情况下，微软设定的安全要求听起来相当明智。
The suscriber must have the right to replicate data definition instructions sent on the publisher. Some of these instructions might even lead to the reinitialisation of the subscriber, which requires the right to a drop\recreate the corresponding database. In these conditions, security requirements as set by Microsoft sound quite sensible.
正如 Remus 和 Philippe 所指出的，订阅数据库上的 db_owner 是同步合并推送订阅的硬性要求。然而，我们确实希望允许我们的用户同步他们自己的笔记本电脑，而不授予他们对数据库的完整 db_owner 权限。
我们的解决方案是对订阅者启用混合模式身份验证，并添加一个 SQL Server 用户，其唯一目的是使我们的最终用户能够同步他们的笔记本电脑。 SQL Server 用户“syncuser”被授予本地订阅数据库的 db_owner 角色。然后，当我们从程序内调用 replmerg.exe 时，我们指定了以下开关：
As Remus and Philippe have pointed out, db_owner on the subscription db is a hard requirement for synchronizing a merge push subscription. However, we really wanted to allow our users to synchronize their own laptop without giving them full db_owner rights to the database.
Our solution was to enable mixed mode authentication on the subscribers and add a SQL Server user whose sole purpose was to enable our end users to synchronize their laptops. The SQL Server user, 'syncuser', was given the db_owner role on the local subscription database. Then, when we called replmerg.exe from within the program, we specified the following switches: