Почему моя служба Windows устанавливает соединение с базой данных только тогда, когда служба SQL Server работает под учетной записью локальной системы?

При работе под учетной записью локальной системы sql-server регистрирует spn для каждой службы, которую он автоматически управляет до active-directory , и пытается отменить их регистрацию при завершении работы службы. Учетная запись локальной системы имеет возможность обмениваться данными по сети в качестве учетной записи компьютера и, таким образом, может указывать Active Directory, когда вносить изменения в себя и когда служба SPN SQL хочет зарегистрироваться. Когда вы меняете учетную запись SQL Server на учетную запись пользователя домена AD, локальная системная учетная запись немедленно теряет возможность контролировать это; поэтому необходимо вручную удалить существующие имена участников-служб, ранее зарегистрированные для этой службы SQL в локальной системе перед регистрацией новых имен участников-служб. Теперь вы должны заметить, почему приятно, что сценарий SQL-сервера услужливо вызывает удаление старого SPN с последующей регистрацией нового для предотвращения проблем. Если это не сделано должным образом - вы получите ошибку аутентификации, когда клиенты kerberos получат билет для старого недопустимого SPN, - потому что он никогда не был удален, и любая служба, поддерживающая Kerberos, всегда будет отклонять билет для неправильного SPN. После внесения изменений в SPN всегда обязательно перезапускайте службу SQL Server, а сразу после этого, если вы проводите тестирование с пользователем, выйдите из системы и войдите снова. Это дает ответ на ваш главный вопрос.

См. Этот документ Microsoft для дальнейшего чтения по этой теме: Зарегистрировать имя участника службы для подключений Kerberos. На YouTube также есть очень хорошее видео на YouTube, посвященное именно этой проблеме, вот где я узнал об этом и как чтобы решить эту проблему. Не обращайте внимания на «SSRS» в названии, я просмотрел все, и рекомендации применимы ко всем без исключения службам SQL, имеющим SPN.

В самом конце у вас был второстепенный вопрос о том, как лучше всего справиться с ситуацией. Если вы говорите о решении этой проблемы программным путем, на это будет очень сложно ответить, поскольку все среды в чем-то различаются, и вы столкнетесь с экземплярами SQL, работающими во всевозможных разных контекстах безопасности. На таком онлайн-форуме вы, вероятно, получите разные ответы от разных людей. Если бы это был ваш единственный вопрос, я думаю, модераторы закрыли бы его за то, что «в первую очередь основывались на мнениях» и могли привлечь спам-ответы. Я бы посоветовал вам включить какое-то руководство по проблеме в какой-либо файл Readme, который вы должны упаковать с мастером InstallShield.

Боковое примечание: я думаю, вам следует добавить тег kerberos ответьте на этот вопрос, поскольку имена участников-служб относятся только к Kerberos, а не к любому другому протоколу проверки подлинности.