Настройка аутентификации windows в asp.net core

Get an existing service principal

A list of the service principals in a tenant can be retrieved with . By default this
command returns the first 100 service principals for your tenant. To get all of a tenant’s service principals, use the parameter. Getting this list can take a long time, so it’s
recommended that you filter the list with one of the following parameters:

requests service principals that have a prefix that match the provided name. The display name of a service principal is the value set with the
parameter during creation. If you didn’t set during service principal creation, the name prefix is .
filters on exact service principal name matching. The service principal name always starts with .
if the value you used for wasn’t a URI, this value is followed by the display name.
requests only service principals created by the signed-in user.
takes an OData filter, and performs server-side filtering. This method is recommended over filtering client-side with the CLI’s parameter. To learn about OData filters, see OData expression syntax for filters.

The information returned for service principal objects is verbose. To get only the information necessary for sign-in, use the query string
. For example, to get the sign-in information for all service principals created by the currently logged in user:

Important

or get the user and tenant, but not any authentication secrets or the authentication method.
Secrets for certificates in Key Vault can be retrieved with , but no other secrets are stored by default.
If you forget an authentication method or secret, .

Генерирование keytab-файла[править]

Создать keytab-файл можно разными способами.
Рассмотрим некоторые из них.

На контроллере домена Windows 2008 R2править

Необходимо выполнить следующую команду:

C:\>ktpass -princ HTTP/[email protected] -mapuser squid -pass Pa$$word -ptype KRB5_NT_PRINCIPAL -out C:\squid.keytab
Targeting domain controller: dcd.domg.testg
Using legacy password setting method
Successfully mapped HTTP/sqserver.domg.testg to squid.
Key created.
Output keytab to C:\squid.keytab:
Keytab version: 0x502
keysize 70 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 6
 etype 0x17 (RC4-HMAC) keylength 16 (0x1a4b1757588cab6298e29e91c06df58d)

Рассмотрим параметры команды подробнее:

-princ — имя принципала содержащее SPN и Kerberos-область (realm)
-mapuser — пользователь к которому привязывается SPN
-pass — пароль пользователя
-ptype — указывает тип принципала (рекомендуется KRB5_NT_PRINCIPAL)
-out — путь и имя генерируемого файла

С помощью ktutilправить

Этот способ работает если SPN предварительно были созданы и привязаны.
Установим необходимый пакет:

# apt-get install krb5-kadmin

Запустим ktutil и создадим keytab-файл:

# ktutil
ktutil:  addent -password -p HTTP/[email protected] -k 6 -e RC4-HMAC
Password for HTTP/[email protected]: 
ktutil:  wkt squid.keytab
ktutil:  q

С помощью Sambaправить

Для создания keytab-файла с помощью samba, необходима работающая kerberos-аутентификация.
При использовании этого метода нет необходимости генерировать и привязывать SPN на контроллере домена.
Приведите файл настроек /etc/samba/smb.conf к следующему виду:

realm = DOMG.TESTG
workgroup = DOMG
server string = Samba server on %h (v. %v)
security = ads
dedicated keytab file = /etc/krb5.keytab
kerberos method = dedicated keytab

Введите машину в домен:

# net -v ads join DOMG.TESTG -UAdministrator
Using short domain name -- DOMG
Joined 'DOSERVER' to dns domain 'domg.testg'

Проверить ввод в домен можно командой:

# net ads testjoin
Join is OK

После этого в домене будет создан аккаунт компьютера к которому можно будет привязать SPN.
Создадим keytab-файл для компьютера:

# net ads keytab create -UAdministrator

Добавим в keytab-файл принципала сервиса «HTTP»:

# net ads keytab add HTTP -U Administrator
Processing principals to add...

Далее можно поменять права на keytab и отредактировать его утилитой kutil.

С помощью Samba DCправить

При использовании этого метода kerberos ни при чём, а все действия выполняются на машине с домен-контроллером.

Создадим пользователя, с которым будем связывать создаваемые SPN:

samba-tool user create <someuser>
samba-tool user setexpiry <someuser> --noexpiry

Привяжем к нему SPN:

