Междоменные учетные записи SQL Server с использованием проверки подлинности Windows

У меня есть экземпляр с именем SQL Server 2005 с использованием проверки подлинности Windows с группами доменов, которые служат в качестве логинов. Доменные структуры следующие:

      Forest1                Forest2
      /      \                  |
Domain1       Domain2        Domain3

Объекты организованы в следующих доменах:

Forest1.Domain1

  • Пользователи
  • Глобальные группы

Forest1.Domain2

  • Экземпляр SQL Server
  • Локальные группы домена (выступающие в качестве логинов)

Forest2.Domain3

  • Пользователи
  • Глобальные группы

Все мои пользователи существуют в Domain1 и Domain3, но поле SQL Server существует в Domain2. Таким образом, мои логины являются группами домена в Domain2. Когда пользователь из Domain1 добавляется в локальную группу домена в Domain2 и пытается подключиться с использованием протокола TCP/IP к экземпляру SQL Server, он получает следующее сообщение об ошибке:

Невозможно подключиться к < экземпляру > . Ошибка входа для пользователя "Domain1\userName". (Microsoft SQL Server, ошибка: 18456)

Другие вещи, которые я пробовал:

  • Если я добавлю пользователя в качестве логина явно, он может подключиться.

  • Если я добавлю глобальную группу Domain1 который пользователь является участником входа в систему явно, он может подключиться.

  • Если я добавлю глобальную группу Domain1 который пользователь является участником член локального домена Domain2 группа, используемая в качестве логина, не может подключения.

  • EDIT:. Если я добавлю локальную группу домена Domain2 в группу пользователей Demote Desktop Users на сервере Domain2, где размещен экземпляр SQL Server, пользователь Domain1 может успешно подключитесь к серверу - я также могу подключиться к экземпляру локально как пользователь Domain1 (просто не удаленно).

  • EDIT:. Если я добавлю локальную группу домена Domain2 в локальную группу серверов и создаю логин SQL Server для этой локальной группы серверов, пользователь Domain1 все еще не сможет подключиться к экземпляру удаленно.

  • EDIT: Если я изменю протокол сети подключения на "Именованные каналы", пользователь Domain1 может успешно подключиться удаленно.

Из того, что я понимаю (ссылаясь на эти статьи TechNet: Область группы и Nesting Groups), доменная группа ДОЛЖНА быть локальной группой домена, чтобы включить пользователей из Domain1 и Domain3.

Как я могу использовать группу домена в качестве входа в SQL Server с использованием проверки подлинности Windows, так что группа домена может содержать пользователей как из Domain1, так и Domain3, и пользователи могут подключаться удаленно через TCP/IP?

БОЛЬШЕ ПРИМЕЧАНИЯ

  • Учетная запись службы для экземпляра с именем SQL Server является учетной записью пользователя в Domain1
  • SPN были добавлены для учетной записи службы (включая имена серверов и псевдонимы)

UPDATE

Изменение учетной записи службы экземпляра службы SQL, находящейся в Domain2, похоже, решило проблему. Я продолжу расследование и опубликую мои результаты!

Ответы

Ответ 1

Как уже упоминалось в моем обновлении вопроса, изменение учетной записи службы в Domain2 разрешило проблему. Так что же происходит?

Проблема - Объяснение

Из того, что я могу сказать (также с помощью представителя Microsoft), поскольку учетная запись службы изначально была пользователем Domain1, она не могла определить, какие локальные группы домена подключаемый пользователь является членом, когда пользователь аутентифицируется через Kerberos. Основная причина, по которой это была проблема Kerberos, заключалась в том, что я успешно подключился к "Именованные каналы", поскольку это использует проверку подлинности NTLM.

Общее решение

Чтобы собрать все вместе, чтобы успешно добавлять пользователей из Domain1 и Domain3 в качестве членов групп в Domain2, чтобы группы могли использоваться как логины SQL Server с аутентификацией Windows, здесь приведен список требований ( или, по крайней мере, настоятельно рекомендуется):

  • Установленные доверительные отношения между доменами
    • Как минимум, нужно настроить односторонние доверительные отношения, чтобы Domain2 доверял Domain1 и Domain3
  • Группы в Domain2 должны иметь область действия "Локальный домен",
    • Таким образом, вы можете добавлять пользователей и группы из Domain1 и Domain3
    • Смотрите здесь для получения дополнительной информации
  • Используйте диспетчер конфигурации SQL Server для назначения неадминистративного Domain2 пользователя в качестве идентификатора учетной записи службы
    • MSDN документы, почему использование учетной записи пользователя домена может быть предпочтительным
    • Несмотря на то, что диспетчер конфигурации должен добавлять пользователей к локальным определенным группам SQL Server 2005 для вас (например, SQLServer2005MSSQLUser $MY_MACHINE $MY_INSTANCE), я столкнулся с несколькими примерами, когда это было не так. Поэтому просто проверьте свои локальные группы, чтобы убедиться, что они были соответствующим образом обновлены с помощью вашей учетной записи пользователя Domain2.
    • Хотя настройка SQL Server должна автоматически назначать соответствующие разрешения для своих локальных групп, я снова столкнулся с несколькими примерами, где это было не так. Если это произойдет с вами, вы можете ссылаться на эту статью MSDN вместе с ранее упомянутой статьей для требований к разрешению.
  • Настроить имя участника-службы (SPN) для экземпляра экземпляра SQL Server (включая любые псевдонимы) и учетную запись службы Domain2
    • SPN требуется для взаимной аутентификации между клиентом и хостом сервера.
    • Смотрите эту статью TechNet для получения дополнительной информации
  • В зависимости от того, как вы собираетесь использовать олицетворение, вам может потребоваться включить учетную запись службы Domain2 для делегирования
    • Смотрите эту статью TechNet для получения дополнительной информации
  • Включить удаленные подключения для экземпляра SQL Service
  • Наконец, создайте логины для желаемых групп Domain2, и любые члены Domain1 или Domain3 должны иметь возможность подключаться удаленно!

Примечание

Как и в случае любой активности удаленной сети, проверьте свои брандмауэры, чтобы убедиться, что ваши порты SQL Server не заблокированы. Хотя порт по умолчанию - 1433, убедитесь, что ваш порт находится в явном виде.

Ответ 2

Хорошо, я тоже встречался с проблемой в 2017 году, трудно найти какое-либо решение, наконец, я понял это только для моего случая.

Моя среда,

Лес 1 (Domain1) --- TRUST --- Лес 2 (Domain2)

У меня есть учетная запись службы в Domain2, пытающаяся войти в SQL-сервер в Domain1 с помощью проверки подлинности Windows.

И появляется сообщение об ошибке.

Ошибка входа. Вход из ненадежного домена и не может использоваться с аутентификацией Windows. (Microsoft SQL Server, ошибка: 18452)

Решение достаточно просто, на домене1, открыть активные домены каталогов и инструмент доверия,

Цели → исходящие доверительные отношения → свойства → проверка подлинности → изменение на "Аутентификация по всему миру"

Моя проблема решена.