KB5014754: spremembe preverjanja pristnosti na podlagi potrdila v krmilnikih domene Windows

Močnih preslikav potrdil ni bilo mogoče najti in potrdilo ni imelo nove razširitve varnostnega identifikatorja (SID), ki bi jo KDC lahko preveril.

Potrdilo je bilo izdano uporabniku, preden je uporabnik obstajal v imeniku Active Directory, in ni bilo mogoče najti močne preslikave. Ta dogodek je zabeležen le, če je ključna poveznica v združljivostnem načinu.

SID v novi razširitvi uporabniškega potrdila se ne ujema s SID uporabnika, kar pomeni, da je bilo potrdilo izdano drugemu uporabniku.

Opomba Nekatera polja, kot so izdajatelj, zadeva in serijska številka, so sporočena v obliki »posredovanja«. To obliko morate obrniti, ko dodate niz preslikave v atribut altSecurityIdentities . Če želite na primer uporabniku dodati preslikavo X509IssuerSerialNumber, poiščite polji »Izdajatelj« in »Serijska številka« potrdila, ki ga želite preslikati na uporabnika. Oglejte si spodnji vzorčni izhod.

• Izdajatelj: CN = CONTOSO-DC-CA, DC = contoso, DC = com
• Serijska številka: 2B0000000011AC0000000012

Nato posodobite uporabnikov atribut altSecurityIdentities v imeniku Active Directory s tem nizom:

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

Če želite posodobiti ta atribut s storitvijo Powershell, uporabite spodnji ukaz. Upoštevajte, da imajo privzeto dovoljenje za posodabljanje tega atributa samo skrbniki domene.

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

Upoštevajte, da morate pri obrnitvi serijske številke ohraniti vrstni red bajtov. To pomeni, da bi moral biti z obračanjem serijske številke »A1B2C3« naveden niz »C3B2A1« in ne »3C2B1A«. Če želite več informacij, glejte HowTo: Preslikava uporabnika v potrdilo z vsemi metodami, ki so na voljo v atributu altSecurityIdentities.

Ko namestite posodobitve sistema Windows 10. maja 2022, bodo naprave v združljivostnem načinu. Če je potrdilo mogoče močno preslikati na uporabnika, bo preverjanje pristnosti potekalo po pričakovanjih. Če je potrdilo mogoče le šibko preslikati na uporabnika, bo preverjanje pristnosti izvedeno po pričakovanjih. Vendar pa bo opozorilo zabeleženo, razen če je potrdilo starejše od uporabnika. Če je potrdilo starejše od uporabnika in registrski ključ potrdila za nazaj ni na voljo ali je obseg zunaj nadomestila za staranje, preverjanje pristnosti ne bo uspelo in zabeleženo bo sporočilo o napaki.  Če je konfiguriran registrski ključ za nazaj potrdila, bo v dnevnik dogodkov zabeležil opozorilno sporočilo, če datumi spadajo v nadomestilo za staranje.

Ko namestite posodobitve sistema Windows z dne 10. maja 2022, bodite pozorni na opozorilo, ki se lahko prikaže po enem mesecu ali več. Če ni opozorilnih sporočil, priporočamo, da omogočite način polnega uveljavljanja v vseh krmilnikih domene, ki uporabljajo preverjanje pristnosti na podlagi potrdila. Z registrskim ključem KDC lahko omogočite način polnega uveljavljanja.

Če krmilniki domene prej ne bodo posodobljeni v način nadzora ali način uveljavljanja z registrskim ključem StrongCertificateBindingEnforcement , se bodo krmilniki domene premaknili v način polnega uveljavljanja, ko bo nameščena varnostna posodobitev sistema Windows iz februarja 2025. Preverjanje pristnosti bo zavrnjeno, če potrdila ni mogoče močno preslikati. Možnost za premik nazaj v združljivostni način bo ohranjena, dokler ne bo nameščena varnostna posodobitev sistema Windows 9. septembra 2025. Po tem datumu registrski ključ StrongCertificateBindingEnforcement ne bo več podprt

Če preverjanje pristnosti na podlagi potrdila temelji na šibki preslikavi, ki je ne morete premakniti iz okolja, lahko krmilnike domene preklopite v onemogočeni način z nastavitvijo registrskega ključa. Microsoft tega ne priporoča in onemogočeni način bomo odstranili 11. aprila 2023.