samba-tool spn add <service-name>/test.example.com <someuser>

(возможно несколько раз для разных сервисов)

создадим keytab:

samba-tool domain exportkeytab /tmp/keytab --principal=<service-name>/test.example.com

(выполняем несколько раз для всех spn, которые хотим поместить в keytab)

проверка (sudo klist -ke, работает):

klist -ke /tmp/keytab
  Keytab name: FILE:/etc/http.keytab
  KVNO Principal
  ---- --------------------------------------------------------------------------
     1 host/[email protected] (des-cbc-crc) 
     1 host/[email protected] (des-cbc-md5) 
     1 host/[email protected] (arcfour-hmac) 
     1 HTTP/[email protected] (des-cbc-crc) 
     1 HTTP/[email protected] (des-cbc-md5) 
     1 HTTP/[email protected] (arcfour-hmac)

С помощью FreeIPA Clientправить

# ipa-getkeytab -s dc.ipa.server.ru -p HTTP/httpserver.ipa.server.ru -k /etc/http.keytab

Где:

dc.ipa.server.ru — FreeIPA сервер
HTTP/httpserver.ipa.server.ru — SPN
/etc/http.keytab — куда запишется keytab

Авторизация пользователей

Состояние конфигурации анонимного доступа определяет способ использования и атрибутов в приложении. В следующих двух разделах объясняется, как обрабатывать запрещенные и разрешенные состояния конфигурации анонимного доступа.

Запрет анонимного доступа

Если проверка подлинности Windows включена и анонимный доступ отключен, атрибуты не влияют. Если сайт IIS настроен для запрета анонимного доступа, запрос никогда не достигает приложения. По этой причине атрибут неприменим.

Разрешить анонимный доступ

Если включена проверка подлинности Windows и анонимный доступ, используйте и атрибуты. Атрибут позволяет защитить конечные точки приложения, для которых требуется проверка подлинности. Атрибут переопределяет атрибут в приложениях, которые разрешают анонимный доступ. Сведения об использовании атрибутов см. в разделе «Простая авторизация» в ASP.NET Core.

Примечание

По умолчанию пользователи, не имеющие разрешения на доступ к странице, получают пустой ответ HTTP 403. можно настроить для предоставления пользователям более эффективного интерфейса «Отказано в доступе».

Использование

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

