Sorry for my mistake. I forgot that snapshot agent resides on distributor and hence it is required db_owner permission. Thanks for refreshing that. It is really great post on replication. We rarely find this type of stuff.

I’m testing with SQL Server 2008 R2 (10.50.2500).

Removing the Merge agent process account from the PAL prevents pull subscriptions from synchronizing for me. I have not tested with push subscriptions yet, but I’m guessing they will exhibit the same behavior, I’ll let you know shortly.

Either we’re missing something, or the Distribution agent isn’t giving us any respect. I’ll play with this some more and let you know what I find.

So I tested 11.0.1750 (SQL Server 2012 RCO), merge replication, pull subscription.

This time I saw PAL enforcement (unlike with transactional replication). The gateway for merge replication when the merge agent isn’t in the PAL is met when calling sp_helpdistpublisher. Calling it under the merge agent account returns “Msg 14080” when the agent account isn’t in the PAL. The message is generic (as expected since it is security related) – but it does say that the failure is at Line 138. Leading up to the error, the procedure checks a few conditions (for example – dbo on the distributor and checking sys.sp_MSrepl_DistDBPALAccess for PAL access).

So then that leads to the question of why this is enforced for merge and not transactional (even though it is documented as though it is fully enforced).

So I recreated the transactional replication pull scenario to see if the remote distributor is calling the same procedures in the same way.

Long story short is – executing sp_helpdistpublisher under the context of the distributor works just fine – even when the distributor account is not in the PAL (unlike in the merge replication scenario) – as the logic in the procedure is looking for db_owner in the distribution database. If I add that merge agent, the procedure runs under that agents context (even though it isn’t in the PAL). However merge replication is enforcing the PAL even further down the workflow. Where – I’m not sure – still working my way in and will likely trace it to find out where.

Either which way – it seems the intended functionality is represented in merge – but not in pull or push subscribers for transactional replication. Fun stuff!

Quick update, I was able to test on a different version – SQL Server 2012 RC0 (11.0.1750).

Both scenarios had the same PAL "bypass" I documented on today’s post for transactional replication.

11.0.1750 (SQL Server 2012 RCO), transactional replication, push subscription
11.0.1750 (SQL Server 2012 RCO), transactional replication, pull subscription

I’ll try merge replication next and share my findings. Hopefully this gap only applies to transactional replication.

The snapshot agent should be added as a member of db_owner for the distribution database, yes. The full list of required permissions can be found on the Replication Agent Security Model topic (http://msdn.microsoft.com/en-us/library/ms151868(v=sql.105).aspx).

While the role and directory permissions seem solid – I still have some open questions on the PAL behavior. I’ll post findings here.

Do we need db_owner role in distribution database for snapshot agent?

I’d like to repeat this specific test on a different version (push-subscriptions and transactional replication). I’ll report back here in the comments and also compare to merge replication.

Can you tell me what version you’re using (SP and any CUs specifically)? I can then compare to your exact edition. I won’t be surprised if you’re right that this was not intended, but then the next question is around which versions are impacted by this gap.

I’ve found the PAL to work as expected with Merge Replication, e.g., preventing the Merge agent process account from synchronizing if it is not a member of the PAL. However, it doesn’t seem to be working correctly with Transactional Replication.

I honestly think you are facing a bug here. If the Distribution agent process account login is not a member of the PAL, the agent should not be able to synchronize.