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

SQL Server, работающий под учетной записью домена, не может зарегистрировать свое SPN

Я пытаюсь настроить новую установку SQL Server для работы под учетной записью домена. Однако я получаю периодические ошибки при попытке подключиться к серверу с использованием другой учетной записи домена, и я все еще вижу The SQL Server Network Interface library could not register the Service Principal Name при трале файла ERRORLOG.

Я добавил свою учетную запись службы (не управляемую учетную запись службы, а просто учетную запись обычного пользователя) в группу AD (например, SQL Servers), и я добавил ACE в свой домен Computers ACL контейнера для этой группы, выбрав:

Я реплицировал это на все контроллеры домена и подтвердил наследование нового ACE конкретному объекту компьютера, используя как вкладку «Действующие разрешения», так и dsacls CN=SERVER01,CN=Computers,DC=fabrikam,DC=local, последний из которых теперь включает:

Allow FABRIKAM\SQL Servers
                                  SPECIAL ACCESS for Validated write to service principal name   <Inherited from parent>
                                  WRITE SELF
Allow FABRIKAM\SQL Servers
                                  SPECIAL ACCESS for Validated write to service principal name   <Inherited from parent>
                                  WRITE SELF
                                  WRITE PROPERTY
                                  READ PROPERTY

Однако, когда я перезапускаю службу SQL Server, я все еще вижу could not register the Service Principal Name сообщение. Я также перезапустил сервер с тем же результатом.

Я использовал Sysinternals Process Explorer для проверки работоспособности sqlservr.exe; на вкладке «Безопасность» четко указан правильный пользователь службы и его членство в SQL Servers группа.

Я знаю, что могу вручную добавить SPN с помощью setspn -A, но дело не в этом.

Что еще я должен сделать, чтобы учетная запись службы (и любая будущая учетная запись, которую я помещаю в SQL Servers group) может автоматически регистрировать собственное SPN без ручного вмешательства?

И / ИЛИ

Как я могу дополнительно определить, какие привилегии / разрешения здесь отсутствуют?

Я нашел это.

Я вручную зарегистрировал SPN в учетной записи службы, затем проверил AD с помощью ADSIEdit и обнаружил, что зарегистрированные вручную SPN не были сохранены в servicePrincipalName поле Компьютер счет, но servicePrincipalName область конкретных Пользователь учетная запись.

Итак, вместо того, чтобы предоставлять мои SQL Servers групповые права на регистрацию своих собственных имен SPN, я (случайно) предоставил им права на изменение имен SPN, зарегистрированных службами, работающими как учетные записи локальной системы / сетевой службы на этом компьютере.

Я удалил новый ACE из Computers контейнер и вместо этого создал новый SQL Servers Организационная единица. Я добавил ACE для SELF к этому OU и ограничил его применение к потомку пользователи:

  • SQL Servers OU ACL
    • SELF
      • Применить к: дочерним объектам пользователя
      • Прочтите servicePrincipalName: Разрешить
      • Написать servicePrincipalName: Разрешить

Теперь, когда я запускаю свой экземпляр SQL Server, я вижу ожидаемый The SQL Server Network Interface library successfully registered the Service Principal Name, и Kerberos теперь используется для моих удаленных подключений.

(Теперь обновим нашу внутреннюю документацию по процессам, чтобы новые учетные записи служб SQL Server создавались в новом подразделении, а не добавлялись в группу)

Редактировать: Обратите внимание, что администратор домена также может вручную зарегистрировать SPN в учетной записи домена, используя setspn.exe.

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:1433 DOMAIN\User
setspn -S MSSQLSvc/myhost.redmond.microsoft.com DOMAIN\User

Зарегистрируйте имя участника-службы для подключений Kerberos (TechNet).

