KB5014754: Промени в удостоверяването, базирано на сертификат, на домейнови контролери на Windows

Не са намерени силни съпоставяния на сертификати и сертификатът няма ново разширение на идентификатора за защита (SID), което KDC може да провери.

Регистър на събитията	Система
Тип събитие	Предупреждение, ако KDC е в режим на съвместимост Грешка, ако KDC е в режим на изпълнение
Източник на събитие	Kdcsvc
ИД на събитие	39 41 (За Windows Server 2008 R2 SP1 и Windows Server 2008 SP2)
Текст на събитие	Центърът за разпространение на ключове (KDC) се натъкна на потребителски сертификат, който е валиден, но не можа да бъде нанесен към потребител по силен начин (например чрез явно съпоставяне, съпоставяне на ключови гаранти или SID). Тези сертификати трябва или да бъдат заместени, или да бъдат нанесени директно на потребителя чрез явно съпоставяне. Вижте https://go.microsoft.com/fwlink/?linkid=2189925, за да научите повече. Потребител: <на основно име> Тема на сертификата: <име на субекта в> на сертификата Издател на сертификат: <пълното име на домейна на издателя (FQDN) > Сериен номер на сертификата: <сериен номер на> на сертификата Пръстов отпечатък на сертификата: <пръстов отпечатък на сертификата>

Сертификатът е издаден на потребителя, преди потребителят да е съществувал в Active Directory и не е намерено силно съпоставяне. Това събитие се регистрира само когато KDC е в режим на съвместимост.