Ko namestite posodobitve sistema Windows z dne 13. februarja 2024 ali novejše v strežniku Server 2019 in novejših različicah ter podprte odjemalce z nameščeno izbirno funkcijo RSAT, bo preslikava potrdila v razdelku Uporabniki imenika Active Directory & računalnikih privzeto izbrala močno preslikavo s storitvijo X509IssuerSerialNumber namesto šibke preslikave s programom X509IssuerSubject. Nastavitev je še vedno mogoče spremeniti po želji.

Simptomi

Microsoft je prejel poročila, da je nastavitev »Obdelaj, tudi če se predmeti pravilnik skupine niso spremenili« pod predmetom pravilnik skupine »Konfiguracija> računalnikaSkrbniške predloge>Sistempravilnik>skupineKonfiguracija>obdelave pravilnika registra" lahko občasno moti preslikave na podlagi imen na krmilnikih domene.

Rešitev

Če se želite izogniti tej težavi, onemogočite nastavitev »Obdelaj, tudi če se predmeti pravilnika skupine niso spremenili« na krmilnikih domene. To storite le, če so potrebne preslikave na podlagi imena, kot so opredeljene v pravilniku skupine »Konfiguracija> računalnika,skrbniške predloge>,sistem>KDC>,Dovoli močne preslikave na podlagi imen za potrdila«. Če želite več informacij, glejte Omogočanje močnega preslikavanja na podlagi imen v vladnih scenarijih.

Naslednji korak

Ta poročila preiskujemo in bomo zagotovili več informacij, ko bodo na voljo.

• Uporabite dnevnik delovanja protokola Kerberos v ustreznem računalniku, da ugotovite, kateri krmilnik domene ne uspe pri vpisu. Pojdite na Pregledovalnik dogodkov>Dnevniki aplikacij in storitev Microsoft\ \Windows\Security-Kerberos\operativen.
• Poiščite ustrezne dogodke v dnevniku sistemskih dogodkov na krmilniku domene, s katerim račun poskuša preveriti pristnost.
• Če je potrdilo starejše od računa, ga znova izdajte ali dodajte varno preslikavo altSecurityIdentities v račun (glejte Preslikave potrdil).
• Če potrdilo vsebuje razširitev SID, preverite, ali se SID ujema z računom.
• Če se potrdilo uporablja za preverjanje pristnosti več različnih računov, bo vsak račun potreboval ločeno preslikavo altSecurityIdentities .
• Če potrdilo nima varne preslikave v račun, ga dodajte ali pustite domeno v združljivostnem načinu, dokler ga ne boste lahko dodali.

Primer preslikave potrdila TLS je uporaba intranetne spletne aplikacije IIS.

• Po namestitvi zaščite CVE-2022-26391 in CVE-2022-26923 ti scenariji privzeto uporabljajo protokol Kerberos Certificate Service For User (S4U) za preslikavo potrdila in preverjanje pristnosti.
• V protokolu potrdila Kerberos S4U zahteva za preverjanje pristnosti teče od aplikacijskega strežnika do krmilnika domene in ne od odjemalca do krmilnika domene. Zato bodo ustrezni dogodki na aplikacijskem strežniku.

Ta registrski ključ ne bo podprt po namestitvi posodobitev za Windows, izdanih septembra 2025 ali pozneje.

Ko strežniška aplikacija zahteva preverjanje pristnosti odjemalca, Schannel samodejno poskuša preslikati potrdilo, ki ga odjemalec TLS posreduje, v uporabniški račun. Preverjanje pristnosti uporabnikov, ki se vpišejo s potrdilom odjemalca, lahko preverite tako, da ustvarite preslikave, ki povezujejo informacije o potrdilu z uporabniškim računom sistema Windows. Ko ustvarite in omogočite preslikavo potrdila, vsakič, ko odjemalec predstavi odjemalsko potrdilo, strežniški program samodejno poveže tega uporabnika z ustreznim uporabniškim računom sistema Windows.

Schannel bo poskušal preslikati vsako metodo preslikave potrdila, ki ste jo omogočili, dokler ena ne bo uspešna. Schannel najprej poskuša preslikati preslikave storitve za uporabnika do sebe (S4U2Self). Preslikave potrdil Predmet/izdajatelj, Izdajatelj in UPN so zdaj šibke in so privzeto onemogočene. Bitna vsota izbranih možnosti določa seznam razpoložljivih načinov preslikave potrdil.