Сценарий	Описание
Приложение прежней версии не указывает имя участника-службы.	Этот сценарий совместимости гарантирует, что не будет изменений в работе приложений, разработанных для предыдущих версий SQL Server. Если имя участника-службы не указано, то приложение использует сформированные имена участников-служб и ничего не знает об используемом методе проверки подлинности.
Клиентское приложение, использующее текущую версию SQL Server Native Client, указывает имя субъекта-службы в строке подключения как учетную запись пользователя домена или компьютера, имя субъекта-службы для конкретного экземпляра или определяемую пользователем строку.	Ключевое слово ServerSPN может быть указано в строке поставщика, инициализации или соединения, для следующих целей. Указать учетную запись, используемую экземпляром SQL Server для соединения. Это упрощает доступ к проверке подлинности Kerberos. Если имеется центр распространения ключей Kerberos (KDC) и указана верная учетная запись, то проверка подлинности Kerberos будет предпочтительнее, чем NTLM. KDC обычно размещается на том же компьютере, что и контроллер домена. Указать имя субъекта-службы для поиска учетной записи службы для экземпляра SQL Server. Для каждого экземпляра SQL Server создаются два имени субъекта-службы по умолчанию, которые могут быть использованы для этой цели. Однако эти ключи не обязательно будут созданы в Active Directory, поэтому в такой ситуации проверка подлинности Kerberos не гарантирована. Указать имя субъекта-службы, которое будет использоваться для поиска учетной записи службы для экземпляра SQL Server. Это может быть любая определенная пользователем строка, сопоставляемая с учетной записью службы. В этом случае ключ должен быть вручную зарегистрирован в центре распространения ключей и удовлетворять правилам для определенных пользователем имен участников-служб. Ключевое слово FailoverPartnerSPN указывает имя партнера-службы для сервера-партнера по обеспечению отработки отказа. Ранг учетной записи и ключевые значения Active Directory те же, что и значения, которые можно указать для основного сервера.
Приложение ODBC указывает имя партнера-службы как атрибут соединения для основного сервера или сервера-партнера по обеспечению отработки отказа.	Атрибут соединения SQL_COPT_SS_SERVER_SPN может быть использован для указания имени участника-службы для соединения с основным сервером. Атрибут соединения SQL_COPT_SS_FAILOVER_PARTNER_SPN может быть использован для указания имени партнера-службы для сервера-партнера по обеспечению отработки отказа.
Приложение OLE DB указывает имя партнера-службы как свойство инициализации источника данных для основного сервера или сервера-партнера по обеспечению отработки отказа.	Свойство соединения SSPROP_INIT_SERVER_SPN в наборе свойств DBPROPSET_SQLSERVERDBINIT может быть использовано для указания имени участника-службы для соединения. Свойство соединения SSPROP_INIT_FAILOVER_PARTNER_SPN в DBPROPSET_SQLSERVERDBINIT может быть использовано для указания имени партнера-службы для сервера-партнера по обеспечению отработки отказа.
Пользователь указывает имя партнера-службы для сервера или сервера-партнера по обеспечению отработки отказа в имени источника данных (DSN) ODBC.	Имя участника-службы может быть указано в DSN ODBC через диалоговые окна настройки DSN.
Пользователь указывает имя партнера-службы для сервера или сервера-партнера по обеспечению отработки отказа в диалоговом окне Связь данных или Имя входа OLE DB.	Имя участника-службы может быть указано в диалоговом окне Связь данных или Имя входа . Диалоговое окно Имя входа может использоваться с ODBC или OLE DB.
Приложение ODBC определяет метод проверки подлинности, используемый для установления соединения.	Если соединение было установлено успешно, то приложение может запросить атрибут соединения SQL_COPT_SS_INTEGRATED_AUTHENTICATION_METHOD , чтобы определить, какой именно метод проверки подлинности будет использоваться. Эти значения включают NTLM , Kerberosи другие.
Приложение OLE DB определяет метод проверки подлинности, используемый при установлении соединения.	Если соединение было установлено успешно, то приложение может запросить свойство соединения SSPROP_AUTHENTICATION_METHOD в наборе свойств DBPROPSET_SQLSERVERDATASOURCEINFO для определения метода проверки подлинности, который будет использоваться. Эти значения включают NTLM , Kerberosи другие.

Проверка подлинности с помощью субъекта-службы

Создав субъект-службу и предоставив ему доступ к реестру контейнеров, вы сможете настроить его учетные данные для доступа к автономным приложениям и службам или использовать для входа команду . Используйте следующие значения.

Имя пользователя — идентификатор приложения (клиента) субъекта-службы
Password — пароль (секрет клиента) субъекта-службы

Каждое значение имеет формат .

Совет

Можно повторно создать пароль (секрет клиента) субъекта-службы, выполнив команду .

Использование учетных данных со службами Azure

Учетные данные субъекта-службы можно использовать из любой службы Azure, которая может выполнить проверку подлинности в реестре контейнеров Azure. Вы можете использовать учетные данные субъекта-службы вместо учетных данных администратора реестра в различных сценариях.

Например, с их помощью можно извлечь образ из реестра контейнеров Azure в службу Экземпляры контейнеров Azure.

Использование входа Docker

С помощью субъекта-службы можно запустить . В примере ниже идентификатор приложения субъекта-службы будет передан в переменной среды , а пароль — в переменной . Современные рекомендации по управлению учетными данными Docker см. в справочных материалах по команде docker login.

После входа в систему Docker кэширует учетные данные.

Использование с сертификатом

Если вы добавили к субъекту-службе сертификат, вы можете войти в Azure CLI с проверкой подлинности на основе сертификата, а затем воспользоваться командой для доступа к реестру. Использование сертификата в качестве секрета вместо пароля повышает защиту при работе в интерфейсе командной строки.

