Назад | Перейти на главную страницу

Не отображаются все каталоги на связанном сервере MSSQL

На SqlServer 2000 я создал связанный сервер с машиной SqlServer 2005 с параметром «Тип сервера», установленным на «SQL Server» (первый переключатель), и именем связанного сервера, установленным на имя хоста удаленной машины.

Но SqlServer 2000 может видеть только ОДИН из множества каталогов на сервере 2005 года. Я могу просто ВЫБРАТЬ из таблиц в этом каталоге, но не могу получить доступ ни к одному из других каталогов на том же сервере 2005 года.

Какие настройки я мог бы найти, чтобы понять, почему это происходит, или есть ли ограничение на количество каталогов, которые SqlServer 2000 может видеть на связанном сервере?

Вам нужно будет отредактировать параметры безопасности связанного сервера, чтобы указать логин на экземпляре SQL 2005, который имеет разрешения для всех каталогов, к которым вы хотите получить доступ через связанный сервер. У меня больше нет сервера SQL 2000, чтобы дать вам точные инструкции, но вот статья MSDN, описывающая как установить безопасность для связанных серверов SQL 2000.

РЕДАКТИРОВАТЬ:
См. Эту статью в SQL Server Central для настройка аутентификации Kerberos чтобы разрешить связанным серверам использовать учетные данные текущего пользователя, вошедшего в систему, для аутентификации на целевом сервере. Смотрите также ответы на мой вопрос по настройка делегирования доверия для SQL Server.

Вы получаете эту проблему, потому что у вас наполовину настроен Kerberos. У вас проблема с двойным прыжком. Я узнал кое-что о настройке связанных серверов за последние несколько дней. Этот документ наКак реализовать ограниченное делегирование Kerberos с SQL Server 2008'помог мне больше всего.

Вот несколько ключевых моментов, касающихся использования интегрированной безопасности со связанными серверами (т. Е. «Сделано с использованием текущего контекста безопасности входа в систему»)

  • У вашей учетной записи Windows должен быть доступ как к ServerA, так и к ServerB.
  • Серверы должны использовать TCP / IP или именованные каналы.
  • И ServerA, и ServerB должны иметь собственное зарегистрированное SPN.
    • В противном случае вы можете увидеть, что логин не удался для пользователя АНОНИМНАЯ ошибка.
    • При использовании коротких имен он ДОЛЖЕН разрешаться в полное доменное имя с именем домена активного каталога. Если вы вводите короткое имя, и оно преобразуется в любое другое доменное имя, кроме вашего доменного имени AD, кажется, что оно не работает. В качестве альтернативы используйте CNAME во вторичном домене, который указывает на ваше доменное имя AD.
    • Чтобы проверить SPN: setspn -l ДОМЕН \ SQL_Engine_Svc_Account
    • Чтобы установить SPN: Я не на 100%, все эти записи необходимы, но это то, что я добавил, чтобы охватить все различные способы, которыми клиент может подключиться к экземпляру. Предупреждение! Эти SPN чувствительны к регистру!. Вы должны сбросить экземпляр после установки имен участников-служб. Вы можете позволить движку автоматически регистрировать их, но в моем случае, используя псевдонимы DNS, он никогда не будет регистрироваться должным образом.
      • Базовый синтаксис: setspn -A MSSQLSvc / SQLHOSTNAME [FQDN] [: Порт] [: ЭКЗЕМПЛЯР]
      • Экземпляр по умолчанию:
        • setspn -A MSSQLSvc / HOSTNAME DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ИМЯ ХОСТА: 1433 ДОМЕН \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / HOSTNAME.DOMAIN.ORG DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / HOSTNAME.DOMAIN.ORG: 1433 ДОМЕН \ SQL_Engine_Svc_Account
      • Именованный экземпляр:
        • setspn -A MSSQLSvc / HOSTNAME: INSTANCENAME DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / HOSTNAME.AD.ORG: INSTANCENAME DOMAIN \ SQL_Engine_Svc_Account
      • Именованный экземпляр с псевдонимом DNS: (Мы используем псевдонимы DNS, которые отличаются от фактического имени хоста.)
        • setspn -A MSSQLSvc / ДОМЕН АЛИАСА \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / НИКНЕЙМЫ: 1433 ДОМЕН \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS: INSTANCENAME DOMAIN \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS.DOMAIN.ORG: 1433 ДОМЕН \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS.DOMAIN.ORG: 1433 ДОМЕН \ SQL_Engine_Svc_Account
        • setspn -A MSSQLSvc / ALIAS.DOMAIN.ORG: INSTANCENAME DOMAIN \ SQL_Engine_Svc_Account
  • В учетной записи механизма sql не должно быть параметра «Учетная запись является конфиденциальной и не может быть делегирована».
  • Вы должны настроить делегирование при настройке соединения с двухскачковым сервером:
    • В Active Directory пользователи и компьютеры находят служебную учетную запись для службы ядра SQLServerA (если вы используете учетную запись - в противном случае найдите учетную запись компьютера.) На вкладке «Делегирование» выберите «Доверять этому пользователю для делегирования только указанным службам» и «Использовать Kerberos». только "Нажмите кнопку" Добавить ". Найдите служебную учетную запись для службы ядра SQLServerB. Выберите ранее настроенные имена SPN, которые относятся к связанному серверу, который вы пытаетесь создать.

Я только что это сделал!

Идентификатор удаленного входа в систему, который используется для связывания всех серверов друг с другом, должен иметь доступ для чтения / записи к базе данных.

Как только вы предоставите доступ для чтения и записи к базе данных, база данных отобразится в списке каталогов на связанном сервере.

Вы переходите к каждой базе данных> Безопасность> пользователи и находите Удаленный вход. Если его там нет, перейдите на уровень сервера> Безопасность> Пользователи> Сопоставление пользователей и проверьте базу данных, которую нужно связать. Теперь убедитесь, что удаленный вход в систему имеет разрешения на чтение / запись, перейдя в базу данных> Безопасность> Пользователи> Собственная схема, проверьте db_datareader и / или db_datawriter.

Удачи!

Джавид