Spn windows что это

Обновлено: 05.07.2024

Как известно, службы Windows представляют собой одно из наиболее излюбленных мест для атак на операционную систему. В худшем (для нас, конечно) случае атакующий получает возможность действовать на атакованном компьютере в контексте учетной записи, от имени которой запущена взломанная служба. И если эта учетная запись обладает административными правами, то фактически злоумышленник получает полный контроль над компьютером. От версии к версии в Windows появляются новые механизмы, обеспечивающие дополнительную изоляцию служб и, как следствие, усиливающие безопасность системы в целом. Я хотел бы вкратце рассмотреть, что принципиально изменилось в этом направлении за последние несколько лет.

Первые существенные изменения в механизмах защиты служб появились в Windows XP Service Pack 2. Сейчас уже сложно себе это представить, но до выхода SP2 все службы самой операционной системы запускались в контексте встроенной учетной записи Local System, обладающей на компьютере максимально полными административными правами. SP2 добавил еще две записи: Local Service и Network Service. Принципиальные отличия трех перечисленных записей можно найти в табл. 1.

Учетная запись	Локальные ресурсы	Сетевые ресурсы
Local System	Полный доступ ко всем ресурсам компьютера	Подключение к сетевым ресурсам в контексте учетной записи компьютера, на котором запущена
Local Service	Права стандартного пользователя + небольшой набор дополнительных привилегий	Анонимное подключение к сетевым ресурсам
Network Service	Права стандартного пользователя + небольшой набор дополнительных привилегий	Подключение к сетевым ресурсам в контексте учетной записи компьютера, на котором запущена. Маркер доступа также содержит SID групп Everyone и Authenticated Users

Таблица 1

Соответственно, начиная с Windows XP SP2, администратор мог настраивать запуск службы в контексте одной из встроенных учетных записей, локальной или доменной учетной записи. Тем не менее, большая часть служб самой Windows по-прежнему запускается в контексте Local System. Но даже если абстрагироваться от этого, ситуация, когда несколько служб запускаются в контексте одной и той же учетной записи, приводит к тому, что успешный взлом одной службы, пусть даже без административных привилегий, потенциально открывает для атакующего любые другие ресурсы, к которым имеет доступ учетная запись взломанной службы.

В Windows Vista появилось несколько механизмов, повышающих изоляцию служб. Я остановлюсь на двух.
Первый механизм – это уникальный идентификатор безопасности службы (Service SID). Данный SID генерируется для каждой службы путем хеширования имени службы с помощью алгоритма SHA-1. К результату добавляется префикс S-1-5-80-. Просмотреть SID службы можно с помощью команды sc showsid, указав в качестве параметра имя службы (см. рис. 1).
Рис. 1

Вы можете поэкспериментировать, например, со службой W32Time. Для любой папки на NTFS в настройках разрешений (permissions) нужно лишь ввести имя пользователя в формате NT SERVICE\<имя службы>, в нашем случае NT SERVICE\w32time (см. рис 2).
Рис. 2

Нажимаете Check Names, затем ОК и видите пользователя (см. рис. 3), которому можно назначать права.

Рис. 3

Еще раз подчеркну, что w32time не является объектом-пользователем. Это – SID, но раз так, его можно использовать в списках ACL, причем как в графическом интерфейсе, так и в командной строке и программным путем. Более того, сервисные SID-ы можно использовать в настройках Windows Firewall, применяя те или иные правила к конкретной службе, точнее конкретному Service SID.

Второй изменение, появившееся в Vista, это идентификаторы безопасности нового типа – Write Restricted SID. Если служба помечена типом Write Restricted SID, то ее SID добавляется в ее же маркере доступа в специальный список – Restricted SID list. При попытке такой службы записать что-либо в какой-либо файл алгоритм проверки прав доступа несколько изменяется. А именно, служба сможет записать в файл только в том случае, если разрешение Write дано явным образом SID-у этой службы, либо группе Everyone.
Например, учетная запись ServiceAccount1 некоторой службы Service1 является членом группы Group1. Группа Group1 и только она имеет разрешение Write на папку Folder1. Что произойдет, если служба попытается что-то изменить в папке Folder1? В обычной ситуации ServiceAccount1 получит возможность записи в папку за счет членства в Group1. Но если служба Service1 помечена типом Write Restricted SID, то ее маркер доступа обрабатывается иначе, и она не сможет записать что-либо в папку, поскольку ей явным образом не дано разрешение Write, равно как не дано это право и Everyone.
Просмотреть тип идентификатора безопасности можно с помощью команды sc qsidtype (см. рис. 4).
Рис. 4