Изменить 2: Если Read servicePrincipalName и Write servicePrincipalName свойства не отображаются в списке ACE, перейдите в Редактор атрибутов вкладка объекта Свойства диалоговом окне щелкните Фильтр кнопку и убедитесь в следующем:

  • Показать только атрибуты, у которых есть значения является не отмечен
  • Показать только доступные для записи атрибуты является не отмечен
  • Показать атрибуты: обязательно является проверил
  • Показать атрибуты: необязательно является проверил
  • Показать атрибуты только для чтения: Создано является проверил
  • Показать атрибуты только для чтения: обратная ссылка является проверил
  • Показать атрибуты только для чтения: только для системы является проверил

(Могут работать и другие комбинации, но мне это подходит)

Вы не сказали, какую версию SQL Server вы используете, ни разрешения учетной записи службы (кроме того, что она не является управляемой учетной записью службы и имеет запись SPN), но из предоставленной вами информации я считаю, что учетная запись не не имеет права регистрироваться как SPN. Хотя, да, вы это прямо предоставили.

По-видимому, SQL 2012 требует виртуальная учетная запись или управляемая учетная запись службы на сервере 2008:

Когда служба компонента Database Engine запускается, она пытается зарегистрировать имя участника-службы (SPN). Если учетная запись, запускающая SQL Server, не имеет разрешения на регистрацию имени участника-службы в доменных службах Active Directory, этот вызов завершится ошибкой, и в журнал событий приложений, а также в журнал ошибок SQL Server будет занесено предупреждающее сообщение. Чтобы зарегистрировать SPN, компонент Database Engine должен работать под встроенной учетной записью, такой как Local System (не рекомендуется) или NETWORK SERVICE, или под учетной записью, имеющей разрешение на регистрацию SPN, например под учетной записью администратора домена. Когда SQL Server работает в операционной системе Windows 7 или Windows Server 2008 R2, вы можете запускать SQL Server, используя виртуальную учетную запись или учетную запись управляемой службы (MSA). И виртуальные учетные записи, и MSA могут регистрировать SPN. Если SQL Server не работает под одной из этих учетных записей, имя участника-службы не регистрируется при запуске, и администратор домена должен зарегистрировать его вручную.

Надеюсь, это поможет.

Если имя учетной записи AD, используемой службой SQL, длиннее 20 символов, SetSpn.exe не сможет найти его в AD, и единственный способ получить ваши сеансы SQL для аутентификации с использованием Kerberos - это перенастройка разрешений AD и перезапуск SQL. Не пытайтесь обмануть SetSpn.exe -S, сократив параметр имени: SetSpn.exe затем найдет учетную запись, но зарегистрирует ее с именем, которое "не соответствует" для Kerberos.

@Katherine Villyard

Когда служба компонента Database Engine запускается, она пытается зарегистрировать имя участника-службы (SPN). Если учетная запись, запускающая SQL Server, не имеет разрешения на регистрацию имени участника-службы в доменных службах Active Directory, этот вызов завершится ошибкой, и в журнал событий приложений, а также в журнал ошибок SQL Server будет занесено предупреждающее сообщение. Чтобы зарегистрировать SPN, компонент Database Engine должен работать под встроенной учетной записью, такой как Local System (не рекомендуется) или NETWORK SERVICE, или под учетной записью, имеющей разрешение на регистрацию SPN, например под учетной записью администратора домена. Когда SQL Server работает в операционной системе Windows 7 или Windows Server 2008 R2, вы можете запускать SQL Server, используя виртуальную учетную запись или учетную запись управляемой службы (MSA). И виртуальные учетные записи, и MSA могут регистрировать SPN. Если SQL Server не работает под одной из этих учетных записей, имя участника-службы не регистрируется при запуске, и администратор домена должен зарегистрировать его вручную.

Итак, я нашел повторяющиеся SPN setspn -x

Один связан с сервером и снова с учетной записью администратора домена. В свойствах компьютера указано «Чтение / запись SPN» как действующие разрешения, а в учетной записи администратора - нет. несмотря на это .... Как я могу быть уверен в том, из какой учетной записи нужно удалить соответствующее SPN?

Спасибо. Не обращайте внимания на мой вопрос, если он звучит глупо.

С уважением Раджен