При создании субъекта-службы может быть создан самозаверяющий сертификат. Кроме того, можно добавить один или несколько сертификатов в существующий субъект-службу. Например, если вы используете один из скриптов, описанных в этой статье, чтобы создать или обновить субъект-службу с правами на извлечение или отправку образов из реестра, добавьте сертификат с помощью команды .

Чтобы использовать субъект-службу с сертификатом для , этот сертификат должен быть в формате PEM и содержать закрытый ключ. Если ваш сертификат не имеет нужного формата, используйте для его преобразования средство наподобие . При выполнении команды для входа в CLI с помощью субъекта-службы также укажите идентификатор приложения субъекта-службы и идентификатор арендатора Active Directory. В примере ниже эти значения показаны как переменные среды:

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

Интерфейс командной строки использует маркер, созданный при выполнении команды , для аутентификации вашего сеанса в реестре.

Использование

Сценарий	Описание
Приложение прежней версии не указывает имя участника-службы.	Этот сценарий совместимости гарантирует, что не будет изменений в работе приложений, разработанных для предыдущих версий SQL Server. Если имя участника-службы не указано, то приложение использует сформированные имена участников-служб и ничего не знает об используемом методе проверки подлинности.
Клиентское приложение, использующее текущую версию SQL Server Native Client, указывает имя субъекта-службы в строке подключения как учетную запись пользователя домена или компьютера, имя субъекта-службы для конкретного экземпляра или определяемую пользователем строку.	Ключевое слово ServerSPN может быть указано в строке поставщика, инициализации или соединения, для следующих целей. Указать учетную запись, используемую экземпляром SQL Server для соединения. Это упрощает доступ к проверке подлинности Kerberos. Если имеется центр распространения ключей Kerberos (KDC) и указана верная учетная запись, то проверка подлинности Kerberos будет предпочтительнее, чем NTLM. KDC обычно размещается на том же компьютере, что и контроллер домена. Указать имя субъекта-службы для поиска учетной записи службы для экземпляра SQL Server. Для каждого экземпляра SQL Server создаются два имени субъекта-службы по умолчанию, которые могут быть использованы для этой цели. Однако эти ключи не обязательно будут созданы в Active Directory, поэтому в такой ситуации проверка подлинности Kerberos не гарантирована. Указать имя субъекта-службы, которое будет использоваться для поиска учетной записи службы для экземпляра SQL Server. Это может быть любая определенная пользователем строка, сопоставляемая с учетной записью службы. В этом случае ключ должен быть вручную зарегистрирован в центре распространения ключей и удовлетворять правилам для определенных пользователем имен участников-служб. Ключевое слово FailoverPartnerSPN указывает имя партнера-службы для сервера-партнера по обеспечению отработки отказа. Ранг учетной записи и ключевые значения Active Directory те же, что и значения, которые можно указать для основного сервера.
Приложение ODBC указывает имя партнера-службы как атрибут соединения для основного сервера или сервера-партнера по обеспечению отработки отказа.	Атрибут соединения SQL_COPT_SS_SERVER_SPN может быть использован для указания имени участника-службы для соединения с основным сервером. Атрибут соединения SQL_COPT_SS_FAILOVER_PARTNER_SPN может быть использован для указания имени партнера-службы для сервера-партнера по обеспечению отработки отказа.
Приложение OLE DB указывает имя партнера-службы как свойство инициализации источника данных для основного сервера или сервера-партнера по обеспечению отработки отказа.	Свойство соединения SSPROP_INIT_SERVER_SPN в наборе свойств DBPROPSET_SQLSERVERDBINIT может быть использовано для указания имени участника-службы для соединения. Свойство соединения SSPROP_INIT_FAILOVER_PARTNER_SPN в DBPROPSET_SQLSERVERDBINIT может быть использовано для указания имени партнера-службы для сервера-партнера по обеспечению отработки отказа.
Пользователь указывает имя партнера-службы для сервера или сервера-партнера по обеспечению отработки отказа в имени источника данных (DSN) ODBC.	Имя участника-службы может быть указано в DSN ODBC через диалоговые окна настройки DSN.
Пользователь указывает имя партнера-службы для сервера или сервера-партнера по обеспечению отработки отказа в диалоговом окне Связь данных или Имя входа OLE DB.	Имя участника-службы может быть указано в диалоговом окне Связь данных или Имя входа . Диалоговое окно Имя входа может использоваться с ODBC или OLE DB.
Приложение ODBC определяет метод проверки подлинности, используемый для установления соединения.	Если соединение было установлено успешно, то приложение может запросить атрибут соединения SQL_COPT_SS_INTEGRATED_AUTHENTICATION_METHOD , чтобы определить, какой именно метод проверки подлинности будет использоваться. Эти значения включают NTLM , Kerberosи другие.
Приложение OLE DB определяет метод проверки подлинности, используемый при установлении соединения.	Если соединение было установлено успешно, то приложение может запросить свойство соединения SSPROP_AUTHENTICATION_METHOD в наборе свойств DBPROPSET_SQLSERVERDATASOURCEINFO для определения метода проверки подлинности, который будет использоваться. Эти значения включают NTLM , Kerberosи другие.

