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

Question

У меня есть именованный экземпляр 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 (только не удаленно).

• РЕДАКТИРОВАТЬ: Если я добавлю локальную группу домена Domain2 на локальный серверГруппировать и создать имя входа SQL Server для этой локальной группы серверов, пользователь Domain1 по-прежнему не может подключиться к экземпляру удаленно.

• РЕДАКТИРОВАТЬ: Если я изменю сетевой протокол подключения на «Именованные каналы», пользователь Domain1 может успешно подключиться удаленно.

---

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

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

БОЛЬШЕ ЗАМЕЧАНИЙ

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

ОБНОВЛЕНИЕ

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

Answer 1

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

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

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

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

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

1. Установленные доверительные отношения между доменами
   1. Как минимум, необходимо установить 1-сторонние отношения доверия, чтобы Domain2 отношения доверия Domain1 и Domain3
2. Группы в Domain2 должны иметь область видимости «Домен локальный»
   1. Это позволяет добавлять пользователей и группы из Domain1 и Domain3
   2. См. здесь для получения дополнительной информации
3. Используйте диспетчер конфигурации SQL Server, чтобы назначить неадминистративного пользователя Domain2 в качестве удостоверения учетной записи службы
   1. MSDN документы, почему используется доменучетная запись пользователя может быть предпочтительнее
   2. Несмотря на то, что диспетчер конфигурации должен добавлять пользователей в определенные локальные группы SQL Server 2005 для вас (т. е. SQLServer2005MSSQLUser $ MY_MACHINE $ MY_INSTANCE), я столкнулся с несколькими случаями, когда этого не былодело.Так что просто проверьте свои локальные группы, чтобы убедиться, что они были обновлены соответствующим образом с вашей учетной записью Domain2.
   3. Хотя настройка SQL Server должна автоматически назначать соответствующие разрешения для их локальных групп, опять же, я столкнулся с несколькимислучаи, когда это было не так.Если это произойдет с вами, вы можете сослаться на эту статью MSDN вместе с ранее упомянутой статьей для требований о разрешениях.
4. Настройте имя участника-службы (SPN) дляХост экземпляра SQL Server (включая псевдонимы) и учетная запись службы Domain2
   1. Имя участника-службы требуется для взаимной аутентификации между клиентом и хостом сервера
   2. См. Это TechNet статья для получения дополнительной информации
5. В зависимости от того, как вы собираетесь использовать олицетворение, вы можете включить учетную запись службы Domain2 в качестве доверенной для делегирования
   1. См. это TechNet статья для получения дополнительной информации
6. Включение удаленных подключений для экземпляра службы SQL
7. Наконец, создайте логины для желаемых групп Domain2 и любых Domain1 или Domain3 участники должны иметь возможность удаленного подключения!

Примечание

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

Answer 2

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

Мое окружение,

Лес 1 (Домен 1) --- ДОВЕРИЕ --- Лес 2 (Домен 2)

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

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

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

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

Доверительные отношения -> исходящие доверительные отношения -> свойства -> аутентификация -> изменить на «Аутентификация на уровне леса»

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