Поделиться через

Настройка поддержки AD FS для проверки подлинности сертификатов пользователей

В этой статье описывается, как включить проверку подлинности на основе сертификата пользователя в службы федерации Active Directory (AD FS) (AD FS). Он также предоставляет сведения об устранении распространенных проблем с этой проверкой подлинности.

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

  • Пользователи используют смарт-карта для входа в систему AD FS.
  • Пользователи используют сертификаты, подготовленные для мобильных устройств.

Необходимые компоненты

  • Определите режим проверки подлинности сертификата пользователя AD FS, который требуется включить с помощью одного из режимов, описанных в поддержке AD FS для альтернативной привязки имени узла для проверки подлинности сертификата.
  • Убедитесь, что цепочка доверия сертификатов пользователей установлена и доверена всеми серверами AD FS и прокси веб-приложения (WAP), включая все промежуточные центры сертификации. Обычно это можно сделать с помощью объекта групповой политики (GPO) на серверах AD FS и WAP.
  • Убедитесь, что корневой сертификат цепочки доверия для сертификатов пользователей находится в хранилище NTAuth в Active Directory.
  • Если вы используете AD FS в альтернативном режиме проверки подлинности сертификатов, убедитесь, что серверы AD FS и WAP имеют сертификаты SSL, содержащие префикс имени узла AD FS с префиксом certauth. Пример: certauth.fs.contoso.com. Кроме того, убедитесь, что трафик к этому имени узла разрешен через брандмауэр.
  • Если вы используете проверку подлинности сертификатов из экстрасети, убедитесь, что по крайней мере один доступ к данным центра (AIA) и по крайней мере одна точка распространения CRL (CDP) или протокол OCSP из списка, указанного в сертификатах, доступны из Интернета.
  • Если вы настраиваете AD FS для проверки подлинности сертификата Microsoft Entra, убедитесь, что вы настроили параметры Microsoft Entra и правила утверждений AD FS, необходимые для издателя сертификата и серийного номера.
  • Если вы используете проверку подлинности сертификата Microsoft Entra для клиентов Exchange ActiveSync, сертификат клиента должен иметь маршрутизируемый адрес электронной почты пользователя в Exchange Online в значении имени субъекта или значении имени RFC822 в поле "Альтернативное имя субъекта". Идентификатор Microsoft Entra сопоставляет значение RFC822 с атрибутом прокси-адреса в каталоге.

Примечание.

AD FS не поддерживает указания имени пользователя с помощью смарт-карта или проверки подлинности на основе сертификатов.

Включение проверки подлинности сертификата пользователя

Включите проверку подлинности сертификата пользователя в качестве метода проверки подлинности интрасети или экстрасети в AD FS с помощью консоли управления AD FS или командлета Set-AdfsGlobalAuthenticationPolicyPowerShell.

Дополнительные рекомендации включают:

  • Если вы хотите использовать утверждения на основе полей сертификатов и расширений в дополнение к типу утверждения EKU, https://schemas.microsoft.com/2012/12/certificatecontext/extension/ekuнастройте дополнительные правила сквозного утверждения для доверия поставщика утверждений Active Directory. Полный список доступных утверждений сертификатов см. далее в этой статье.

  • Если необходимо ограничить доступ на основе типа сертификата, можно использовать дополнительные свойства сертификата в правилах авторизации выдачи AD FS для приложения. Распространенные сценарии — разрешить только сертификаты, подготовленные поставщиком управления мобильными устройствами (MDM) или разрешать только смарт-сертификаты карта.

    Внимание

    Клиенты, использующие поток кода устройства для проверки подлинности и выполняющие проверку подлинности устройства с помощью поставщика удостоверений, отличного от идентификатора Microsoft Entra (например, AD FS), не могут применять доступ на основе устройств для ресурсов Microsoft Entra. Например, они не могут разрешать только управляемые устройства с помощью сторонней службы MDM.

    Чтобы защитить доступ к корпоративным ресурсам в идентификаторе Microsoft Entra и предотвратить утечку данных, настройте условный доступ на основе устройств Microsoft Entra. Например, используйте параметр "Требовать, чтобы устройство было отмечено жалобой для предоставления контроля в условном доступе Microsoft Entra".

    Настройте разрешенные центры сертификации для сертификатов клиентов с помощью руководства в разделе "Управление доверенными издателями для проверки подлинности клиента" в техническом обзоре Schannel SSP.

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

