KB5014754: Modificări de autentificare bazate pe certificat pe controlerele de domeniu Windows

Nu au fost găsite mapări puternice ale certificatelor, iar certificatul nu avea noua extensie de identificator de securitate (SID) pe care KDC o putea valida.

Certificatul a fost emis utilizatorului înainte ca utilizatorul să existe în Active Directory și nu a putut fi găsită nicio mapare puternică. Acest eveniment este înregistrat în jurnal doar atunci când KDC este în modul de compatibilitate.

SID-ul conținut în noua extensie a certificatului de utilizatori nu se potrivește cu SID-ul utilizatorilor, ceea ce înseamnă că certificatul a fost emis unui alt utilizator.

Notă Anumite câmpuri, cum ar fi Emitent, Subiect și Număr de serie, sunt raportate într-un format "redirecționat". Trebuie să inversați acest format atunci când adăugați șirul de mapare la atributul altSecurityIdentities . De exemplu, pentru a adăuga maparea X509IssuerSerialNumber la un utilizator, căutați în câmpurile "Emitent" și "Număr de serie" ale certificatului pe care doriți să-l asociați la utilizator. Vedeți rezultatul eșantion de mai jos.

• Emitent: CN=CONTOSO-DC-CA, DC=contoso, DC=com
• Număr de serie: 2B0000000011AC000000012

Apoi actualizați atributul altSecurityIdentities al utilizatorului în Active Directory cu următorul șir:

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

Pentru a actualiza acest atribut utilizând Powershell, puteți utiliza comanda de mai jos. Rețineți că, în mod implicit, doar administratorii de domeniu au permisiunea de a actualiza acest atribut.

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

Rețineți că atunci când inversați SerialNumber, trebuie să păstrați ordinea în octeți. Aceasta înseamnă că inversarea numărului de serie "A1B2C3" ar trebui să aibă ca rezultat șirul "C3B2A1" și nu "3C2B1A". Pentru mai multe informații, consultați Instrucțiuni: Maparea unui utilizator la un certificat prin toate metodele disponibile în atributul altSecurityIdentities.

După ce ați instalat actualizările Windows din 10 mai 2022, dispozitivele vor fi în modul de compatibilitate. Dacă un certificat poate fi mapat puternic la un utilizator, autentificarea va avea loc așa cum vă așteptați. Dacă un certificat poate fi mapat doar slab la un utilizator, autentificarea va avea loc așa cum vă așteptați. Totuși, un mesaj de avertisment va fi înregistrat în jurnal, cu excepția cazului în care certificatul este mai vechi decât utilizatorul. Dacă certificatul este mai vechi decât utilizatorul și cheia de registry pentru certificatele anterioare nu este prezentă sau intervalul este în afara compensării pentru retrodatare, autentificarea nu va reuși și va fi înregistrat un mesaj de eroare.  Dacă cheia de registry pentru certificatele anterioare este configurată, aceasta va înregistra un mesaj de avertisment în jurnalul de evenimente dacă datele se încadrează în compensația de retrodatare.

După ce instalați actualizările Windows din 10 mai 2022, așteptați orice mesaj de avertizare care poate apărea după o lună sau mai mult. Dacă nu există mesaje de avertizare, vă recomandăm ferm să activați modul de impunere totală pe toate controlerele de domeniu utilizând autentificarea bazată pe certificat. Puteți utiliza cheia de registry KDC pentru a activa modul de impunere totală.

Cu excepția cazului în care sunt actualizate mai devreme la modul Auditare sau Impunere utilizând cheia de registry StrongCertificateBindingForce , controlerele de domeniu vor trece în modul de impunere totală atunci când se instalează actualizarea de securitate Windows din februarie 2025. Autentificarea va fi refuzată dacă un certificat nu poate fi mapat puternic. Opțiunea de a reveni la modul de compatibilitate va rămâne până când se instalează actualizarea de securitate Windows din 9 septembrie 2025. După această dată, cheia de registry StrongCertificateBindingEnforcement nu va mai fi acceptată

Dacă autentificarea bazată pe certificat se bazează pe o mapare slabă pe care nu o puteți muta din mediu, puteți plasa controlerele de domeniu în modul Dezactivat utilizând o setare de cheie de registry. Microsoft nu recomandă acest lucru și vom elimina modul Dezactivat pe 11 aprilie 2023.

