Сертификаты безопасности Windows не соответствуют критериям

Обновлено: 21.11.2024

В этой статье описываются требования, которым должны соответствовать ваши клиентские сертификаты и сертификаты сервера при использовании Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) или Protected Extensible Authentication Protocol (PEAP) с EAP-TLS.

Дополнительная информация

При использовании EAP со строгим типом EAP, например TLS со смарт-картами или TLS с сертификатами, и клиент, и сервер используют сертификаты для подтверждения своей подлинности друг перед другом. Для успешной аутентификации сертификаты должны соответствовать определенным требованиям как на сервере, так и на клиенте.

Одним из требований является то, что сертификат должен быть настроен для одной или нескольких целей в расширениях расширенного использования ключа (EKU), которые соответствуют использованию сертификата. Например, сертификат, который используется для проверки подлинности клиента на сервере, должен быть настроен с целью проверки подлинности клиента. Или сертификат, который используется для проверки подлинности сервера, должен быть настроен с целью проверки подлинности сервера. Когда сертификаты используются для проверки подлинности, средство проверки подлинности проверяет сертификат клиента и ищет правильный идентификатор целевого объекта в расширениях EKU. Например, идентификатор объекта для проверки подлинности клиента: 1.3.6.1.5.5.7.3.2.

Минимальные требования к сертификату

Все сертификаты, используемые для проверки подлинности доступа к сети, должны соответствовать требованиям для сертификатов X.509, а также требованиям для соединений, использующих шифрование Secure Sockets Layer (SSL) и шифрование Transport Level Security (TLS). После выполнения этих минимальных требований сертификаты клиента и сертификаты сервера должны соответствовать следующим дополнительным требованиям.

Требования к сертификату клиента

При использовании EAP-TLS или PEAP с EAP-TLS сервер принимает аутентификацию клиента, если сертификат соответствует следующим требованиям:

Сертификат клиента выдается центром сертификации предприятия (ЦС) или сопоставляется с учетной записью пользователя или учетной записью компьютера в службе каталогов Active Directory.

Сертификат пользователя или компьютера на клиенте привязывается к доверенному корневому ЦС.

Сертификат пользователя или компьютера на клиенте включает цель проверки подлинности клиента.

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

Сертификат пользователя или компьютера не проходит ни одну из проверок идентификатора объекта сертификата, указанных в политике удаленного доступа службы проверки подлинности в Интернете (IAS).

Клиент 802.1x не использует сертификаты на основе реестра, которые являются либо сертификатами смарт-карт, либо сертификатами, защищенными паролем.

Расширение альтернативного имени субъекта (SubjectAltName) в сертификате содержит основное имя пользователя (UPN) пользователя.

Когда клиенты используют EAP-TLS или PEAP с проверкой подлинности EAP-TLS, в оснастке "Сертификаты" отображается список всех установленных сертификатов со следующими исключениями:

Беспроводные клиенты не отображают сертификаты на основе реестра и сертификаты входа в систему с помощью смарт-карты.

Беспроводные клиенты и клиенты виртуальной частной сети (VPN) не отображают сертификаты, защищенные паролем.

Сертификаты, не содержащие цель Аутентификация клиента в расширениях EKU, не отображаются.

Требования к сертификату сервера

Вы можете настроить клиентов для проверки сертификатов сервера, используя параметр Проверить сертификат сервера на вкладке Аутентификация в свойствах сетевого подключения. Когда клиент использует аутентификацию версии 2 протокола аутентификации рукопожатия (CHAP) PEAP-EAP-MS-Challenge, PEAP с аутентификацией EAP-TLS или аутентификацию EAP-TLS, клиент принимает сертификат сервера, если сертификат соответствует следующим требованиям:

Сертификат компьютера на сервере связан с одним из следующих:

Доверенный корневой ЦС Microsoft.

Автономный корневой ЦС Microsoft или сторонний корневой ЦС в домене Active Directory с хранилищем NTAuthCertificates, содержащим опубликованный корневой сертификат. Чтобы получить дополнительные сведения об импорте сертификатов ЦС сторонних производителей, щелкните следующий номер статьи для просмотра статьи в базе знаний Майкрософт:

295663 Как импортировать сертификаты сторонних центров сертификации (ЦС) в хранилище Enterprise NTAuth

Сертификат компьютера IAS или VPN-сервера настроен для проверки подлинности сервера. Идентификатор объекта для проверки подлинности сервера — 1.3.6.1.5.5.7.3.1.

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