Настройка простой проверки подлинности сертификатов для браузера Chrome на настольных компьютерах Windows

Если компьютер имеет несколько сертификатов пользователя (например, сертификатов Wi-Fi), которые удовлетворяют целям проверки подлинности клиента, браузер Chrome на настольных компьютерах Windows предложит пользователям выбрать нужный сертификат. Это может быть запутано для пользователей. Чтобы оптимизировать этот интерфейс, вы можете настроить политику для Chrome, чтобы автоматически выбрать правильный сертификат.

Эту политику можно настроить вручную, изменив реестр, или настроить ее автоматически с помощью групповой политики (чтобы задать разделы реестра). Для этого требуется, чтобы сертификаты клиента пользователя для проверки подлинности в AD FS имели разные издатели из других вариантов использования.

Дополнительные сведения о настройке проверки подлинности сертификата для Chrome см . в списке политик Chrome Enterprise.

Устранение неполадок проверки подлинности сертификата

Используйте следующие сведения, чтобы устранить распространенные проблемы при настройке AD FS для проверки подлинности сертификатов для пользователей.

Проверьте правильность настройки доверенных издателей сертификатов на всех серверах AD FS и WAP

Если доверенные издатели сертификатов не настроены должным образом, распространенный симптом — это ошибка HTTP 204: "Содержимое не https://certauth.adfs.contoso.com."выполняется;

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

Чтобы проверить это автоматически, используйте средство анализатора диагностики AD FS. Средство запрашивает все серверы и гарантирует правильность подготовки правильных сертификатов.

  1. Скачайте и запустите средство.
  2. Отправьте результаты и просмотрите все ошибки.

Проверьте, включена ли проверка подлинности сертификата в политике проверки подлинности AD FS

AD FS выполняет проверку подлинности сертификата пользователя по умолчанию на порте 49443 с тем же именем узла, что и AD FS (например: adfs.contoso.com). Вы также можете настроить AD FS для использования порта 443 (порт HTTPS по умолчанию) с помощью альтернативной ssl-привязки. Однако URL-адрес, используемый в этой конфигурации, — certauth.<adfs-farm-name> (например: certauth.contoso.com). Дополнительные сведения см. в статье о поддержке AD FS для альтернативной привязки имени узла для проверки подлинности сертификата.

Примечание.

В AD FS в Windows Server 2016 теперь поддерживаются два режима. Первый режим использует узел adfs.contoso.com с портами 443 и 49443. Второй режим использует узлы adfs.contoso.com и certauth.adfs.contoso.com порт 443. Требуется SSL-сертификат для поддержки certauth.\<adfs-service-name> в качестве альтернативного имени субъекта. Это можно сделать во время создания фермы или более поздней версии с помощью PowerShell.

Наиболее распространенный случай проблем с сетевым подключением заключается в том, что брандмауэр был неправильно настроен и блокирует трафик для проверки подлинности сертификата пользователя. Обычно при возникновении этой проблемы отображается пустой экран или ошибка сервера 500. Чтобы устранить эту проблему, выполните следующие действия.

  1. Обратите внимание на имя узла и порт, настроенный в AD FS.
  2. Убедитесь, что любой брандмауэр перед AD FS или WAP настроен, чтобы разрешить hostname:port сочетание для фермы AD FS. Сетевой инженер должен выполнить этот шаг.

Проверка подключения CRL

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