В частности, на рис. 4 вы видите, что служба Windows Firewall относится как раз к упомянутому типу. Естественно, что введен этот тип был для того, чтобы дополнительно ограничить возможности службы (возможности стереть или перезаписать что-либо) в случае ее успешного взлома. Надо также добавить, что данный механизм предназначен в первую очередь не для администраторов систем, а для разработчиков служб. Только бы пользовались.

В Windows 7 и Windows Server 2008 R2 работа над изоляцией служб была продолжена. Появились виртуальные учетные записи (virtual accounts) и управляемые учетные записи служб (managed service accounts). А собственно в чем проблема? Нужно изолировать службы – давайте создадим нужное количество локальных (или доменных) учетных записей пользователей. Для каждой критически важной службы свой account. Да, это решение. Но для локальных служб, которым не нужен сетевой доступ к ресурсам, необходимо вручную задавать пароли, длинные и сложные. И также вручную их периодически обновлять. Ну, раз уж мы за безопасность. Для служб, которые должны по сети обращаться к ресурсам в контексте доменных учетных записей, плюс к этому еще нужно регистрировать Service Principal Name (SPN), свой для каждой службы. Это неудобно. Но неудобство становится реальной проблемой, когда служба из-за просроченного пароля не может стартовать. А админ просто забыл сменить для нее пароль.

Так вот для локальных служб вы можете использовать virtual accounts. Виртуальная учетная запись используется только для запуска конкретной службы, точнее для создания контекста безопасности конкретной службы. Вы не найдете эту запись среди пользователей в Computer Management. И, тем не менее, это – account, со своим уникальным SID-ом, со своим пользовательским профилем. А стало быть, вы можете назначать ему разрешения и, тем самым, разграничивать права доступа и четко их контролировать. Но также как и в случае с Local System, Local Service и Network Service операционная система берет на себя задачи управления паролями для virtual accounts. Мы изолируем нужные службы, и у нас не болит голова о паролях.

Чтобы создать виртуальную учетную запись, нужно в настройках службы указать в качестве учетной записи: NT SERVICE\<имя службы> (см. рис 5)

Рис. 5

После запуска службы virtual account отобразится в консоли Services (рис. 6), а в папке Users вы заметите появление нового пользовательского профиля.
Рис. 6

По формату это очень напоминает сервисный SID. Но подчеркну, это не просто дополнительный уникальный SID для службы как в Vista, это отдельная учетная запись и, соответственно, другой уровень изоляции. По умолчанию виртуальные учетные записи используются, например, для пулов приложений (application pool) в IIS 7.5 в Windows Server 2008 R2. Надо иметь в виду, что virtual accounts предназначены для локального использования. Если служба, запущенная в контексте virtual account, обращается по сети, то это обращение происходит от имени учетной записи компьютера, на котором служба запущена. Если же необходимо, чтобы служба, например SQL Server, работала по сети от имени доменной учетной записи, то здесь как раз помогут managed service accounts. С ними, однако, связано больше тонкостей, и их рассмотрение выходит за рамки данного поста. Более подробно с MSA можно познакомиться здесь.

Перечисленные мною механизмы изоляции служб на этом не заканчиваются. Можно еще упомянуть об изоляции нулевого сеанса, уровнях целостности, механизме DEP. Я сосредоточился на тех, которые, как мне кажется, в меньшей степени известны, но при этом имеют вполне практический смысл для администратора. Ну и конечно, работа по усилению защищенности служб в последующих версиях Windows будет продолжена.

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

К примеру, по итогам пентеста в одной компании мы пришли к выводу, что все доступные машины в домене были не ниже Windows10/Windows Server2016, и на них стояли все самые свежие патчи. Сеть регулярно сканировалась, машины хардились. Все пользователи сидели через токены и не знали свои «20-символьные пароли». Вроде все хорошо, но протокол IPv6 не был отключен. Схема захвата домена выглядела так:
mitm6 -> ntlmrelay -> атака через делегирование -> получен хеш пароля локального администратора -> получен хеш пароля администратора домена.
К сожалению, такие популярные сертификации, как OSCP, GPEN или CEH, не учат проведению тестирования на проникновение Active Directory.