Регистър на събитията	Система
Тип събитие	Грешка
Източник на събитие	Kdcsvc
ИД на събитие	40 48 (за Windows Server 2008 R2 SP1 и Windows Server 2008 SP2
Текст на събитие	Центърът за разпространение на ключове (KDC) се натъкна на потребителски сертификат, който е валиден, но не можа да бъде нанесен към потребител по силен начин (например чрез явно съпоставяне, съпоставяне на ключови гаранти или SID). Сертификатът предшества и потребителя, с който е нанесен, така че е отхвърлен. Вижте https://go.microsoft.com/fwlink/?linkid=2189925, за да научите повече. Потребител: <на основно име> Тема на сертификата: <име на субекта в> на сертификата Издател на сертификат: FQDN <издател> Сериен номер на сертификата: <сериен номер на> на сертификата Пръстов отпечатък на сертификата: <пръстов отпечатък на сертификата> Час на издаване на сертификата: <FILETIME на сертификата> Време за създаване на акаунт: <FILETIME на основния обект в AD>

SID, който се съдържа в новото разширение на потребителския сертификат, не съответства на SID на потребителите, което означава, че сертификатът е издаден на друг потребител.

Регистър на събитията	Система
Тип събитие	Грешка
Източник на събитие	Kdcsvc
ИД на събитие	41 49 (За Windows Server 2008 R2 SP1 и Windows Server 2008 SP2)
Текст на събитие	Центърът за разпространение на ключове (KDC) се натъкна на потребителски сертификат, който е валиден, но съдържа различен SID от потребителя, с който е нанесен. В резултат на това искането, свързано със сертификата, е неуспешно. Вижте https://go.microsoft.cm/fwlink/?linkid=2189925, за да научите повече. Потребител: <на основно име> Потребителски SID: <SID на главен> за удостоверяване Тема на сертификата: <име на субекта в> на сертификата Издател на сертификат: FQDN <издател> Сериен номер на сертификата: <сериен номер на> на сертификата Пръстов отпечатък на сертификата: <пръстов отпечатък на сертификата> SID на сертификат: <SID е намерен в новия> за разширение на сертификата

Забележка Някои полета, като например "Издател", "Тема" и "Сериен номер", се отчитат във формат "препращане". Трябва да обърнете този формат, когато добавяте низа за съпоставяне към атрибута altSecurityIdentities . Например за да добавите съпоставянето на X509IssuerSerialNumber с потребител, потърсете в полетата "Издател" и "Сериен номер" на сертификата, който искате да съпоставите с потребителя. Вижте примерния резултат по-долу.

• Издател: CN=CONTOSO-DC-CA, DC=contoso, DC=com

• SerialNumber: 2B0000000011AC0000000012

След това актуализирайте атрибута altSecurityIdentities на потребителя в Active Directory със следния низ:

• "X509:<>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC1100000002B"

За да актуализирате този атрибут с помощта на Powershell, можете да използвате командата по-долу. Имайте предвид, че по подразбиране само администраторите на домейни имат разрешението да актуализират този атрибут.

• set-aduser "DomainUser" - replace @{altSecurityIdentities= "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>120000000AC1100000002B"}

Обърнете внимание, че когато обръщате SerialNumber, трябва да запазите реда на байтовете. Това означава, че обръщането на SerialNumber "A1B2C3" трябва да доведе до низа "C3B2A1", а не до "3C2B1A". За повече информация вижте HowTo: Съпоставяне на потребител към сертификат чрез всички методи, налични в атрибута altSecurityIdentities.

След като инсталирате актуализациите на Windows от 10 май 2022 г., устройствата ще бъдат в режим на съвместимост. Ако даден сертификат може силно да бъде нанесен към потребител, удостоверяването ще възникне по очаквания начин. Ако даден сертификат може да бъде слабо свързан с потребител, удостоверяването ще се извърши по очаквания начин. Ще се регистрира предупредително съобщение обаче, освен ако сертификатът не е по-стар от този на потребителя. Ако сертификатът е по-стар от потребителя и ключът от системния регистър за архивиране на сертификат не е наличен или диапазонът е извън компенсацията за архивиране, удостоверяването ще е неуспешно и ще се регистрира съобщение за грешка.  Ако ключът от системния регистър за връщане на сертификата е конфигуриран, той ще регистрира предупредително съобщение в регистрационния файл на събитията, ако датите попадат в размера на компенсацията с по-задна дата.

След като инсталирате актуализациите на Windows от 10 май 2022 г., внимавайте за всяко предупредително съобщение, което може да се появи след един месец или повече. Ако няма предупредителни съобщения, настоятелно ви препоръчваме да разрешите режима на пълно прилагане на всички домейнови контролери, като използвате удостоверяване, базирано на сертификат. Можете да използвате ключа от системния регистър на KDC , за да разрешите режима на пълно прилагане.

Освен ако не е актуализиран в режим на проверка или режим на изпълнение с помощта на ключа от системния регистър StrongCertificateBindingEnforcement по-рано, домейнови контролери ще преминат в режим на пълно прилагане, когато е инсталирана актуализацията на защитата на Windows от февруари 2025 г. Удостоверяването ще бъде отказано, ако даден сертификат не може да бъде силно нанесен. Опцията за връщане в режим на съвместимост ще остане до септември 2025 г. След тази дата ключът от системния регистър StrongCertificateBindingEnforcement вече няма да се поддържа

Ако удостоверяването, базирано на сертификат, разчита на слабо съпоставяне, което не можете да преместите от средата, можете да поставите домейнови контролери в дезактивиран режим с помощта на настройка на ключ от системния регистър. Microsoft не препоръчва това и ще премахнем дезактивирания режим на 11 април 2023 г.

След като сте инсталирали актуализациите на Windows от 13 февруари 2024 г. или по-нови на Server 2019 и по-нови версии и поддържани клиенти с инсталирана незадължителна RSAT функция, съпоставянето на сертификатите в потребители на Active Directory & компютри по подразбиране ще избере силно съпоставяне с помощта на X509IssuerSerSerialNumber вместо слабо съпоставяне с помощта на X509IssuerSubject. Настройката все още може да се променя според предпочитанията си.

• Използвайте kerberos оперативни влизане на съответния компютър, за да определите кой домейнов контролер не успява влизане. Отидете на регистрационни файлове на приложенията и услугите на Визуализатор на събития >\Microsoft \Windows\Security-Kerberos\Operational.

• Потърсете подходящи събития в регистъра на системните събития на домейновия контролер, за който акаунтът се опитва да се удостовери.

• Ако сертификатът е по-стар от акаунта, напишете отново сертификата или добавете защитено съпоставяне altSecurityId в акаунта (вижте Съпоставяния на сертификати).

• Ако сертификатът съдържа SID разширение, проверете дали SID съответства на акаунта.

• Ако сертификатът се използва за удостоверяване на няколко различни акаунта, всеки акаунт ще се нуждае от отделно съпоставяне altSecurityIdentities .

• Ако сертификатът няма защитено съпоставяне с акаунта, добавете такова или оставете домейна в режим на съвместимост, докато не бъде добавено такова.

Пример за съпоставяне на TLS сертификат е използването на IIS интранет уеб приложение.

• След инсталиране на защити CVE-2022-26391 и CVE-2022-26923 , тези сценарии използват протокола Kerberos за сертификат за потребител (S4U) за съпоставяне на сертификати и удостоверяване по подразбиране.

• В протокола Kerberos Certificate S4U искането за удостоверяване тече от сървъра на приложението към домейновия контролер, а не от клиента към домейновия контролер. Следователно съответните събития ще бъдат на сървъра на приложението.

Този ключ от системния регистър няма да се поддържа след инсталирането на актуализации за Windows, издадени на или след септември 2025 г.

Подключ от системния регистър	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Value	StrongCertificateBindingEnforcement
Тип данни	REG_DWORD
Data	1 – Проверява дали има сигурно съпоставяне на сертификати. Ако това е така, удостоверяването е разрешено. В противен случай KDC ще провери дали сертификатът има ново разширение на SID и ще го провери. Ако това разширение не е налично, удостоверяване е разрешено, ако потребителският акаунт предшества сертификата. 2 – Проверява дали има сигурно съпоставяне на сертификати. Ако това е така, удостоверяването е разрешено. В противен случай KDC ще провери дали сертификатът има ново разширение на SID и ще го провери. Ако това разширение не е налично, удостоверяването е отказано. 0 – Забранява проверката за сигурно съпоставяне на сертификати. Не се препоръчва, тъй като това ще забрани всички подобрения на защитата. Ако зададете това на 0, трябва също да зададете CertificateMappingMethods да 0x1F, както е описано в раздела ключ от системния регистър на Schannel по-долу, за да успее удостоверяването, базирано на сертификат на компютъра.
Изисква се рестартиране?	Не

Когато сървърно приложение изисква удостоверяване на клиента, Schannel автоматично се опитва да съпостави сертификата, който TLS клиентът предоставя към потребителски акаунт. Можете да удостоверите потребителите, които влизат със сертификат на клиент, като създадете съпоставяния, които свързват информацията за сертификата с потребителски акаунт в Windows. След като създадете и разрешите съпоставяне на сертификати, всеки път, когато клиентът представи сертификат на клиент, вашето сървърно приложение автоматично свързва този потребител с подходящия потребителски акаунт за Windows.

Schannel ще се опита да съпостави всеки метод за съпоставяне на сертификати, който сте разрешили, докато такъв не успее. Schannel се опитва първо да съпостави съпоставянията service-For-User-To-Self (S4U2Self). Съпоставянията на сертификати за тема/издател, издател и UPN сега се считат за слаби и са забранени по подразбиране. Сумата с побитово търсене на избраните опции определя списъка с налични методи за съпоставяне на сертификати.

Ключът от системния регистър SChannel по подразбиране е 0x1F и сега е 0x18. Ако изпитвате неуспешни удостоверявания с базирани на Schannel сървърни приложения, ви предлагаме да изпълните тест. Добавете или променете стойността на ключа на системния регистър CertificateMappingMethods на домейновия контролер и я задайте на 0x1F и вижте дали това адресира проблема. Погледнете в регистрите на системните събития на домейновия контролер за всички грешки, изброени в тази статия, за повече информация. Имайте предвид, че промяната на стойността на ключа на системния регистър SChannel обратно към предишната стойност по подразбиране (0x1F) ще се върне към използване на методи за съпоставяне на слаби сертификати.

Подключ от системния регистър	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel
Value	CertificateMappingMethods
Тип данни	DWORD
Data	0x0001 – съпоставяне на сертификат за тема/издател (слаб – забранено по подразбиране) 0x0002 – Съпоставяне на сертификата на издателя (слабо – забранено по подразбиране) 0x0004 – съпоставяне на UPN сертификат (слабо – забранено по подразбиране) 0x0008 – S4U2Записване на сертификат (силно) 0x0010 – S4U2Изрична карта на сертификат (силно)
Изисква се рестартиране?	Не

За допълнителни ресурси и поддръжка вижте раздела "Допълнителни ресурси".

След като инсталирате актуализации, които адрес CVE-2022-26931 и CVE-2022-26923, удостоверяването може да е неуспешно в случаите, когато потребителските сертификати са по-стари от времето за създаване на потребителите. Този ключ от системния регистър позволява успешно удостоверяване, когато използвате съпоставяния на слаби сертификати във вашата среда и времето на сертификата е преди часа на създаване на потребителя в зададен диапазон. Този ключ от системния регистър не засяга потребители или машини със силни съпоставяния на сертификати, тъй като времето за сертификата и времето за създаване на потребителя не се проверяват със силни съпоставяния на сертификати. Този ключ от системния регистър не оказва влияние, когато StrongCertificateBindingEnforcement е зададен на 2.

Използването на този ключ от системния регистър е временно заобиколно решение за среди, които го изискват, и трябва да бъдете внимателни. Използването на този ключ от системния регистър означава следното за вашата среда:

• Този ключ от системния регистър работи само в режим на съвместимост , започвайки с актуализации, издадени на 10 май 2022 г. Удостоверяването ще бъде разрешено в рамките на отместването на компенсацията с по-стара форма, но за слабото обвързване ще бъде регистрирано предупреждение в регистъра на събитията.

• Разрешаването на този ключ от системния регистър позволява удостоверяване на потребителя, когато времето на сертификата е преди часа на създаване на потребителя в зададен диапазон като слабо съпоставяне. Слабите съпоставяния няма да се поддържат след инсталирането на актуализации за Windows, издадени на или след септември 2025 г.

Подключ от системния регистър	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Value	CertificateBackdatingCompensation
Тип данни	REG_DWORD
Data	Стойности за заобиколно решение в приблизителни години: 50 години: 0x5E0C89C0 25 години: 0x2EFE0780 10 години: 0x12CC0300 5 години: 0x9660180 3 години: 0x5A39A80 1 година: 0x1E13380 Забележка Ако знаете жизнения цикъл на сертификатите във вашата среда, задайте този ключ от системния регистър малко по-дълъг от времето на съществуване на сертификата.  Ако не знаете жизнения цикъл на сертификата за вашата среда, задайте този ключ от системния регистър на 50 години. По подразбиране е 10 минути, когато този ключ не е наличен, което съответства на услугите за сертификати на Active Directory (ADCS). Максималната стойност е 50 години (0x5E0C89C0). Този ключ задава времевата разлика в секунди, която центърът за разпространение на ключове (KDC) ще игнорира между времето на издаване на сертификат за удостоверяване и времето на създаване на акаунта за акаунти на потребители/машини. Важно Задайте този ключ от системния регистър само ако вашата среда го изисква. Използването на този ключ от системния регистър забранява проверката на защитата.
Изисква се рестартиране?	Не

Изпълнете следната команда certutil , за да изключите сертификати на потребителски шаблон от получаване на новото разширение.

1. Влезте в сървър на сертифициращия орган или клиент, присъединен към домейн, Windows 10 с администратора на предприятието или еквивалентните идентификационни данни.

2. Отворете команден прозорец и изберете Изпълнявай като администратор.

3. Изпълнете certutil -dstemplate потребител msPKI-Enrollment-Flag +0x00080000. 

Забраняването на добавянето на това разширение ще премахне защитата, предоставена от новото разширение. Обмислете дали да не направите това само след едно от следните неща:

1. Потвърждавате, че съответните сертификати не са приемливи за Cryptography на публичен ключ за първоначално удостоверяване (PKINIT) в удостоверяване на Протокола kerberos в KDC

2. Съответните сертификати имат конфигурирани други силни съпоставяния на сертификати

Среди, които имат разполагания, които не са на Microsoft CA, няма да бъдат защитени с помощта на новото разширение SID след инсталиране на актуализацията на Windows от 10 май 2022 г. Засегнатите клиенти трябва да работят със съответните доставчици на СО, за да се справят с това, или трябва да обмислят използването на други силни съпоставяния на сертификати, описани по-горе.

За допълнителни ресурси и поддръжка вижте раздела "Допълнителни ресурси".

Не, подновяването не е задължително. СО ще се доставя в режим на съвместимост. Ако искате силно съпоставяне с помощта на разширението ObjectSID, ще ви трябва нов сертификат.

В актуализацията на Windows от 11 февруари 2025 г. устройствата, които все още не са в изпълнение (StrongCertificateBindingEnforcement стойност в системния регистър е зададена на 2), ще бъдат преместени в Изпълнение. Ако удостоверяването е отказано, ще видите ИД на събитие 39 (или ИД на събитие 41 за Windows Server 2008 R2 SP1 и Windows Server 2008 SP2). На този етап ще имате опцията да зададете стойността на ключа от системния регистър на 1 (режим на съвместимост).

В актуализацията на Windows от 10 септември 2025 г. стойността в системния регистър StrongCertificateBindingEnforcement вече няма да се поддържа. ​​​​​​​