Имя в строке «Тема» сертификата сервера совпадает с именем, настроенным на клиенте для подключения.

Для беспроводных клиентов расширение альтернативного имени субъекта (SubjectAltName) содержит полное доменное имя сервера (FQDN).

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

Примечание. При использовании аутентификации PEAP или EAP-TLS серверы отображают список всех установленных сертификатов в оснастке «Сертификаты». Однако сертификаты, содержащие цель проверки подлинности сервера в расширениях EKU, не отображаются.

Ссылки

Для получения дополнительных сведений о технологиях беспроводной сети посетите следующий веб-сайт Microsoft:

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

5 ответов

Спасибо за публикацию здесь.

Я провел тест в своей лаборатории.

Настройте шаблон сертификата "Агент регистрации".

1. Дублируйте шаблон сертификата "Агент регистрации" и предоставьте группе "пользователей домена" разрешения "Чтение" и "Зачисление".

Отображаемое имя шаблона сертификата — Enrollment Agent-1.

2.Выдайте этот шаблон сертификата.

Daisy 11 запрашивает сертификат, используя шаблон сертификата с именем "Enrollment Agent-1".

3. Войдите в систему одного клиента, используя доменного пользователя с именем daisy11.

4.Запросите сертификат, используя шаблон сертификата с именем "Enrollment Agent-1" в пользовательском хранилище.

Daisy11 может запросить сертификат от имени другого пользователя.

5.После этого Daisy11 может запросить сертификат от имени другого пользователя (Б\ю).

Поскольку daisy11 имеет два сертификата, выданных шаблоном сертификата "Enrollment Agent", мне будет предложено выбрать один.

6.Выберите один шаблон сертификата для пользователя домена (Б\ю).

7.Выберите имя пользователя(Б\ю).

8.Daisy11 теперь запросит сертификат для Б\ю успешно.

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

3. Найдите, какой пользователь уже запросил сертификат агента регистрации, используя шаблон сертификата агента регистрации. Вы можете использовать учетную запись пользователя с сертификатом Enrollment Agent в его/ее Личном хранилище для запроса сертификатов от имени других пользователей.

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

Если у вас возникнут какие-либо вопросы или проблемы, сообщите нам об этом.

С уважением,
Дейзи Чжоу

===========================================
Если ответ полезен, нажмите "Принять ответ" и проголосуйте за него.

Описывает рекомендации, расположение, значения и соображения безопасности для параметра политики безопасности "Пароль должен соответствовать требованиям сложности".

Ссылка

Настройка политики «Пароли должны соответствовать требованиям сложности» определяет, должны ли пароли соответствовать ряду рекомендаций относительно надежных паролей. Если этот параметр включен, пароли должны соответствовать следующим требованиям:

Пароли не могут содержать значение samAccountName пользователя (имя учетной записи) или полностью displayName (значение полного имени). Обе проверки не чувствительны к регистру.

Имя samAccountName проверяется полностью только для того, чтобы определить, является ли оно частью пароля. Если длина samAccountName меньше трех символов, эта проверка пропускается. DisplayName анализируется на наличие разделителей: запятых, точек, тире или дефисов, подчеркивания, пробелов, знаков фунта и табуляции. Если какой-либо из этих разделителей найден, displayName разделяется, и подтверждается, что все проанализированные разделы (токены) не включены в пароль. Токены короче трех символов игнорируются, а подстроки токенов не проверяются. Например, имя «Эрин М. Хагенс» разделено на три токена: «Эрин», «М» и «Хагенс». Поскольку второй токен имеет длину всего один символ, он игнорируется. Таким образом, у этого пользователя не может быть пароля, включающего "erin" или "hagens" в качестве подстроки в любом месте пароля.

Пароль содержит символы трех из следующих категорий:

Требования к сложности применяются при изменении или создании паролей.

Правила, включенные в требования к сложности пароля Windows Server, являются частью Passfilt.dll, и их нельзя изменить напрямую.

Если эта функция включена, Passfilt.dll по умолчанию может вызвать дополнительные обращения в службу поддержки по поводу заблокированных учетных записей, поскольку пользователи привыкли к паролям, содержащим только символы алфавита. Но этот параметр политики достаточно либерален, и все пользователи должны к нему привыкнуть.

Дополнительные параметры, которые можно включить в пользовательскую версию Passfilt.dll, включают использование символов не из верхнего ряда. Чтобы ввести символы верхнего ряда, удерживайте клавишу SHIFT и нажимайте одну из любых клавиш в числовом ряду клавиатуры (от 1 до 9 и 0).