După ce ați instalat actualizările Windows din 13 februarie 2024 sau mai recente pe Server 2019 și mai sus și clienții acceptați cu caracteristica opțională RSAT instalată, maparea certificatelor în Utilizatori & computere Active Directory va selecta implicit o mapare puternică utilizând X509IssuerSerialNumber în loc de o mapare slabă utilizând X509IssuerSubject. Setarea poate fi modificată după cum doriți.

Simptome

Microsoft a primit rapoarte conform cărora setarea "Proces chiar dacă obiectele Politică de grup nu s-au modificat" sub obiectul Politică de grup "Configurație> computerȘabloane administrative Sistem>>Politică de grupConfigurarea>procesării politicii de registry" poate interfera intermitent cu mapările bazate pe nume pe controlerele de domeniu.

Soluție de evitare

Pentru a rezolva această problemă, dezactivați setarea "Procesați chiar dacă obiectele Politică de grup nu s-au modificat" pe controlerele de domeniu. Faceți acest lucru doar dacă sunt necesare mapări bazate pe nume, așa cum sunt definite în Politica de grup "Configurație> computer,Șabloane> administrative,Sistem>KDC>: Permiteți mapări puternice bazate pe nume pentru certificate". Pentru mai multe informații, consultați Activarea unei mapări puternice bazate pe nume în scenariile guvernamentale.

Pasul următor

Investigăm aceste rapoarte și vom oferi mai multe informații atunci când vor fi disponibile.

• Utilizați jurnalul operațional Kerberos de pe computerul relevant pentru a determina controlerul de domeniu care nu reușește să se conecteze. Accesați Vizualizator evenimenteJurnale> de aplicații și servicii Microsoft\ \Windows\Security-Kerberos\operațional.
• Căutați evenimente relevante în jurnalul de evenimente de sistem de pe controlerul de domeniu împotriva căruia contul încearcă să se autentifice.
• Dacă certificatul este mai vechi decât contul, emiteți din nou certificatul sau adăugați o mapare securizată altSecurityIdentities la cont (consultați mapările certificatelor).
• Dacă certificatul conține o extensie SID, verificați dacă SID se potrivește cu contul.
• Dacă certificatul este utilizat pentru a autentifica mai multe conturi diferite, fiecare cont va avea nevoie de o mapare separată altSecurityIdentities .
• Dacă certificatul nu are o mapare securizată la cont, adăugați una sau lăsați domeniul în modul de compatibilitate până când se poate adăuga una.

Un exemplu de mapare a certificatelor TLS este utilizarea unei aplicații web de intranet IIS.

• După instalarea protecțiilor CVE-2022-26391 și CVE-2022-26923 , aceste scenarii utilizează în mod implicit protocolul Kerberos Certificate Service For User (S4U) pentru maparea certificatelor și autentificare.
• În protocolul S4U pentru certificat Kerberos, solicitarea de autentificare curge de la serverul de aplicații la controlerul de domeniu, nu de la client la controlerul de domeniu. Prin urmare, evenimentele relevante vor fi pe serverul de aplicații.

Această cheie de registry nu va fi acceptată după instalarea actualizărilor pentru Windows lansate la sau după septembrie 2025.

Atunci când o aplicație server necesită autentificarea clientului, Schannel încearcă automat să mapeze certificatul pe care clientul TLS îl furnizează la un cont de utilizator. Puteți autentifica utilizatorii care se conectează cu un certificat de client prin crearea de mapări care asociază informațiile despre certificat la un cont de utilizator Windows. După ce creați și activați o mapare de certificat, de fiecare dată când un client prezintă un certificat de client, aplicația server asociază automat utilizatorul respectiv cu contul de utilizator Windows corespunzător.

Schannel va încerca să mapeze fiecare metodă de mapare a certificatelor pe care ați activat-o până când una reușește. Schannel încearcă mai întâi să mapeze mapările Service-for-User-To-Self (S4U2Self). Mapările de certificate Subiect/Emitent, Emitent și UPN sunt acum considerate slabe și au fost dezactivate în mod implicit. Suma biților a opțiunilor selectate determină lista de metode de mapare a certificatelor care sunt disponibile.