Каждый сервер AD FS и WAP должен получить доступ к конечной точке списка отзыва сертификатов, чтобы проверить, является ли сертификат, представленный им, по-прежнему действительным и не был отменен. Проверка списка отзыва сертификатов может выполняться по протоколу HTTPS, HTTP, LDAP или OCSP. Если серверы AD FS и WAP не могут достичь конечной точки, проверка подлинности завершится ошибкой. Чтобы устранить неполадки, выполните следующие действия.

  1. Обратитесь к инженеру инфраструктуры открытых ключей (PKI), чтобы определить, какие конечные точки CRL используются для отзыва сертификатов пользователей из системы PKI.
  2. На каждом сервере AD FS и WAP убедитесь, что конечные точки CRL доступны через используемый протокол (обычно HTTPS или HTTP).
  3. Для расширенной проверки включите ведение журнала событий CAPI2 на каждом сервере AD FS и WAP.
  4. Проверьте идентификатор события 41 (проверка отзыва) в операционных журналах CAPI2.
  5. Проверьте наличие <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Совет

Для упрощения устранения неполадок можно использовать один сервер AD FS или WAP, настроив разрешение DNS (файл узлов в Windows), чтобы указать на определенный сервер. Этот метод позволяет включить трассировку, нацелив сервер.

Проверка проблем SNI

AD FS требует клиентских устройств (или браузеров) и подсистемы балансировки нагрузки для поддержки указания имени сервера (SNI). Некоторые клиентские устройства (например, старые версии Android) могут не поддерживать SNI. Кроме того, подсистемы балансировки нагрузки могут не поддерживать SNI или не настроены для SNI. В этих случаях, скорее всего, вы получите сбои сертификации пользователей.

Чтобы устранить эту проблему, обратитесь к сетевому инженеру, чтобы убедиться, что подсистема балансировки нагрузки для AD FS и WAP поддерживает SNI. Если SNI не поддерживается, используйте следующее обходное решение в AD FS:

  1. Откройте окно командной строки с повышенными привилегиями на основном сервере AD FS.
  2. Введите Netsh http show sslcert.
  3. Скопируйте идентификатор GUID приложения и хэш сертификата службы федерации.
  4. Введите netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}.

Проверка правильности подготовки клиентского устройства с помощью сертификата

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

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

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

  2. Экспортируйте сертификат пользователя клиента в файл .cer и выполните команду certutil -f -urlfetch -verify certificatefilename.cer.

Проверьте, совместима ли версия TLS между серверами AD FS/WAP и клиентским устройством.

В редких случаях клиентское устройство обновляется для поддержки только более поздней версии TLS (например, 1.3). Или у вас может возникнуть обратная проблема, при которой серверы AD FS и WAP были обновлены, чтобы использовать только более высокую версию TLS, которую клиентское устройство не поддерживает.

Вы можете использовать онлайн-средства SSL для проверка серверов AD FS и WAP и узнать, совместимы ли они с устройством. Дополнительные сведения об управлении версиями TLS см. в разделе "Управление протоколами SSL/TLS" и наборами шифров для AD FS.

Проверьте правильность настройки Microsoft Entra PromptLoginBehavior в параметрах федеративного домена.

Многие приложения Office 365 отправляются prompt=login в идентификатор Microsoft Entra. Идентификатор Microsoft Entra по умолчанию преобразует его в новое имя входа паролей в AD FS. В результате, даже если вы настроили проверку подлинности сертификата в AD FS, пользователи видят только имя входа в пароль. Чтобы устранить эту проблему, выполните следующие действия.

  1. Получите параметры федеративного домена с помощью командлета Get-MgDomainFederationConfiguration .
  2. Убедитесь, что PromptLoginBehavior для параметра задано значение Disabled или NativeSupport.

Дополнительные сведения см. в статье AD FS prompt=login parameter support.

Дополнительные сведения об устранении неполадок

В редких случаях, если списки списков отзыва сертификатов очень длинные, они могут получить время ожидания при попытке скачивания. В этом случае необходимо обновить MaxFieldLength и MaxRequestByte , как описано в параметрах реестра Http.sys для Windows.

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

Тип утверждения Пример значения
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4