Вопрос или проблема
В мае 2022 года Microsoft изменила способ сопоставления клиентских сертификатов с учетными записями AD, что привело к сбою аутентификации компьютеров с использованием 802.1X EAP-TLS.
Вот дополнительный ресурс с подробной информацией о аутентификации Schannel<=>Kerberos S4U2Self
Доступные решения для этого были:
- Создать надежные сопоставления, используя altSecurityIdentities
- Использовать новое расширение сертификата szOID_NTDS_CA_SECURITY_EXT
- Временно отключить Schannel<=>Kerberos S4u2Self через ключ реестра CertificateMappingMethods и установить флаг 0x4 для сопоставления сертификатов SAN
Это все работает хорошо, если сервер NPS и учетная запись компьютера клиента находятся в одном домене.
Однако в нашем сценарии сервер NPS находится в корневом домене леса, а учетная запись компьютера клиента — в подсети.
Это приводит к тому, что учетные записи компьютеров во всех подсетях не могут пройти аутентификацию с кодом причины 16, с событиями 4625 и 6273, зарегистрированными на сервере NPS.
Учетные записи компьютеров, которые находятся в корневом домене (например, сервер NPS), могут успешно пройти аутентификацию
Проблема, похоже, заключается где-то между аутентификацией Schannel и Kerberos:
- Установка ключа CertificateMappingMethods на всех контроллерах подсети и сервере NPS в 0x1F делает аутентификацию рабочей (к сожалению, это только временное решение)
- Создание надежных сопоставлений с использованием altSecurityIdentities не дает эффекта; на контроллере домена не регистрируются события; ошибка на сервере NPS не изменяется; невидимой разницы нет
- Использование нового расширения сертификата szOID_NTDS_CA_SECURITY_EXT не дает эффекта; аутентификация по-прежнему не проходит
Ошибки, зарегистрированные на сервере RADIUS, следующие:
Событие 4625
Учетная запись не смогла войти в систему.
Субъект:
Идентификатор безопасности: SYSTEM
Имя учетной записи: <СЕРВЕР NPS>$
Домен учетной записи: <ДОМЕН СЕРВЕРА NPS>
Идентификатор входа: 0x3E7
Тип входа: 3
Учетная запись, для которой вход не удался:
Идентификатор безопасности: NULL SID
Имя учетной записи:
Домен учетной записи:
Информация о сбое:
Причина сбоя: Неизвестное имя пользователя или неверный пароль.
Статус: 0xC000006D
Подстатус: 0xC0000064
Информация о процессе:
Идентификатор вызывающего процесса: 0x278
Имя вызывающего процесса: C:\Windows\System32\lsass.exe
Сетевое Идентификация:
Имя рабочей станции: <СЕРВЕР NPS>
Исходный сетевой адрес: -
Исходный порт: -
Подробная информация об аутентификации:
Процесс входа: Schannel
Пакет аутентификации: Kerberos
Пересекаемые службы: -
Имя пакета (только NTLM): -
Длина ключа: 0
Это событие генерируется, когда запрашивается вход, но он не удался. Оно генерируется на компьютере, на котором была предпринята попытка доступа.
Поля субъекта указывают на учетную запись на локальной системе, которая запросила вход. Обычно это служба, такая как служба сервера, или локальный процесс, такой как Winlogon.exe или Services.exe.
Поле типа входа указывает на тип входа, который был запрошен. Наиболее распространенные типы - 2 (интерактивный) и 3 (сетевой).
Поля информации о процессе указывают, какой учетной записи и процессу на системе был запрошен вход.
Поля сетевой информации указывают, откуда поступил удаленный запрос на вход. Имя рабочей станции не всегда доступно и может быть оставлено пустым в некоторых случаях.
Поля информации об аутентификации предоставляют подробную информацию об этом конкретном запросе на вход.
- Пересекаемые службы указывают, какие промежуточные службы принимали участие в этом запросе входа.
- Имя пакета указывает, какой подсprotocol был использован среди NTLM-протоколов.
- Длина ключа указывает длину сгенерированного сеансового ключа. Это будет 0, если сеансовый ключ не был запрошен.
Событие 6273
Сервер сетевой политики отказал в доступе пользователю.
Свяжитесь с администратором сервера сетевой политики для получения дополнительной информации.
Пользователь:
Идентификатор безопасности: <ДОМЕН КЛИЕНТА>\<УЧЕТНАЯ ЗАПИСЬ КОМПЬЮТЕРА>$
Имя учетной записи: host/<dns клиента>
Домен учетной записи: <ДОМЕН КЛИЕНТА>
Полное имя учетной записи: <ДОМЕН КЛИЕНТА>\<УЧЕТНАЯ ЗАПИСЬ КОМПЬЮТЕРА>$
Клиентский компьютер:
Идентификатор безопасности: NULL SID
Имя учетной записи: -
Полное имя учетной записи: -
Идентификатор вызывающей станции: 6E-22-32-2F-19-CF:<SSID>
Идентификатор вызывающей станции: 84-38-38-86-82-C2
NAS:
NAS IPv4-адрес: <ip AP>
NAS IPv6-адрес: -
Идентификатор NAS: 6e22322f09cf
Тип порта NAS: Беспроводной - IEEE 802.11
Порт NAS: 1
Клиент RADIUS:
Дружественное имя клиента: <имя AP>
IP-адрес клиента: <ip AP>
Детали аутентификации:
Имя политики запроса на подключение: Защищенные беспроводные подключения
Имя сети: Защищенные беспроводные подключения
Провайдер аутентификации: Windows
Сервер аутентификации: <Полное доменное имя контроллера домена>
Тип аутентификации: EAP
Тип EAP: Microsoft: смарт-карта или другой сертификат
Идентификатор сеанса учетной записи: 43323444383435463834444530463634
Результаты ведения журнала: Информация учета была записана в хранилище данных SQL.
Код причины: 16
Причина: Аутентификация не удалась из-за несовпадения учетных данных пользователя. Либо предоставленное имя пользователя не соответствует существующей учетной записи, либо пароль был неверным.
Похоже, что сервер NPS каким-то образом не может получить билет Kerberos для подсети; но я не уверен.
Итак, подводя итог: Аутентификация работает, если только клиент не находится в двухсторонне доверенной подсети того же леса, что и сервер NPS (или в родственном домене).
Какие параметры конфигурации у нас отсутствуют??
Было то же самое:
Выяснилось, что нужно было заставить серверы NPS использовать TSL 1.2 согласно этому:
https://warlord0blog.wordpress.com/2017/02/09/tls-and-nps/
https://support.microsoft.com/en-us/topic/microsoft-security-advisory-update-for-microsoft-eap-implementation-that-enables-the-use-of-tls-october-14-2014-d9ba4b83-b4e9-2c01-83a7-e42706e671af
Иначе клиенты Win 11 22H2 с обновлением декабря 2022 года не смогли бы подключиться
Ответ или решение
Проблема обновления сертификатов Windows NPS в мае 2022 года: причины и решения
В мае 2022 года Microsoft внесла изменения в способ, которым клиентские сертификаты сопоставляются с учетными записями Active Directory, что привело к неуспешной аутентификации компьютерных учетных записей при использовании 802.1X EAP-TLS. В частности, такая проблема возникла, когда сервер NPS (Network Policy Server) находится в корневом домене леса, а клиентская учетная запись компьютера располагается в подсети этого леса.
Контекст проблемы
Проблема начала проявляться после обновления, определяющего способ обработки сертификатов. Согласно описанию:
- Аутентификация работает, если сервер NPS и клиентские учетные записи находятся в одном домене.
- При расположении сервера NPS в корневом домене и клиентской учетной записи в поддомене, аутентификация завершается неудачей с кодом причины 16, и в журнале событий NPS отображаются записи 4625 и 6273.
Ошибки, возникающие на сервере RADIUS
- Событие 4625: Учетная запись не смогла выполнить вход.
- Событие 6273: Сервер сетевой политики отказал в доступе пользователю.
Возможные решения
Несмотря на различные подходы к устранению неполадки, набор действий, приведённых ниже, оказался весьма полезным:
-
Создание сильных сопоставлений с использованием altSecurityIdentities: Это решение не дало желаемых результатов. Отсутствие логирования событий на контроллерах домена также свидетельствует о его неэффективности.
-
Использование нового расширения сертификатов szOID_NTDS_CA_SECURITY_EXT: К сожалению, аутентификация продолжала завершаться неудачей.
-
Темпоральное отключение Schannel <=> Kerberos S4u2Self: Обстановка улучшилась только при установлении параметра
CertificateMappingMethodsна все контроллеры поддомена и сервер NPS на 0x1F, что оказалось ненадежным временным решением. -
Добавление сервера NPS в группу "RAS и IAS Servers" в поддомене. Этот шаг также не привел к ожидаемым результатам.
Дополнительные рекомендации
Необходимо также обратить внимание на настройки протокола TLS. Обновления системы Windows, такие как версия November 2022 для Windows 11, могут требовать поддержки TLS 1.2 для корректной работы аутентификации:
- Проверьте, что протокол TLS 1.2 активирован на сервере NPS.
Тем не менее, внедрение TLS 1.2 уже в некоторой степени решает структуру запросов и повышает их безопасность.
Заключение
Проблема с аутентификацией на уровне двухсторонних доверенных поддоменов, возникшая после обновления Windows NPS, требует всестороннего анализа и настройки нескольких элементов инфраструктуры. Рекомендуется уделять внимание совместимости протоколов передачи данных, настройки сопоставления сертификатов, а также изменениям в системных настройках безопасности. Все эти аспекты необходимо тщательно протестировать для обеспечения устойчивости и надежности систем аутентификации в вашем окружении.
Если указанные решения не решают проблему, рекомендуется обратиться к профессионалам в области ИТ-безопасности для проведения углубленного аудита конфигурации вашей системы и устранения возможных недоработок.