Использование режима ретрансляции Вас спасет.
Читайте SQL Remote™ Руководство пользователя.

Я вообще-то не пробовал, но может пойти в направлении включения в публикации системных таблиц.
SYSUSERPERM и т.д. отвечающих за пользователей.
Хотя как-то криминально выглядит, да и ненадежно.

Еще раз говорю, не пробовал.

antandЯ вообще-то не пробовал, но может пойти в направлении включения в публикации системных таблиц.
SYSUSERPERM и т.д. отвечающих за пользователей.
Хотя как-то криминально выглядит, да и ненадежно.

Еще раз говорю, не пробовал.
Не... . Сильно извиняюсь. Что-то не то сморозил. Точно так нельзя. Причины я думаю понятны.

А вот то, что режим ретрансляции работает, сверху-вниз, от консолидированной в удаленную, по-моему очень даже правильно, если посмотреть зачем обычно его используют.
Так что лучше делать добавление пользователя в консолидированной базе, в удаленные ретранслируйте.

PaulJB 2 __Yorik__
Не наступите на грабли типа :

В одной удаленной базе вводят юзера под именем Маша и в другой тоже вводят такое же имя. У них ( в удаленных ) все гуд, а вот в консолидированной будеть конфликт при синхронизации. Зарегистрируется только логин, который пришел первым.
Эта беда может случиться так-же, если ввести в консолидированную логин Маша, затем в удаленную ввести логин с таким же именем и запустить репликацию.
Это, если имя пользователя - первичный ключ по таблице(причем своей таблицы пользователей, не системной таблицы пользователей базы) и меры по уникальности ключей в разных точках не приняты.
Но человек вроде этим вариантом не интерисуется, ему как раз нужно синхонизировать через sp_addlogin

Согласен с White Owl.

Если мы здесь говорим об пользователях базы, именно базы, для которых используется sp_addlogin(а не какой-то своей таблицы пользователей).
Я исхожу из принципа, что
Вызов sp_addlogin можно послать только из консолидированной в удаленную базу.
Из удаленной нельзя!
При таком подходе конфликтов не должно быть.
Все правильно, если такой уже будет в удаленной, то должна перезаписать.

White Owl
Я эту задачу решал по другому.
У меня, кроме основных баз (консолидирования с кучей удаленых) в которых хранятся реальные данные, есть еще и вторичная база.
Вторичная база обслуживает внутренний веб-сайт. Когда кто-либо из главного офиса или из филиала желает завести глобального юзера - идет на этот веб сайт и там заводит. Юзер во вторичной базе хранится как обычные данные. После нажатия на веб-сайте кнопки "Активизировать юзера" запускается внешний скрипт отсылающий данные по юзеру в консолидированную. А оттуда уже юзер однонаправленно расползается по филиалам.
В базах естественно есть табличка с правами глобальных юзеров и на ней триггер который при нужде делает "grant connect to...."
Работает очень даже замечательно :)

Только я бы этот сайт сделал прямо на консолидированной.
А то как-то незаконченно получается. Ведь если удалить пользователя в консолидированной(мало ли какие причины), то в вашей базе отдельной базе сайта он не изменится.
Или есть связь в обратном направлении?
Или предполагается, что управление пользователями только через сайт?

White Owl antandИли предполагается, что управление пользователями только через сайт?Глобальными пользователями только через сайт.

Там у меня вообще все списки держаться которые являются общими для всех филиалов разом. Словари, контрагенты, и тд и тп.
Любой филиал может начать работать с новым контрагентом или начать рекламу на новой радиостанции. Клерк из филиала идет на сайт, помещает там запрос на добавление. Центральный офис проверяет данные, исправляет при необходимости потом дает добро и данные уходят в консолидированую базу и потом по филиалам.

Сначала делали просто - новый контрагент регистрировался в филиале и через репликацию попадал во все базы, но несколько раз пришлось вычищать дублирующихся контрагентов. В итоге решили сделать такой веб-сайт, как буфер для новых записей в словари.

Понял. Жестко сделано.
Такие проблема с общими справочниками всегда есть при репликациях.
Вот недавно набрел на идею с мапингом таких записей в базе.
Т.е. в базе создается таблица где 2 поля, код контрагента и код реального контрагента.
С таблицей контрагентов работаем только через View, который работает с реальной таблицей через эту.
Если видим двух контрагентов, то просто добавляем туда запись.
С этого момента ненужный контрагент как бы скрывается.
Преимущества в том что, чистить вообще не надо, ну разве что по большим админовским праздникам.
До конца еще не прорабатывал в своей системе, но попробовать надо.