Установка сервера управления

Для установки сервера управления выполните следующие шаги:

1. Добавить учетную запись для сервиса Service Manager (IT\SCSMService – в нашем случае) в группу локальных администраторов на сервере.

2. Запустить программу “setup.exe” из дистрибутива Service Manager.

3. На первом шаге мастера выберите для установки компонент “Service Manager management server”.

4. На следующем шаге мастера установки укажите лицензионный ключ (либо отметьте опцию “Install an evaluation edition”) и, при согласии, укажите, что вы прочитали и согласны с лицензионным соглашением (опция “I have read, understood and agree with terms of license terms”). Нажмите “Next”.

5. На этапе выбора директории установки укажите необходимую директорию и нажмите кнопку “Next”.

6. На этапе проверки предварительных требований мастер установки выполнит проверку наличия всех требуемых компонентов. Если какой-то компонент не установлен, то мастер сообщит об этом. Этот компонент нужно будет установить и нажать кнопку для повторной оценки наличия всех необходимых компонентов. Например, компонент Report Viewer можно установить не закрывая мастер установки. Если все необходимые компоненты установлены, то нажмите кнопку “Next”.

7. На этапе выбора сервера баз данных для размещения баз Service Manager при использовании именованного экземпляра SQL (в нашем случае) укажите имя сервер в следующем формате имя_сервера\имя_экземпляра и нажмите Enter. Мастер установки выполнит поиск экземпляра SQL на сервере баз данных.

При использовании сортировки по умолчанию (SQL_Latin1_General_CP1_CI_AS) может возникнуть следующее предупреждение:

8. После того, как экземпляр SQL будет определен необходимо указать имя, размер и расположение базы данных сервера управления. Можно оставить значения по умолчанию – они вполне корректны. Нажимаем “Next”.

9. На следующем шаге мастера указываем имя группы управления и группу, участники которой будут являться администратором Service Manager. Имя группы управления не должно совпадать с именем группы управления SCOM (если этот продукт у вас развернут). Немного подробнее про выбор имени для группы управления написано

10. На этапе указания сервисной учетной записи укажите запись, которую мы добавляли в группу локальных администраторов на сервере в п. 1 и нажмите кнопку “Test Credential”. В случае успешного прохождения теста нажмите кнопку “Next”.

11. На этапе указания учетной записи для запуска рабочих процессов укажите запись, которую мы создавали на этапе подготовки и нажмите кнопку “Test Credential”. В случае успешного прохождения теста нажмите кнопку “Next”.

12. На следующем этапе мастера нажмите кнопку “Next”. Мастер сообщает вам, что некоторые данные могут отправляться в Microsoft.

13. На этапе настройки параметров обновления мы укажем, что не будем обновлять Service Manager через Windows Update и не будем запускать поиск новых обновлению после завершения установки. Нажмите “Next”.

14. На следующем шаге ознакомьтесь с итоговыми параметрами установки. Если вы считаете, что все указали правильно, то нажмите кнопку “Install”.

15. Дождитесь окончания процесса установки.