В этой статье мы рассмотрим несколько видов атак на Active Directory, которые мы проводили в рамках пентестов, а также используемые инструменты. Это ни в коем случае нельзя считать полным пособием по всем видам атак и инструментам, их действительно очень много, и это тяжело уместить в рамках одной статьи.

Итак, для демонстрации используем ноутбук на Kali Linux 2019 и поднятые на нем виртуальные хосты на VMware. Представим, что главная цель пентеста — получить права администратора домена, а в качестве вводных данных у нас есть доступ в корпоративную сеть компании по ethernet. Чтобы начать тестировать домен, нам понадобится учетная запись.

Получение учетной записи
Рассмотрим два самых распространенных, по моему мнению, метода, позволяющих получить логин и пароль доменной учетной записи: LLMNR/NBNS-спуфинг и атаку на протокол IPv6.

LLMNR/NBNS-спуфинг
Про эту атаку было сказано довольно много. Суть в том, что клиент рассылает мультикастные LLMNR- и широковещательные NBT-NS-запросы для разрешения имен хостов, если сделать это по DNS не удалось. На такие запросы может ответить любой пользователь сети.

Полученный хеш мы можем сбрутить или выполнить NTLM-релей.

Атака на протокол IPv6
Если в корпоративной сети используется IPv6, мы можем ответить на запросы DHCPv6 и установить в качестве DNS-сервера на атакуемой машине свой IP-адрес. Так как IPv6 имеет приоритет над IPv4, DNS-запросы клиента будут отправлены на наш адрес. Подробнее об атаке можно прочитать тут .

После выполнения атаки на атакуемой рабочей станции появится новый DNS-сервер с нашим IPv6-адресом.

Атакуемые машины будут пытаться аутентифицироваться на нашей машине. Подняв SMB-сервер с помощью утилиты smbserver.py , мы сможем получить хеши паролей пользователей.

Действия с захваченными хешами
Следующим шагом мы можем либо выполнить криптографическую атаку на хеши паролей и получить пароль в открытом виде, либо выполнить NTLM relay.

Перебор пароля
Тут все просто: берем хеш пароля, hashcat

и брутим. Пароль либо удастся получить, либо нет :)

Пароль пользователя Harvey был восстановлен — Pbvf2019

NTLM Relay
Также мы можем выполнить NTLM-релей. Предварительно убедившись, что не используется SMB Signing, применяем утилиту ntlmrelayx.py и проводим атаку. Здесь опять же, в зависимости от цели, выбираем нужный нам вектор. Рассмотрим некоторые из них.

Доступ к атакуемой машине по протоколу SMB
Выполним атаку с ключом i .

При удачной атаке мы сможем подключиться к удаленной машине с помощью netcat.

Cбор информации о домене

В данном случае выполняем релей на контроллер домена.

При успешном проведении атаки получим подробную информацию о домене:

Добавление нового компьютера в домен
Каждый пользователь по умолчанию имеет возможность создать до 10 компьютеров в домене. Чтобы создать компьютер, нужно выполнить релей на контроллер домена по протоколу ldaps. Создание пользователей и компьютеров по незашифрованному соединению ldap запрещено. Также не удастся создать учетную запись, если будет перехвачено соединение по SMB.

Как видно на рисунке, нам удалось создать компьютер RORYOTGS$.
При создании более 10 компьютеров получим ошибку следующего вида:

Используя учетные данные компьютера RORYOTGS$, мы можем выполнять легитимные запросы к контроллеру домена.

Сбор информации о домене
Итак, у нас есть учетная запись доменного пользователя либо компьютера. Для продолжения тестирования нам нужно собрать доступную информацию для дальнейшего планирования атак. Рассмотрим некоторые инструменты, которые помогут нам определиться с поиском наиболее критичных систем, спланировать и выполнить атаку.

BloodHound
Один из самых важных инструментов, который используется практически во всех внутренних тестированиях на проникновение. Проект активно развивается и дополняется новыми фичами.