Privzeti registrski ključ SChannel je bil 0x1F in je zdaj 0x18. Če pride do napak pri preverjanju pristnosti s strežniškimi aplikacijami, ki temeljijo na Schannel, predlagamo, da izvedete preskus. Dodajte ali spremenite vrednost registrskega ključa CertificateMappingMethods v krmilniku domene in jo nastavite na 0x1F ter preverite, ali ste s tem odpravili težavo. Če želite več informacij, poiščite napake v dnevnikih sistemskih dogodkov na krmilniku domene, ki so navedene v tem članku. Ne pozabite, da se bo sprememba vrednosti registrskega ključa SChannel nazaj na prejšnjo privzeto vrednost (0x1F) vrnila na uporabo šibkih metod preslikave potrdil.

Za dodatne vire in podporo glejte razdelek »Dodatni viri«.

Ko namestite posodobitve, ki obravnavajo CVE-2022-26931 in CVE-2022-26923, preverjanje pristnosti morda ne bo uspelo v primerih, ko so uporabniška potrdila starejša od časa ustvarjanja uporabnikov. Ta registrski ključ omogoča uspešno preverjanje pristnosti, ko v svojem okolju uporabljate šibke preslikave potrdil in je čas potrdila pred časom ustvarjanja uporabnika v nastavljenem obsegu. Ta registrski ključ ne vpliva na uporabnike ali računalnike z močnimi preslikavami potrdil, saj čas potrdila in čas ustvarjanja uporabnika nista preverjena z močnimi preslikavami potrdil. Ta registrski ključ nima učinka, če je StrongCertificateBindingEnforcement nastavljen na 2.

Uporaba tega registrskega ključa je začasna rešitev za okolja, ki jo zahtevajo, in jo je treba opraviti previdno. Uporaba tega registrskega ključa za vaše okolje pomeni naslednje:

• Ta registrski ključ deluje samo v združljivostnem načinu , začenši s posodobitvami, izdanimi 10. maja 2022. Preverjanje pristnosti bo dovoljeno v okviru nadomestila za nazaj za nazaj, vendar bo zabeleženo opozorilo dnevnika dogodkov za šibko vezavo.
• Če omogočite ta registrski ključ, omogočite preverjanje pristnosti uporabnika, ko je čas potrdila pred časom ustvarjanja uporabnika v nastavljenem obsegu kot šibko preslikavo. Šibke preslikave ne bodo podprte po namestitvi posodobitev za Windows, izdanih septembra 2025 ali pozneje.

Zaženete ta ukaz certutil , da izključite potrdila uporabniške predloge iz pridobivanja nove razširitve.

1. Vpišite se v strežnik overitelja potrdil ali odjemalca sistema Windows 10, ki je pridružen domeni, s skrbnikom podjetja ali enakovrednimi poverilnicami.
2. Odprite ukazni poziv in izberite Zaženi kot skrbnik.
3. Zaženite certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

Če onemogočite dodajanje te razširitve, boste odstranili zaščito, ki jo zagotavlja nova razširitev. Razmislite o tem, da to storite šele po enem od naslednjega:

1. Potrdite, da ustrezna potrdila niso sprejemljiva za šifriranje javnega ključa za začetno preverjanje pristnosti (PKINIT) pri preverjanju pristnosti protokola Kerberos na spletnem mestu KDC
2. Za ustrezna potrdila so konfigurirane druge močne preslikave potrdil

Okolja, ki imajo uvedbe izdelovalnega potrdila, ki niso Microsoftova potrdila, po namestitvi posodobitve sistema Windows 10. maja 2022 ne bodo zaščitena z novo razširitvijo SID. Prizadete stranke bi morale sodelovati z ustreznimi prodajalci potrdil, da bi to rešile, ali pa bi morale razmisliti o uporabi drugih močnih preslikav potrdil, opisanih zgoraj.

Za dodatne vire in podporo glejte razdelek »Dodatni viri«.

Ne, podaljšanje ni potrebno. CA bo dobavljen v združljivostnem načinu. Če želite močno preslikavo z razširitvijo ObjectSID, boste potrebovali novo potrdilo.

V posodobitvi sistema Windows Update 11. februarja 2025 bodo naprave, ki še niso v postopku uveljavljanja (vrednost registra StrongCertificateBindingEnforcement je nastavljena na 2), premaknjene v uveljavitev. Če je preverjanje pristnosti zavrnjeno, se prikaže ID dogodka 39 (ali ID dogodka 41 za Windows Server 2008 R2 s servisnim paketom SP1 in servisnim paketom SP2 za Windows Server 2008). Na tej stopnji boste imeli možnost, da vrednost registrskega ključa nastavite nazaj na 1 (združljivostni način).

V storitvi Windows Update 9. septembra 2025 vrednost registra StrongCertificateBindingEnforcement ne bo več podprta.