Возможные значения

  • Включено
  • Отключено
  • Не определено

Рекомендации

Новые рекомендации см. в разделе Руководство по паролю.

Установка паролей должна соответствовать требованиям сложности для включения. Этот параметр политики в сочетании с минимальной длиной пароля 8 гарантирует наличие не менее 159 238 157 238 528 различных вариантов для одного пароля. Этот параметр делает атаку грубой силы затруднительной, но все же не невозможной.

Использование комбинаций символов клавиши ALT может значительно повысить сложность пароля. Однако требование ко всем пользователям в организации придерживаться таких строгих требований к паролям может привести к недовольству пользователей и перегруженности службы поддержки. Рассмотрите возможность внедрения в вашей организации требования использовать символы ALT в диапазоне от 0128 до 0159 как часть всех паролей администратора. (Символы ALT за пределами этого диапазона могут представлять собой стандартные буквенно-цифровые символы, которые не усложняют пароль.)

Короткие пароли, содержащие только буквенно-цифровые символы, легко взломать с помощью общедоступных инструментов. Чтобы этого не произошло, пароли должны содержать дополнительные символы и/или соответствовать требованиям сложности.

Местоположение

Конфигурация компьютера\Параметры Windows\Параметры безопасности\Политики учетных записей\Политика паролей

Значения по умолчанию

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

< td>Настройки по умолчанию для автономного сервера
Тип сервера или объект групповой политики (GPO) Значение по умолчанию
Политика домена по умолчанию Включено
Политика контроллера домена по умолчанию Включено
Отключено
Действующие настройки контроллера домена по умолчанию Включено
Действующие настройки рядового сервера по умолчанию Включено
Действующие настройки GPO по умолчанию на клиентских компьютерах Отключено< /td>

Соображения безопасности

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

Уязвимость

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

Контрмеры

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

В сочетании с минимальной длиной пароля, равной 8, этот параметр политики гарантирует, что число различных возможностей для одного пароля настолько велико, что успешная атака полным перебором затруднена (но возможна). (Если увеличить параметр политики Минимальная длина пароля, среднее время, необходимое для успешной атаки, также увеличится.)

Потенциальное влияние

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

Если в вашей организации предъявляются более строгие требования к безопасности, вы можете создать пользовательскую версию файла Passfilt.dll, которая позволяет использовать произвольно сложные правила надежности пароля. Например, для пользовательского фильтра паролей может потребоваться использование символов не в верхней строке. (Символы верхнего ряда — это символы, которые требуют нажатия и удерживания клавиши SHIFT, а затем нажатия любой клавиши в числовом ряду клавиатуры, от 1 до 9 и 0.) Пользовательский фильтр паролей также может выполнять словарь. проверьте, чтобы предлагаемый пароль не содержал общих словарных слов или фрагментов.

Использование комбинаций символов клавиши ALT может значительно повысить сложность пароля. Однако такие строгие требования к паролю могут привести к увеличению количества запросов в службу поддержки. В качестве альтернативы ваша организация может рассмотреть требование, чтобы все пароли администраторов использовали символы ALT в диапазоне 0128–0159. (Символы ALT за пределами этого диапазона могут представлять собой стандартные буквенно-цифровые символы, которые не усложняют пароль.)

Чтобы Credential Guard в Защитнике Windows обеспечивал защиту, компьютеры, которые вы защищаете, должны соответствовать определенным базовым требованиям к оборудованию, микропрограмме и программному обеспечению, которые мы будем называть Требованиями к оборудованию и программному обеспечению. Кроме того, Credential Guard в Защитнике Windows блокирует определенные возможности проверки подлинности, поэтому приложения, которым требуются такие возможности, не будут работать. Мы будем называть эти требования требованиями приложения. Помимо этих требований, компьютеры могут соответствовать дополнительным требованиям к аппаратному и микропрограммному обеспечению и получать дополнительную защиту. Эти компьютеры будут более защищены от определенных угроз. Подробную информацию о базовых средствах защиты, а также средствах повышения безопасности, связанных с вариантами аппаратного и микропрограммного обеспечения, доступными в 2015, 2016 и 2017 годах, см. в таблицах в разделе Вопросы безопасности.

Требования к оборудованию и программному обеспечению