В качестве базы данных используется Neo4j , имеющая свой синтаксис, что позволяет выполнять кастомные запросы. Подробнее ознакомиться с синтаксисом можно тут .

Также разработчики предоставляют скрипт DBCreator.py , который позволяет сгенерировать случайную базу для проведения тестов.

CypherDog
CypherDog — оболочка BloodHound, написанная на powershell. Включает в себя 27 командлетов.

По умолчанию для доступа к базе neo4j требуется аутентификация. Отключить аутентификацию можно, отредактировав файл neo4j.conf. В нем необходимо раскомментировать строку dbms.security.auth_enabled=false. Но так делать не рекомендуется, поскольку любой пользователь сможет подключиться к базе по адресу 127.0.0.1:7474 (конфигурация по умолчанию). Более подробно об аутентификации и авторизации в neo4j можно прочитать тут.

GoFetch
GoFetch использует граф, созданный в bloodhound для планирования и выполнения атаки.

gt-generator
gt-generator , используя данные BloodHound, упрощает создание golden-тикетов. Для получения golden-тикета необходимы только имя пользователя и хеш пароля пользователя KRBTGT.

PowerView
PowerView — Powershell-фреймворк, входящий в состав PowerSploit . Ниже приведен список некоторых командлетов, которые помогут при сборе информации о домене.

При использовании интегрированного DNS в Active Directory любой пользователь домена может запросить все DNS-записи, установленные по умолчанию.

Roasting
Атака через ACL
Делегирование Kerberos
Abusing GPO Permissions

Kerberoast
Asreproast

Чтобы понять суть атаки, рассмотрим, как работает Kerberos.

1. Пароль преобразуется в NTLM-хеш, временная метка шифруется хешем и отправляется на KDC в качестве аутентификатора в запросе TGT-тикета (AS-REQ). Контроллер домена (KDC) проверяет информацию пользователя и создает TGT-тикет.

2. TGT-тикет шифруется, подписывается и отправляется пользователю (AS-REP). Только служба Kerberos (KRBTGT) может открыть и прочитать данные из TGT-тикета.

3. Пользователь представляет TGT-тикет контроллеру домена при запросе TGS-тикета (TGS-REQ). Контроллер домена открывает TGT-тикет и проверяет контрольную сумму PAC.

4. TGS-тикет шифруется NTLM-хешем пароля сервисной учетной записи и отправляется пользователю (TGS-REP).

5. Пользователь предоставляет TGS-тикет компьютеру, на котором запущена служба (AP-REQ). Служба открывает TGS-тикет с помощью своего NTLM-хеша.

6. Доступ к сервису предоставлен (AS-REP).

Получив TGS-тикет (TGS-REP), мы можем подобрать пароль сервисной учетной записи в офлайн-режиме. Например, с помощью hashcat.

AES256_CTS_HMAC_SHA1
AES128_CTS_HMAC_SHA1
RC4_HMAC_MD5

Отключать RC4_HMAC_MD5 необходимо на уровне домена.

Атака Kerberoasting имеет 2 подхода.

Инструменты для проведения атаки:

GetUserSPN.ps1
Find-PSServiceAccounts.ps1
Get-NetUSER -SPN
(Get-ADUser -Filter -Properties ServicePrincipalName).ServicePrincipalName

Invoke-Mimikatz -Command ‘«Kerberos::list /export»'
Mimikatz -Command ‘«Kerberos::list /export»'
Invioke-Kerberoast
tgsrepack.py

Уязвимость встречается редко, так как отключение предварительной аутентификации — это не настройка по умолчанию.

троен как для отдельного объекта (например, учетная запись пользователя), так и для организационной единицы, например OU. При настройке ACL на OU все объекты внутри OU будут наследовать ACL. В списках ACL содержатся записи управления доступом (ACE), которые определяют способ взаимодействия SID с объектом Aсtive Directory.
К примеру, у нас есть три группы: А, Б, С, — где группа С является членом группы Б, а группа Б является членом группы А. При добавлении пользователя guest в группу С пользователь guest будет не только членом группы С, но и косвенным членом групп Б и А. При добавлении доступа к объекту домена группе А пользователь guest тоже будет иметь доступ к этому объекту. В ситуации, когда пользователь является прямым членом только одной группы, а эта группа является косвенным членом других 50 групп, легко потерять связь унаследованных разрешений.

