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, na primer izdajatelj, zadeva in serijska številka, so sporočena v obliki »posredovanja«. To obliko morate obrniti, ko niz za preslikavo dodate atributu altSecurityIdentities . Če želite na primer dodati preslikavo X509IssuerSerialNumber za uporabnika, poiščite polji »Izdajatelj« in »Serijska številka« potrdila, ki ga želite preslikati za uporabnika. Oglejte si vzorčni rezultat spodaj.

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

Nato posodobite atribut uporabnika altSecurityIdentities v imeniku Active Directory z naslednjim nizom:

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

Če želite posodobiti ta atribut z ogrodjem Powershell, uporabite spodnji ukaz. Ne pozabite, da imajo privzeto dovoljenje za posodobitev tega atributa le skrbniki domen.

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

Če obrnete vrednost »SerialNumber«, morate obdržati vrstni red bajtov. To pomeni, da bi moral biti rezultat obračanja serijske številke »A1B2C3« niz »C3B2A1« in ne »3C2B1A«. Če želite več informacij, glejte Nasveti: Preslikava uporabnika v potrdilo z vsemi načini, ki so na voljo v atributu altSecurityIdentities.

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

Ko namestite posodobitve sistema Windows z dne 10. maja 2022, bodite pozorni na morebitna opozorila, ki se lahko prikažejo čez mesec dni ali več. Če ni nobenega opozorila, toplo priporočamo, da omogočite način polnega uveljavljanja v vseh krmilnikih domene, ki uporabljajo preverjanje pristnosti na osnovi potrdila. Z registrskim ključem KDC lahko omogočite način polnega uveljavljanja.

Če krmilniki domene niso posodobljeni na način nadzora ali način uveljavljanja z registrskim ključem StrongCertificateBindingEnforcement prej, bodo krmilniki domene pri namestitvi varnostne posodobitve sistema Windows iz februarja 2025 prešli v način polnega uveljavljanja. Preverjanje pristnosti bo zavrnjeno, če potrdila ni mogoče močno preslikati. Možnost za vrnitev v združljivostni način bo ohranjena do namestitve varnostne posodobitve sistema Windows 9. septembra 2025. Po tem datumu registrski ključ StrongCertificateBindingEnforcement ne bo več podprt

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

Ko namestite posodobitve sistema Windows z dne 13. februarja 2024 ali novejše v Server 2019 in novejše ter podprte odjemalce z nameščeno izbirno funkcijo RSAT, bo preslikava potrdila v uporabnikih imenika Active Directory & računalnikih privzeto izbrala močno preslikavo z X509IssuerSerialNumber namesto šibke preslikave z X509IssuerSubject. Nastavitev lahko še vedno spremenite 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>Sistemski>pravilnik skupineKonfiguriranje>obdelave registrskega pravilnika« lahko občasno vpliva na preslikave na podlagi imena v krmilnikih domene.

Rešitev

Če se želite izogniti tej težavi, onemogočite nastavitev »Obdelaj, tudi če se predmeti pravilnik skupine niso spremenili« v krmilnikih domene. To naredite le, če so potrebne preslikave na podlagi imena, kot je določeno v pravilnik skupine »Konfiguracija>>računalnika, sistemskrbniških predlog>KDC>,dovoli močno preslikavo na osnovi imena za potrdila«. Če želite več informacij, glejte Omogočanje močne preslikave na osnovi imena v scenarijih za vladne ustanove.

Naslednji korak

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

• Uporabite operativni dnevnik Kerberos v ustreznem računalniku, da določite, v kateri krmilnik domene se ne more vpisati. Pojdite v PregledovalnikdogodkovDnevniki\> aplikacij in storitevVarnost sistema Microsoft \Windows\– Kerberos\Operational.
• Poiščite ustrezne dogodke v dnevniku sistemskih dogodkov v krmilniku domene, na katerem račun poskuša preveriti pristnost.
• Če je potrdilo starejše od računa, ga znova izdajte ali pa računu dodajte varno preslikavo altSecurityIdentities (glejte Preslikave potrdil).
• Če potrdilo vsebuje pripono 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, jo dodajte ali pustite domeno v združljivostnem načinu, dokler je ne dodate.

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 storitve Kerberos Certificate Service For User (S4U) za preslikavo potrdila in preverjanje pristnosti.
• V protokolu potrdila Kerberos S4U zahteva za preverjanje pristnosti teče od programskega strežnika do krmilnika domene in ne od odjemalca do krmilnika domene. Zato bodo ustrezni dogodki v strežniku aplikacije.

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, storitev Schannel samodejno poskuša preslikati potrdilo, ki ga zagotovi odjemalec TLS, v uporabniški račun. Uporabnike, ki se vpisujejo s potrdilom odjemalca, lahko preverite tako, da ustvarite preslikave, ki informacije o potrdilu povežejo z uporabniškim računom sistema Windows. Ko ustvarite in omogočite preslikavo potrdila, vsakič, ko odjemalec predstavi potrdilo odjemalca, strežniška aplikacija 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 uspe. Schannel poskuša najprej preslikati preslikavo storitve za uporabnika sebi (S4U2Self). Preslikave potrdil predmeta/izdajatelja, izdajatelja in UPN so zdaj šibke in so privzeto onemogočene. Zakrita vsota izbranih možnosti določa seznam načinov preslikave potrdil, ki so na voljo.

Privzeti registrski ključ SChannel je bil 0x1F in je zdaj 0x18. Če pride do napak pri preverjanju pristnosti s strežniškimi aplikacijami 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, navedene v tem članku, v dnevnikih sistemskih dogodkov v krmilniku domene. Ne pozabite, da bo sprememba vrednosti registrskega ključa SChannel nazaj na prejšnjo privzeto vrednost (0x1F) povrnjena na uporabo šibkih metod preslikave potrdil.

Če želite dodatne vire in podporo, glejte razdelek »Dodatni viri«.

Ko namestite posodobitve, ki odpravljajo CVE-2022-26931 in CVE-2022-26923, preverjanje pristnosti morda ne uspe v primerih, ko so uporabniška potrdila starejša od časa ustvarjanja uporabnikov. Ta registrski ključ omogoča uspešno preverjanje pristnosti, če uporabljate šibke preslikave potrdil v svojem okolju in je čas potrdila pred časom, ki je bil ustvarjen uporabnik znotraj nastavljenega razpona. 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, ko je vrednost StrongCertificateBindingEnforcement nastavljena na 2.

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

• Ta registrski ključ deluje le v združljivostnem načinu , začenši s posodobitvami, izdanimi 10. maja 2022. Preverjanje pristnosti bo dovoljeno znotraj kompenzacijskega odmika za vzporedno datumiranje, vendar bo zabeleženo opozorilo dnevnika dogodkov za šibko vezavajo.
• Če omogočite ta registrski ključ, omogočite preverjanje pristnosti uporabnika, ko je čas potrdila pred časom ustvarjanja uporabnika znotraj nastavljenega razpona kot šibka preslikava. Šibke preslikave ne bodo podprte po namestitvi posodobitev za Windows, izdanih septembra 2025 ali pozneje.

Zaženite ta ukaz certutil , da potrdila uporabniške predloge izključite 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.