Новые возможности проверки подлинности Kerberos

  • Статья

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016 и Windows 10

Поддержка KDC для проверки подлинности клиента на основе открытого ключа

Начиная с Windows Server 2016, KDCs поддерживают способ сопоставления открытых ключей. Если открытый ключ подготовлен для учетной записи, KDC поддерживает Kerberos PKInit явно с помощью этого ключа. Так как проверка сертификатов отсутствует, самозаверяющий сертификат поддерживается, а проверка механизма проверки подлинности не поддерживается.

Доверие ключей предпочтительно при настройке учетной записи независимо от параметра UseSubjectAltName.

Поддержка клиента Kerberos и KDC для расширения PKInit Freshness RFC 8070

Начиная с Windows 10 версии 1607 и Windows Server 2016 клиенты Kerberos попытаются использовать расширение 8070 PKInit для входа на основе открытого ключа.

Начиная с Windows Server 2016, KDCs могут поддерживать расширение свежести PKInit. По умолчанию KDCs не предлагают расширение свежести PKInit. Чтобы включить его, используйте новую поддержку KDC для политики административных шаблонов расширения KDC PKInit Freshness на всех контроллерах домена. При настройке следующие параметры поддерживаются, если домен является функциональным уровнем домена Windows Server 2016 (DFL):

  • Отключен: KDC никогда не предлагает расширение PKInit Freshness и принимает допустимые запросы проверки подлинности без проверка для свежести. Пользователи никогда не получат идентификатор идентификатора нового открытого ключа.
  • Поддерживается: расширение PKInit Freshness поддерживается по запросу. Клиенты Kerberos успешно проходят проверку подлинности с помощью расширения PKInit Freshness, получают идентификатор идентификатора нового открытого ключа.
  • Обязательный: для успешной проверки подлинности требуется расширение PKInit Freshness. Клиенты Kerberos, не поддерживающие расширение PKInit Freshness, всегда завершаются ошибкой при использовании учетных данных открытого ключа.

Поддержка устройства, присоединенного к домену, для проверки подлинности с помощью открытого ключа

Начиная с Windows 10 версии 1507 и Windows Server 2016, если присоединенное к домену устройство может зарегистрировать связанный открытый ключ с контроллером домена Windows Server 2016 (DC), устройство может пройти проверку подлинности с помощью открытого ключа с помощью проверки подлинности Kerberos на контроллере домена Windows Server 2016. Дополнительные сведения см. в разделе "Проверка подлинности открытого ключа устройства, присоединенного к домену"

Клиенты Kerberos разрешают имена узлов адресов IPv4 и IPv6 в именах субъектов-служб (SPN)

Начиная с Windows 10 версии 1507 и Windows Server 2016 клиенты Kerberos можно настроить для поддержки имен узлов IPv4 и IPv6 в именах субъектов-служб.

Путь к реестру:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Чтобы настроить поддержку имен узлов IP-адресов в именах субъектов-служб, создайте запись TryIPSPN. Эта запись не существует в реестре по умолчанию. После создания записи измените значение DWORD на 1. Если это не настроено, имена узлов IP-адресов не выполняются.

Если имя субъекта-службы зарегистрировано в Active Directory, проверка подлинности завершается с помощью Kerberos.

Дополнительные сведения проверка документе Настройка Kerberos для IP-адресов.

Поддержка KDC для сопоставления учетных записей доверия ключей

Начиная с Windows Server 2016 контроллеры домена поддерживают сопоставление учетных записей доверия ключей, а также резервное копирование на существующий AltSecID и имя участника-пользователя (UPN) в поведении SAN. Если параметр UseSubjectAltName имеет значение:

  • 0. Требуется явное сопоставление. Затем должно быть следующее:
    • Доверие ключей (новое с Windows Server 2016)
    • ЯвныйAltSecID
  • 1. Неявное сопоставление разрешено (по умолчанию):
    1. Если для учетной записи настроено доверие ключей, она используется для сопоставления (новая с Windows Server 2016).
    2. Если в SAN нет имени участника-пользователя, то altSecID пытается сопоставить.
    3. Если в san есть имя участника-пользователя, попытка имени участника-пользователя выполняется для сопоставления.

См. также