Получить ACL, связанные с объектом, можно, выполнив следующую команду

Пользователь добавляется в необходимые группы.
Два ACE (Replicating Directory Changes и Replicating Directory Changes ALL) добавляются в ACL объекта домена.
При наличии прав на DCSync с помощью утилиты Mimikatz запрашивается хеш пароля пользователя krbtgt (настройка по умолчанию).
После завершения эксплуатации скрипт удаляет все добавленные группы и записи ACE в ACL.

ForceChangePassword. Права на изменение пароля пользователя, когда текущий пароль не известен. Эксплуатация с помощью PowerSploit — Set-DomainUserPassword.
AddMembers. Права на добавление групп, компьютеров и пользователей в группы. Эксплуатация с помощью PowerSploit — Add-DomainGroupMember.
GenericWrite. Права на изменение атрибутов объекта. Например изменить значение параметра scriptPath. При следующем входе пользователя в систему запустится указанный файл. Эксплуатация с помощью PowerSploit — Set-DomainObject.
WriteOwner. Права на изменения владельца объекта. Эксплуатация с помощью PowerSploit — Set-DomainObjectOwner.
AllExtendedRights. Права на добавление пользователей в группы, смена паролей пользователя и др. Эксплуатация с помощью PowerSploit — Set-DomainUserPassword or Add-DomainGroupMember.

Invoke-ACLPwn

Запуск с машины, которая не находится в домене

Делегирование полномочий Kerberos позволяет повторно использовать учетные данные конечного пользователя для доступа к ресурсам, размещенным на другом сервере.

Неограниченное (Unconstrained delegation). Единственный вариант делегирования до Windows Server 2003
Ограниченное (Сonstrained delegation), начиная с Windows Server 2003
Ограниченное на основе ресурсов (Resource-Based Constrained Delegation). Появилось в Windows Server 2012

Для наглядности рассмотрим, как происходит неограниченное делегирование на схеме.

Пароль пользователя конвертируется в ntlm-хеш. Временная метка шифруется этим хешем и отправляется на контроллер домена для запроса TGT-тикета.
Контроллер домена проверяет информацию о пользователе (ограничение входа в систему, членство в группах и т.д.), создает TGT-тикет и отправляет пользователю. TGT-тикет зашифрован, подписан, и его данные могут быть прочитаны только krbtgt.
Пользователь запрашивает TGS-тикет для доступа на веб-сервис на веб-сервере.
Контроллер домена предоставляет TGS-тикет.
Пользователь отправляет TGT- и TGS-тикеты на веб-сервер.
Сервисная учетная запись веб-сервера использует TGT-тикет пользователя для запроса TGS-тикета для доступа к серверу БД.
Сервисная учетная запись подключается к серверу БД как пользователь.

Ограниченное делегирование
Режим ограниченного делегирования позволяет получить доступ только к разрешенным сервисам и на определенной машине. В оснастке Active Directory выглядит следующим образом:

S4U2Proxy позволяет учетной записи службы использовать перенаправляемый тикет, полученный в процессе S4U2proxy, для запроса TGS-тикета для доступа к разрешенным сервисам (msds-allowtodelegateto). KDC проверяет, указан ли запрашиваемый сервис в поле msds-allowtodelegateto запрашивающего пользователя, и выдает билет, если проверка прошла успешно. Таким образом, делегирование «ограничено» конкретными целевыми сервисами.

Поиск компьютеров и пользователей в домене с ограниченным делегированием можно выполнить с помощью PowerView .

Поиск компьютеров с неограниченным делегированием

Поиск пользователей с ограниченным делегированием

Для проведения атаки нам необходим пароль в открытом виде, NTLM-хеш пароля либо TGT-тикет.

Ограниченное делегирование на основе ресурсов
Как и в обычном делегировании, используются расширения S4U. Так как делегирование на основе ресурсов — это в первую очередь ограниченное делегирование, то и здесь доступны атаки, актуальные для обычного ограниченного делегирования. Отличие только в том, что в простом ограниченном делегировании сервис А должен иметь атрибут msDS-AllowedToDelegateTo =ServiceB, а тут сервис B должен иметь атрибут msDS-AllowedToActOnBehalfOfOtherIdentity =Service A.