После успешного завершения установки сервера управления рекомендуется сделать резервную копию ключей шифрования. Для этого в окне со статусом установки укажите опцию “Open the Encryption Backup or RestoreWizardafter Setup close. You are advised to complete this process to be prepared in event of future disaster recovery needs.”

Запустится мастер резервного копирования ключей шифрования. Выполните следующие шаги:

1. На шаге приветствия нажмите “Next”.

2. На этапе выбора типа работ выберите “Backup the Encryption Key” и нажмите “Next”.

3. На следующем шаге укажите место расположения файла с резервной копией ключей шифрования нажмите “Next”.

4. Далее укажите пароль к файлу с резервной копией ключей шифрования и нажмите кнопку “Next”.

5. После окончания процесса резервного копирования нажмите кнопку “Finish”.

Kerberoasting

Kerberoasting является возможным по двум причинам. Во-первых, DC не занимается авторизацией Клиента, то есть имеет ли право Клиент посещать те или иные сервисы — это не вопрос DC. И поэтому атакующий, имея одну лишь доменную учетную запись, может создать легитимный запрос билета TGS ко всем SPN в домене. Стоит заметить, что атакующего интересуют SPN, ассоциирующиеся с учетными записями пользователей, а не компьютеров, ввиду нецелесообразности восстановления паролей последних. Вторая причина уже озвучивалась выше: билеты TGS шифруются с использованием хеша сервисной учетной записи. Это позволяет атакующему восстановить пароль сервисной учетной записи при условии, что пароль недостаточно стойкий.

Атаку можно разделить на несколько этапов:

Атакующий приступает к аутентификации в домене (AS_req и AS_rep).
Атакующий использует билет TGT для запроса получения билета TGS для конкретного SPN (TGS_req и TGS_rep).
Атакующий извлекает хеш зашифрованного билета TGS из TGS_rep.

Несколько общих фактов об атаке:

легкость в эксплуатации. В сети можно найти огромное количество инструкций, как выполнять перечисление SPN запрос билетов TGS, получение хешей зашифрованных билетов TGS, а также как реализовать все действия разом, к примеру, с помощью модуля Impacket GetUserSPNs.py;
для реализации атакующему достаточно иметь доменную учетную запись с любым уровнем привилегий и сетевой доступ к DC по порту UDP/88;
полученные хеши сервисных учетных записей можно в пассивном режиме подвергнуть перебору.

Атака прочно вошла в арсенал как пентестеров, так и хакеров. Обиженный участник «партнерской программы» вымогателя Conti опубликовал обучающие «гайды» хак-группы, в которых Kerberoasting фигурирует как одна из приоритетных атак. Конкретно в «гайде» написано, что в случае проникновения в крупный домен, именно Kerberoasting целесообразно применять в первую очередь.

Пример реализации атаки с помощью GetUserSPNs.py:

где:

ntpdate – синхронизация времени на машине атакующего с временем на DC. Без данной команды рискуем получить ошибку «KRB_AP_ERR_SKEW(Clock skew too great)»;
10.23.53.26 – IP-адрес DC;
GetUserSPNs.py -request -dc-ip – запуск скрипта с опциями -request и -dc-ip;
TESTDOMAIN.local – имя домена;
testuser1:Testuser! – логин и пароль доменной учетной записи;
> kerberoast.txt – записываем вывод скрипта GetUserSPNs.py в текстовый файл.

Рис.8. Вывод файла kerberoast.txt

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

Описание проблемы

Давайте я подробнее опишу рабочее окружение. И так есть лес Active Directory, в котором есть родительский домен, дочерний и транзитивный отдельный домен в рамках леса. Поступила задача мигрировать и доверительного домена объект компьютера в дочерний домен. Для этого была использована утилита ADMT 3.2. Сама миграция учетной записи компьютера прошла штатно. Далее я сменил принадлежность к домену Active Directory нового компьютера, у меня ввод был успешен, но было предупреждение, что якобы есть проблемы на уровне DNS-сервера. После перезагрузки и попытке на него залогиниться появилась вот такая ошибка:

База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станции

В английской версии, это выглядит вот так:

The security database on the server does not have a computer account for this workstation trust relationship