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

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

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

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

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

• Издател: CN=CONTOSO-DC-CA, DC=contoso, DC=com
• Сериен номер: 2B000000011AC000000012

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

• "X509:<I>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>1200000000AC1100000002B"}

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

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

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

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

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

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

Симптоми

Microsoft получи отчети, че настройката "Обработка дори ако обектите на групови правила не са променени" в обекта на групови правила "Системни групови правила за конфигуриране>>>на административни шаблони за конфигурация на системния регистър Конфигуриране на обработката на правилата на системния регистър>" може периодично да причинява смущения с базирани на имена съответствия на домейнови контролери.

Заобиколно решение

За да заобиколите този проблем, забранете настройката "Обработка дори ако обектите на групови правила не са променени" на домейновите контролери. Направете това само ако са необходими съпоставяния, базирани на име, както е дефинирано в групови правила "Система за конфигуриране>>> накомпютър KDC>позволяване на базирани на имена строги съпоставяния за сертификати". За повече информация вижте "Разрешаване на строго съпоставяне, базирано на имена", в сценарии за държавни организации.

Следваща стъпка

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

• Използвайте оперативния регистрационен файл на Kerberos на съответния компютър, за да определите кой домейнов контролер не успява да влезе. Отидете въвВизуализатор на събитияРегистрационни>файлове за приложения и услуги Microsoft\ \Windows\Security-Kerberos\Operational.
• Потърсете съответните събития в регистъра на системните събития в домейновия контролер, за който акаунтът се опитва да удостовери.
• Ако сертификатът е по-стар от акаунта, преиздайте сертификата или добавете защитено съпоставяне на altSecurityIdentities към акаунта (вж. Съпоставяния на сертификати).
• Ако сертификатът съдържа разширение на SID, проверете дали SID съответства на акаунта.
• Ако сертификатът се използва за удостоверяване на няколко различни акаунта, всеки акаунт ще трябва да има отделно съпоставяне на altSecurityIdentities .
• Ако сертификатът няма защитено съпоставяне с акаунта, добавете такова или оставете домейна в режим на съвместимост, докато не може да бъде добавен такъв.

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

• След инсталиране на защити на CVE-2022-26391 и CVE-2022-26923 , тези сценарии използват протокола Kerberos Certificate Service For User (S4U) за съпоставяне и удостоверяване на сертификати по подразбиране.
• В протокола S4U за сертификат на Kerberos заявката за удостоверяване тече от сървъра на приложението към домейновия контролер, а не от клиента към домейновия контролер. Следователно съответните събития ще бъдат на сървъра за приложения.

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

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

Schannel ще се опитва да нанесе всеки метод за съпоставяне на сертификати, който сте активирали, докато един от тях не успее. Schannel се опитва да нанесе първо съпоставянията "Услуга за потребител към себе си" (S4U2Self). Съпоставянията на сертификати "Тема/издател", "Издател" и "UPN" сертификати сега се считат за слаби и са забранени по подразбиране. Побитовата сума на избраните опции определя списъка с наличните методи за съпоставяне на сертификати.

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

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

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

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

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

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

1. Влезте в сървър на сертифициращ орган или присъединен към домейн клиент на Windows 10 с корпоративен администратор или еквивалентни идентификационни данни.
2. Отворете командния прозорец и изберете " Изпълнение като администратор".
3. Run certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

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

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

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

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

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

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

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