Это свойство позволяет провести еще одну атаку , опубликованную пользователем harmj0y . Для проведения атаки необходимы права на изменение параметра PrincipalsAllowedToDelegateToAccount, который задает атрибут msds-AllowedToActOnBehalfOfOtherIdentity, содержащий список управления доступом (ACL). В отличие от просто ограниченного делегирования, нам не нужны права администратора домена, чтобы изменить атрибут msds-AllowedToActOnBehalfOfOtherIdentity. Узнать, кто имеет права на редактирование атрибута, можно следующим образом:

Итак, чтобы провести атаку, выполняем mitm6

Запускаем ntlmrelayx с опцией --delegate-access

В результате атаки создается компьютер ZGXTPVYX$ с правами на делегирование компьютера Windows7.

Хороший доклад про делегирование был представлен на PHDays Егором Подмоковым.

Abusing GPO Permissions
Group Policy Objects — инструмент, позволяющий администраторам эффективно управлять доменом. Но бывает так, что пользователям назначаются излишние права, в том числе и на изменение политик GPO.

Для демонстрации примера добавим пользователю Ragnar права на редактирование политики «Default Domain Controllers Policy» (в реальной жизни права для этой политики выдаются только администраторам домена, но суть атаки не меняется; в случае другой политики меняются лишь подконтрольные хосты).

Выполним перечисление прав на всех GPOs в домене, используя PowerView

Пользователь Ragnar имеет права на изменение GPO, имеющее GUID — 6AC1786C-016F-11D2-945F-00C04FB984F9. Чтобы определить, к каким хостам в домене применяется данная политика, выполним следующую команду

Получили хост dc1.jet.lab.

Зная конкретную политику, которую может редактировать пользователь Ragnar, и хосты, к которым применяется эта политика, мы можем выполнить различные действия на хосте dc1.jet.lab.

Выполнить задачу в планировщике задач
Добавить права пользователю (SeDebugPrivilege, SeTakeOwnershipPrivilege и др.)
Добавить скрипт, выполняющийся после автозагрузки
Добавить пользователя в локальную группу

После выполнения появляется запланированная задача test

И появляется Meterpreter-сессия

Чтобы удалить запланированную задачу, нужно выполнить следующую команду:

Выводы
В статье мы рассмотрели лишь некоторые векторы атак. Такие виды, как Enumerate Accounts и Password spray , MS14-068 , связка Printer Bug и Unconstrained Delegation, атаки на Exchange ( Ruler , PrivExchange , ExchangeRelayX ) могут значительно расширить область проведения атаки.

Техники атак и методы закрепления (Golden ticket, Silver ticket, Pass-The-Hash, Over pass the hash, SID History, DC Shadow и др.) постоянно меняются, а команде защиты нужно всегда быть готовой к новым видам атак.

Всем привет, сегодня хочу вам рассказать как настраивать SPN в Active Directory, на примере SPN для MS SQL Server 2012. В процессе загрузки свежее установленного экземпляра SQL Server в его логе можно обнаружить ошибку регистрации SPN, в случае если службы SQL Server запускаются от имени пользовательской доменной учетной записи. Необходимо зарегистрировать имя участника-службы (SPN — Service Principal Name) для учетной записи службы SQL Server, чтобы в работе службы могла использоваться проверка подлинности с помощью протокола Kerberos.

В нашем примере KOM-AD01-DB03 — это имя сервера SQL, а s-KOM-AD01-DB03-SQL01 — это имя пользовательской доменной учетной записи, из под которой запускаются службы SQL Server на этом сервере.

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-02

Как мы видим, ни на учетной записи компьютера ни на учетной записи пользователя нет SPN содержащих указатели MSSQLSvc. Помимо утилиты SetSPN мы можем воспользоваться оснасткой “AD Users and Computers” (dsa.msc) с включенным режимом отображения дополнительных компонент…

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-03

открыв свойства соответствующей учётной записи и перейдя на вкладку редактирования атрибутов можно посмотреть и изменить значение атрибута servicePrincipalName

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-04

Особенности работы с Kerberos аутентификацией в SQL Server (и в частности управление SPN) рассмотрены в статье KB319723 — How to use Kerberos authentication in SQL Server

