SQL не удалось войти в систему из-за ненадежного домена

Question

• У меня есть виртуальная машина, на которой размещены сервер SQL и сервер IIS.
• На моем сервере IIS есть пул приложений, на котором выполняется веб-приложение. NET.
• Это удостоверение пула приложений: домен \ account1
• В строке подключения моего приложения web.config указано «Trusted_Connection = True», а в источнике данных = NAME \ INSTANCE01
• Мой SQL сервер имеет «SQL Включен режим аутентификации сервера и окна. Домен учетной записи \ account1 добавляется в систему безопасности для входа в базу данных.
• Я могу подключиться к этой виртуальной машине по протоколу RDP, используя domain \ account1, и я могу подключиться к базе данных через SMS, используя Windows Authentication и подключившись к NAME \ INSTANCE01
• Я проверяю, что в нашей AD и D есть только один домен C.

Однако, когда я попытался войти в свое веб-приложение, трассировка ошибки. NET показывает, что это не удается при входе в систему. Посмотрев журнал базы данных, я вижу ошибку ниже. Кажется, что ошибка указывает на пользователя Identity (домен \ account1), который я использую в моем. NET приложении не может войти в базу данных из-за этой ошибки.

введите описание изображения здесь

Это сбивало с толку, потому что я исследовал и обнаружил, что эта ошибка возникает только в том случае, если вы подключаетесь из внешнего домена, но я не знаю, почему она показывает это в моем случае.

Я попытался заглянуть в свой AD, но похоже, что он работает, потому что в противном случае я бы не смог подключить RDP к виртуальной машине, используя домен \ account1.

Любые рекомендации, которые помогут Я сузил причину, приветствую.

Answer 1

Основываясь на нашем разговоре, одна из распространенных причин, которые могут иметь место, заключается в том, что на SQL сервере не зарегистрировано имя участника-службы. Это то, что нужно для работы kerberos.

Для этого вы используете утилиту setspn.

В этом документе много всего, здесь основы. Имя участника службы применяется к некоторой конкретной службе (например, sql сервер), на некотором конкретном компьютере и порту, к некоторой конкретной учетной записи домена. Представим, что имя вашей серверной машины - MyServer, а учетная запись, на которой запущен экземпляр сервера SQL, - MyDomain \ SQLAccount, и это экземпляр по умолчанию (работает на порту 1433. Если это именованный экземпляр, найдите порт с помощью диспетчера конфигурации sql или просмотрев начало журнала sql и подставив его ниже)

Чтобы увидеть список SPN, назначенных учетной записи, вы должны использовать

setspn -l MyDomain\SQLAccount

Чтобы зарегистрировать SPN для служба сервера SQL, лучше всего зарегистрироваться для имени netb ios и полного имени:

setspn -a MSSQLSvc/MyServer:1433 MyDomain\SQLAccount
setspn -a MSSQLSvc/MyServer.mydomain.com:1433 MyDomain\SQLAccount

Теперь, если у вас несколько контроллеров домена, репликация SPN может занять некоторое время вокруг домена. Поэтому вам нужно подождать «достаточно долго», чтобы увидеть, как это подействует. 15 минут - обычное дело, 30 - определенно безопасно. Поэтому после запуска подождите некоторое время, затем создайте новое соединение с SQL сервером (используя, например, SSMS и windows auth) и снова select auth_scheme from sys.dm_exec_connections where session_id = @@spid. Если вы видите "керберос", это сработало. Вы также можете запустить klist purge из командной строки, чтобы очистить ваши билеты, но обычно в этом нет необходимости, и это не поможет, если билет еще не реплицирован.

Это не единственная возможная причина почему у вас могут возникнуть проблемы с SSPI - подробнее см. в блоге MS. Но это действительно распространенная проблема.

РЕДАКТИРОВАТЬ:

Проблемы с Kerberos обычно возникают только тогда, когда у вас есть «двойной прыжок» учетных данных. Например, с компьютера пользователя на веб-сервер, затем с веб-сервера на сервер SQL. Это не относится к вашему конкретному случаю c. Но я бы все равно попробовал эту настройку SPN, потому что это очень частый источник ошибок SSPI.