Cheia de registry SChannel implicită a fost 0x1F și acum este 0x18. Dacă întâmpinați erori de autentificare cu aplicațiile server bazate pe Schannel, vă sugerăm să efectuați un test. Adăugați sau modificați valoarea cheii de registry CertificateMappingMethods pe controlerul de domeniu și setați-o la 0x1F și vedeți dacă aceasta rezolvă problema. Pentru mai multe informații, căutați erorile listate în acest articol în jurnalele de evenimente de sistem de pe controlerul de domeniu. Rețineți că modificarea valorii cheii de registry SChannel înapoi la valoarea implicită anterioară (0x1F) va reveni la utilizarea metodelor slabe de mapare a certificatelor.

Pentru resurse suplimentare și asistență, consultați secțiunea "Resurse suplimentare".

După ce instalați actualizările care se adresează CVE-2022-26931 și CVE-2022-26923, autentificarea poate să nu reușească în cazurile în care certificatele de utilizator sunt mai vechi decât ora creării utilizatorilor. Această cheie de registry permite autentificarea reușită atunci când utilizați mapări slabe ale certificatelor în mediul dvs., iar ora certificatului este înainte de ora creării utilizatorului, într-un interval setat. Această cheie de registry nu afectează utilizatorii sau mașinile cu mapări puternice ale certificatului, deoarece ora certificatului și ora creării utilizatorului nu sunt verificate cu mapări puternice ale certificatului. Această cheie de registry nu are niciun efect atunci când StrongCertificateBindingEnforcement este setat la 2.

Utilizarea acestei chei de registry este o soluție temporară pentru mediile care necesită acest lucru și trebuie făcută cu precauție. Utilizarea acestei chei de registry înseamnă următoarele lucruri pentru mediul dvs.:

• Această cheie de registry funcționează numai în modul de compatibilitate începând cu actualizările lansate pe 10 mai 2022. Autentificarea va fi permisă în cadrul compensației de retrodatare, dar se va înregistra un avertisment în jurnalul de evenimente pentru legătura slabă.
• Activarea acestei chei de registry permite autentificarea utilizatorului atunci când ora certificatului este înainte de ora creării utilizatorului într-un interval setat, ca o mapare slabă. Mapările slabe nu vor fi acceptate după instalarea actualizărilor pentru Windows lansate la sau după această dată din septembrie 2025.

Rulați următoarea comandă certutil pentru a exclude certificatele șablonului de utilizator de la obținerea noii extensii.

1. Conectați-vă la un server de autoritate de certificare sau la un client Windows 10 asociat la domeniu cu acreditările de administrator de întreprindere sau echivalente.
2. Deschideți o linie de comandă și alegeți Executare ca administrator.
3. Rulați certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

Dezactivarea adăugării acestei extensii va elimina protecția oferită de noua extensie. Luați în considerare să faceți acest lucru numai după una dintre următoarele:

1. Confirmați că certificatele corespunzătoare nu sunt acceptate pentru criptografia cu cheie publică pentru autentificarea inițială (PKINIT) în autentificările cu protocolul Kerberos de la KDC
2. Certificatele corespunzătoare au alte mapări puternice de certificate configurate

Mediile care au implementări non-Microsoft CA nu vor fi protejate utilizând noua extensie SID după instalarea actualizării Windows din 10 mai 2022. Clienții afectați ar trebui să colaboreze cu distribuitorii CA corespunzători pentru a rezolva acest lucru sau ar trebui să ia în considerare utilizarea altor mapări puternice ale certificatelor descrise mai sus.

Pentru resurse suplimentare și asistență, consultați secțiunea "Resurse suplimentare".

Nu, reînnoirea nu este necesară. CA va fi livrată în modul de compatibilitate. Dacă doriți o mapare puternică utilizând extensia ObjectSID, veți avea nevoie de un certificat nou.

În actualizarea Windows din 11 februarie 2025, dispozitivele care nu sunt deja în impunere (valoarea de registry StrongCertificateBindingEnforcement este setată la 2) vor fi mutate în Impunere. Dacă autentificarea este refuzată, veți vedea ID-ul de eveniment 39 (sau ID-ul de eveniment 41 pentru Windows Server 2008 R2 SP1 și Windows Server 2008 SP2). În această etapă, veți avea opțiunea de a seta valoarea cheii de registry înapoi la 1 (Mod compatibilitate).

În actualizarea Windows din 9 septembrie 2025, valoarea de registry StrongCertificateBindingEnforcement nu va mai fi acceptată.