Для того чтобы обеспечить нужное для корректной работы Kerberos содержание атрибута servicePrincipalName можно пойти двумя путями:

Создать необходимую SPN запись вручную с помощью утилиты SetSPN. Синтаксис команд будет следующий:

setspn –S MSSQLSvc/SQLServerFQDN:1433 DomainSQLAccount
setspn –S MSSQLSvc/SQLServerFQDN DomainSQLAccount

Разрешить учетной записи, от имени которой запускается SQL Server, динамическое обновление атрибута servicePrincipalName, выдав разрешения на чтение и запись атрибута servicePrincipalName. Для того чтобы выполнить второй вариант, откроем оснастку ADSIEdit.msc, перейдём к свойствам объекта – учетной записи. На закладке “Безопасность” (Security) нажмём кнопу “Дополнительно” (Advanced)

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-05

В диалоговом окне «Дополнительные параметры безопасности» (Advanced Security Settings) нажмём кнопку «Добавить» (Add)

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-06

введём SELF и в открывшемся окне перейдём на закладку «Свойства» (Properties). В окне выбора области применения выберем пункт «Только этот объект» (This object only) и в списке разрешений отметим два пункта:

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-07

Сохраним внесённые изменения и затем, при запуске службы SQL Server, сможем убедиться в том, что в журнале регистрации событий появилась запись об успешном создании SPN

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-08

а так же увидим что вывод утилиты SetSPN изменился

Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-09

Как удалить SPN

setspn -d MSSQLSvc/server19.ваш домен:1433 имя учетной записи от имени которой запускается sql
setspn -d MSSQLSvc/server19.ваш домен:MSSQL2012 имя учетной записи от имени которой запускается sql

Вот пример ситуации когда нужно удаление. Был раньше сервер virt105 и использовался под одни нужды, сервер удален. После по этому же имени virt105 подняли другой сервер, и столкнулись с тем, что SPN уже был занят. Вот запрос на проверку SPN у virt105

Далее попытка его зарегистрировать, и видим, что он уже есть на учетную запись Семина Ивана

Описание ошибки 0x21c7/8647

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

SPN позволяют подключаться к соответствующему экземпляру SQL Server с удаленного компьютера. Для этого необходимо, чтобы SPN уже существовал. Чтобы это происходило каждый раз при запуске экземпляра SQL Server, необходимо создать соответствующее имя участника-службы. Поскольку ваш экземпляр работает под учетной записью службы, вам необходимо предоставить некоторые разрешения, чтобы это произошло.

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

Failed to assign SPN on account 'CN=run-t,OU=Run-users,DC=Pyatilistnik,DC=org', error 0x21c7/8647 -> The operation failed because SPN value provided for addition/modification is not unique forest-wide.

Если попытаться добавить SPN в ручную через оснастку "Active Directory - Пользователи и компьютеры" или через ADSIedit, то ошибка воспроизведется.

Ошибка операции. Код ошибки: 0x21c7. Не удалось выполнить операцию, так как значение имени субъекта-службы, представленное для добавления или изменения, не является уникальным в пределах леса.

Еще данная ситуация может легко появляться, когда вы произвели миграцию компьютера из одного домена в другой, или же произвели восстановление объекта Active Directory из корзины, например такой восстановленный объект вызывал ошибку дублирования SPN ID 11.

Устранение ошибки дублирования SPN

Вообще это нормальное поведение, что служба каталогов Active Directory производит проверку одинаковых SPN, но возможность отключения такого поведения все же есть. Первое, что вы должны сделать, это зайти на любой из контроллеров домена, которые отвечают за домен, где располагается сервер у которого есть дубль SPN. Откройте оснастку просмотр событий или же можете воспользоваться утилитой Windows Admin Center, это не принципиально. Найдите там журнал "ActiveDirectory_DomainService". В этом журнале поищите событие с кодом ID 2974.

Так же найти все SPN для нужного объекта можно через команду:

dsquery * -filter servicePrincipalName=* | findstr имя объекта

Из ошибки ID 2974, мы видим, где именно уже прописан наш SPN, это учетная запись пользователя СИНИНТ. Давайте зайдем в ее свойства и удалим их.

Далее попробуем заново зарегистрировать SPN записи:

Читайте также: