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

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

В этой статье описывается, как включить проверку подлинности сертификата пользователя в службах федерации Active Directory (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 в значении Principal Name или RFC822 Name значения поля альтернативного имени субъекта . Идентификатор Microsoft Entra сопоставляет значение RFC822 с атрибутом прокси-адреса в каталоге.

Заметка

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

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

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

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

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

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

    Важный

    Клиенты, использующие поток кода устройства для аутентификации и выполняющие проверку подлинности устройства с помощью поставщика удостоверений, отличного от Microsoft Entra ID (например, 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. Для поддержки certauth.\<adfs-service-name> в качестве альтернативного имени субъекта требуется SSL-сертификат. Это можно сделать во время создания фермы или позже с помощью PowerShell.

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

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

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

Списки отзыва сертификатов (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_applicationGUID}.

Проверьте, правильно ли клиентское устройство получило сертификат.

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

  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