Чтобы обеспечить базовую защиту от попыток чтения учетных данных домена Credential Manager на уровне ОС, учетных данных, полученных от NTLM и Kerberos, Credential Guard в Защитнике Windows использует:

  • Поддержка безопасности на основе виртуализации (обязательно)
  • Безопасная загрузка (обязательно)
  • Поддерживается доверенный платформенный модуль (TPM, предпочтительнее — обеспечивает привязку к оборудованию) версий 1.2 и 2.0, дискретный или микропрограммный.
  • Блокировка UEFI (предпочтительнее — предотвращает отключение злоумышленника простым изменением ключа реестра)

Для обеспечения безопасности на основе виртуализации требуется:

  • 64-разрядный процессор
  • Расширения виртуализации ЦП и расширенные таблицы страниц.
  • Гипервизор Windows (не требует установки компонента Windows Hyper-V)

Развертывание Credential Guard в Защитнике Windows на виртуальных машинах

Credential Guard может защищать секреты на виртуальной машине Hyper-V точно так же, как на физической машине. Когда Credential Guard развернут на виртуальной машине, секреты защищены от атак внутри виртуальной машины. Credential Guard не обеспечивает дополнительную защиту от атак на привилегированную систему, исходящих с хоста.

Требования для запуска Credential Guard в Защитнике Windows на виртуальных машинах Hyper-V

  • Хост Hyper-V должен иметь IOMMU и работать под управлением как минимум Windows Server 2016 или Windows 10 версии 1607.
  • Виртуальная машина Hyper-V должна быть поколения 2, иметь включенный виртуальный доверенный платформенный модуль и работать под управлением как минимум Windows Server 2016 или Windows 10.
    • TPM не является обязательным требованием, но мы рекомендуем вам внедрить TPM.

    Сведения о требованиях к оборудованию и программному обеспечению Remote Credential Guard в Защитнике Windows см. в разделе Требования к Remote Credential Guard в Защитнике Windows.

    Требования к заявке

    При включении Credential Guard в Защитнике Windows определенные возможности проверки подлинности блокируются, поэтому приложения, требующие таких возможностей, не будут работать. Приложения следует тестировать перед развертыванием, чтобы обеспечить совместимость с ограниченной функциональностью.

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

    Credential Guard в Защитнике Windows не обеспечивает защиту базы данных Active Directory или диспетчера учетных записей безопасности (SAM).Учетные данные, защищенные с помощью Kerberos и NTLM, когда включен Credential Guard в Защитнике Windows, также находятся в базе данных Active Directory (на контроллерах домена) и SAM (для локальных учетных записей).

    • Поддержка шифрования Kerberos DES
    • Неограниченное делегирование Kerberos
    • Извлечение Kerberos TGT
    • NTLMv1
    • Дайджест-аутентификация
    • Делегирование учетных данных
    • MS-CHAPv2

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

    Службы или протоколы, использующие Kerberos, такие как общие файловые ресурсы, удаленный рабочий стол или BranchCache, продолжают работать и не затрагиваются Credential Guard в Защитнике Windows.

    Соображения безопасности

    Все компьютеры, соответствующие базовым требованиям защиты оборудования, микропрограмм и программного обеспечения, могут использовать Credential Guard в Защитнике Windows. Компьютеры, отвечающие дополнительным требованиям, могут обеспечить дополнительную защиту для дальнейшего уменьшения поверхности атаки. В следующих таблицах описаны базовые средства защиты, а также средства для повышения безопасности, связанные с вариантами аппаратного и микропрограммного обеспечения, доступными в 2015, 2016 и 2017 годах.

    Начиная с Windows 10 версии 1607 доверенный платформенный модуль (TPM 2.0) должен быть включен по умолчанию на новых поставляемых компьютерах.

    Базовые средства защиты

    Windows Server 2016, работающий в качестве контроллера домена, не поддерживает Credential Guard в Защитнике Windows.

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

    2015 Дополнительные требования безопасности, начиная с Windows 10 версии 1507 и Windows Server 2016 Technical Preview 4

    2016 Дополнительные требования безопасности, начиная с Windows 10 версии 1607 и Windows Server 2016

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

    2017 Дополнительные требования безопасности, начиная с Windows 10 версии 1703

    В следующей таблице перечислены требования для Windows 10 версии 1703, которые дополняют все предыдущие требования.

    Что касается включения VBS защиты NX для служб среды выполнения UEFI:

    Это относится только к памяти службы времени выполнения UEFI, а не к памяти службы загрузки UEFI.

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