KB5014754: שינויי אימות המבוססים על אישורים בבקרי תחום של Windows

חל על

Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Enterprise ESU Windows Server 2008 R2 Standard ESU Windows Server 2008 R2 Datacenter ESU Windows Server 2008 Service Pack 2 Windows Server 2016, all editions Windows Server, version 20H2, all editions Windows Server 2022 Windows Server 2019

יומן רישום שינויים

שנה תאריך	תיאור
9/10/2025	תוקן תאריך מצב האכיפה מ- 10 בספטמבר 2025 ל- 9 בספטמבר 2025.
9/8/2025	הוספתי הפניה לסעיף "משאבים נוספים"... יישום מיפוי חזק באישורי Intune.
7/29/2025	נוסף "בעיה ידועה" תחת הסעיף "פתרון בעיות"... אובייקט של מדיניות קבוצתית עשוי להפריע ל"מיפויים מבוססי שם"
10/24/2024	עודכן הטקסט לשם הבהרה, בשלב 2 של המקטע 'בצע פעולה', בתיאור 'מצב אכיפה מלאה' של הסעיף 'ציר זמן עבור עדכוני Windows', ותיקן את פרטי התאריכים בנושאים 'מפתח רישום של מרכז תפוצת מפתחות (KDC)' ו'מפתח רישום של אישורים המתוארכים לאחור' במקטע 'פרטי מפתח רישום'.
9/10/2024	שינה את התיאור של מצב אכיפה מלאה במקטע "תזמון עבור עדכוני Windows" כדי לשקף תאריכים חדשים. ב- 11 בפברואר 2025, המכשיר יעביר מכשירים למצב אכיפה, אך יעזוב את התמיכה כדי לחזור למצב תאימות. תמיכה מלאה במפתח רישום תסתיים מעכשיו ב- 9 בספטמבר 2025.
7/5/2024	נוסף מידע אודות סיומת SID למפתח הרישום של המרכז לתפוצת מפתחות (KDC) במקטע 'פרטי מפתח רישום'.
10/10/2023	נוסף מידע על שינויי ברירת מחדל של מיפויי חזקים תחת "ציר זמן עבור עדכונים של Windows"
6/30/2023	תאריך מצב אכיפה מלאה השתנה מ- 14 בנובמבר 2023 ל- 11 בפברואר 2025, (תאריכים אלה הופיעו בעבר כ- 19 במאי 2023 עד 14 בנובמבר 2023).
1/26/2023	הסרה של מצב לא זמין השתנתה מ- 14 בפברואר 2023 ל- 11 באפריל 2023.

Summary

CVE-2022-34691,CVE-2022-26931 ו-CVE-2022-26923 מטפלים בהסלמה של פגיעות הרשאות שעלולה להתרחש כאשר המרכז לתפוצת מפתחות (KDC) של Kerberos משרת בקשת אימות מבוססת אישור. לפני עדכון האבטחה של 10 במאי 2022, אימות מבוסס אישור לא התייחס לסימן דולר ($) בסוף שם מחשב. זה איפשר לחקות (לזייף) תעודות קשורות בדרכים שונות. בנוסף, התנגשויות בין שמות ראשיים של משתמשים (UPN) ו- sAMAccountName גרמו לפגיעויות אמולציה (התחזות) אחרות שאנו מטפלים בהן גם בעדכון אבטחה זה.

נקוט פעולה

כדי להגן על הסביבה שלך, השלם את השלבים הבאים לאימות מבוסס-אישור:

עדכן את כל השרתים שמפעילים Active Directory Certificate Services ובקרי תחום של Windows אשר משרתים אימות מבוסס-אישורים באמצעות העדכון של 10 במאי 202,2 (ראה מצב תאימות). העדכון של 10 במאי 2022 יספק אירועי ביקורת המזהים אישורים שאינם תואמים למצב אכיפה מלאה.
אם לא נוצרים יומני אירועי ביקורת בבקרי תחום במשך חודש אחד לאחר התקנת העדכון, המשך להפיכת מצב 'אכיפה מלאה ' לזמין בכל בקרי התחומים. עד פברואר 2025, אם מפתח הרישום StrongCertificateBindingEnforcement אינו מוגדר, בקרי התחום יעברו למצב אכיפה מלאה. אחרת, הגדרת מצב התאימות של מפתחות הרישום תמשיך להיות מכובדת. במצב אכיפה מלאה, אם אישור נכשל בקריטריוני המיפוי החזקים (המאובטחים) (ראה מיפויי אישורים), האימות יידחה. עם זאת, האפשרות לחזור למצב תאימות תישאר עד להתקנת עדכון האבטחה של Windows ב- 9 בספטמבר 2025.

ביקורת אירועים

עדכון Windows מ- 10 במאי 2022 מוסיף את יומני האירועים הבאים.

אין מיפוי חזק

לא נמצאו מיפויי אישורים חזקים, והאישור לא כלל את הסיומת החדשה של מזהה האבטחה (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 מנפיק> מספר סידורי של אישור: <מספר סידורי של אישור> טביעת אצבע של אישור: <טביעת אצבע של אישור> זמן הנפקת אישור: <זמן הקובץ של אישור> שעת יצירת חשבון: <זמן קובץ של אובייקט ראשי ב- AD>

ה- SID של המשתמשים אינו תואם SID של אישור

ה-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 נמצא בהרחבת האישור החדשה>

מיפויי אישורים

מנהלי תחומים יכולים למפות אישורים באופן ידני למשתמש ב- Active Directory באמצעות התכונה altSecurityIdentities של אובייקט המשתמשים. ישנם שישה ערכים נתמכים עבור תכונה זו, כאשר שלושה מיפויים נחשבים חלשים (לא בטוחים) ושלושת האחרים נחשבים לחזקים. באופן כללי, סוגי מיפויים נחשבים לחזקים אם הם מבוססים על מזהים שלא ניתן לעשות בהם שימוש חוזר. לכן, כל סוגי המיפויים המבוססים על שמות משתמשים וכתובות דואר אלקטרוני נחשבים חלשים.

מיפוי	דוגמה	Type	הערות
X509מנפיקנושא	"x509:<I>issuerName<s>subjectName"	חלש
X509נושא בלבד	"X509:<S>SubjectName"	חלש
X509RFC822	"X509:<RFC822>user@contoso.com"	חלש	כתובת דואר אלקטרוני
X509IssuerSerialNumber	"X509:<I>IssuerName<SR>1234567890"	חזק	מומלץ
X509SKI	"X509:<SKI>123456789abcdef"	חזק
X509SHA1PublicKey	"X509:<SHA1-PUKEY>123456789abcdef"	חזק

אם לקוחות אינם יכולים להנפיק מחדש אישורים עם הרחבת SID החדשה, אנו ממליצים ליצור מיפוי ידני באמצעות אחד מהמיפויים החזקים המתוארים לעיל. באפשרותך לעשות זאת על-ידי הוספת מחרוזת המיפוי המתאימה לתכונה משתמשים altSecurityIdentities ב- Active Directory.

מיפוי ידני של אישורים

הערה שדות מסוימים, כגון 'מנפיק', 'נושא' ו'מספר סידורי', מדווחים בתבנית "העברה". עליך להפוך תבנית זו בעת הוספת מחרוזת המיפוי לתכונה altSecurityIdentities . לדוגמה, כדי להוסיף את מיפוי X509IssuerSerialNumber למשתמש, חפש בשדות "מנפיק" ו"מספר סידורי" של האישור שברצונך למפות למשתמש. ראה את הפלט לדוגמה להלן.

מנפיק: CN=CONTOSO-DC-CA, DC=CONTOSO, DC=com
מספר סידורי: 2B0000000011AC0000000012

לאחר מכן, עדכן את התכונה altSecurityIdentities של המשתמש ב- Active Directory במחרוזת הבאה:

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

כדי לעדכן תכונה זו באמצעות Powershell, ייתכן שתשתמש בפקודה הבאה. זכור כי כברירת מחדל, רק למנהלי תחומים יש הרשאה לעדכן תכונה זו.

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

שים לב שבעת הפיכת המספר הסידורי, עליך לשמור על סדר הבתים. פירוש הדבר הוא שהיפוך המספר הסידורי "A1B2C3" אמור להביא למחרוזת "C3B2A1" ולא ל- "3C2B1A". לקבלת מידע נוסף, ראה 'כיצד לבצע': מיפוי משתמש לאישור באמצעות כל השיטות הזמינות בתכונה altSecurityIdentities.

ציר זמן עבור עדכוני Windows

חשוב שלב ההפעלה מתחיל בעדכונים של 11 באפריל 2023 עבור Windows, שיתעלמו מהגדרת מפתח הרישום של מצב לא זמין.

מצב תאימות

לאחר התקנת עדכוני Windows ב- 10 במאי 2022, המכשירים יהיו במצב תאימות. אם ניתן למפות אישור בצורה חזקה למשתמש, האימות יתבצע כצפוי. אם ניתן למפות אישור בצורה חלשה בלבד למשתמש, האימות יתבצע כצפוי. עם זאת, הודעת אזהרה תירשם אלא אם האישור ישן יותר מהמשתמש. אם האישור ישן יותר מהמשתמש ומפתח הרישום של אישור לתאריך לאחור אינו קיים או אם הטווח נמצא מחוץ לפיצוי התאריך לאחור, האימות ייכשל ותתוצג הודעת שגיאה. אם מפתח הרישום של אישור לתאריך לאחור מוגדר, הוא ירשום הודעת אזהרה ביומן האירועים אם התאריכים נכללים בפיצוי התאריך לאחור.

לאחר התקנת עדכוני Windows של 10 במאי 2022, שים לב להודעת אזהרה שעלולה להופיע לאחר חודש או יותר. אם אין הודעות אזהרה, מומלץ להפוך את מצב 'אכיפה מלאה' לזמין בכל בקרי התחומים באמצעות אימות מבוסס-אישורים. באפשרותך להשתמש במפתח הרישום של KDC כדי להפעיל מצב אכיפה מלאה.

מצב אכיפה מלאה

אלא אם עודכן למצב ביקורת או למצב אכיפה באמצעות מפתח הרישום StrongCertificateBindingEnforcement מוקדם יותר, בקרי תחום יעברו למצב אכיפה מלאה כאשר עדכון האבטחה של Windows של פברואר 2025 יותקן האימות יידחה אם לא ניתן למפות אישור בצורה חזקה. האפשרות לחזור למצב תאימות תישאר עד להתקנת עדכון האבטחה של Windows ב- 9 בספטמבר 2025. לאחר תאריך זה, לא תהיה עוד תמיכה במפתח הרישום StrongCertificateBindingEnforcement

מצב לא זמין

אם אימות מבוסס-אישורים מסתמך על מיפוי חלש שלא ניתן להזיז מהסביבה, באפשרותך למקם בקרי תחום במצב לא זמין באמצעות הגדרת מפתח רישום. Microsoft אינה ממליצה על כך, ואנו נסיר את מצב לא זמין ב- 11 באפריל 2023.

שינויי ברירת מחדל של מיפוי חזק

לאחר התקנת עדכוני Windows ב- 13 בפברואר 2024 ואילך ב- Server 2019 ואילך ותמכת בלקוחות שבהם מותקנת התכונה האופציונלית RSAT, מיפוי האישורים במשתמשי Active Directory & מחשבים יבחר כברירת מחדל מיפוי חזק באמצעות X509IssuerSerialNumber במקום מיפוי חלש באמצעות X509IssuerSubject. עדיין ניתן לשנות את ההגדרה כרצונך.

פתרון בעיות

אובייקט של מדיניות קבוצתית עשוי להפריע ל"מיפויים מבוססי שם"

מאפייני הבעיה

Microsoft קיבלה דיווחים כי ההגדרה "עבד גם אם אובייקטי מדיניות קבוצתית לא השתנו" תחת אובייקט מדיניות קבוצתית "תצורת> המחשב,תבניות מנהליות>, מדיניות קבוצתיתשל המערכת>: קביעת> תצורה של עיבוד מדיניות רישום" עלול להפריע לסירוגין למיפויים מבוססי השם בבקרי תחום.

פתרון

כדי לעקוף בעיה זו, הפוך את ההגדרה 'עבד גם אם אובייקטי מדיניות קבוצתית לא השתנו' בבקרי תחום. עשה זאת רק אם יש צורך במיפויים מבוססי שמות כמוגדר ב- מדיניות קבוצתית "מערכת>> תבניות > ניהול של תצורת> מחשב,אפשר מיפויי חזק מבוססי שם עבור אישורים". לקבלת מידע נוסף, ראה הפיכת מיפוי מבוסס שם חזק לזמין בתרחישים ממשלתיים.

השלב הבא

אנו חוקרים דוחות אלה ונספק מידע נוסף כאשר הוא יהיה זמין.

כשל בכניסה לאחר התקנת הגנות CVE-2022-26931 ו- CVE-2022-26923

השתמש ביומן התפעולי של Kerberos במחשב הרלוונטי כדי לקבוע איזה בקר תחום נכשל בכניסה. עבור אל מציג האירועים>יומני\ רישום של יישומים ושירותיםMicrosoft \Windows\Security-Kerberos\Operational.
חפש אירועים רלוונטיים ביומן אירועי המערכת בבקר התחום שמולו החשבון מנסה לבצע אימות.
אם האישור ישן יותר מהחשבון, הנפק מחדש את האישור או הוסף מיפוי altSecurityIdentities מאובטח לחשבון (ראה מיפויי אישורים).
אם האישור מכיל סיומת SID, ודא שהוא תואם לחשבון.
אם האישור משמש לאימות מספר חשבונות שונים, כל חשבון יזדקק למיפוי altSecurityIdentities נפרד.
אם האישור אינו כולל מיפוי מאובטח לחשבון, הוסף מיפוי או השאר את התחום במצב תאימות עד שניתן יהיה להוסיף מיפוי כזה.

כשל באימות באמצעות מיפוי אישורים של Transport Layer Security (TLS)

דוגמה למיפוי אישורי TLS משתמשת ביישום אינטרנט של אינטרא-נט IIS.

לאחר התקנת הגנות CVE-2022-26391 ו - CVE-2022-26923 , תרחישים אלה משתמשים בפרוטוקול Kerberos Certificate Service For User (S4U) למיפוי ואימות אישורים כברירת מחדל.
בפרוטוקול Kerberos Certificate S4U, בקשת האימות זורמת משרת היישומים לבקר התחום, ולא מהלקוח לבקר התחום. לכן, האירועים הרלוונטיים יופיעו בשרת האפליקציות.

פרטי מפתח רישום

לאחר התקנת הגנות CVE-2022-26931 ו- CVE-2022-26923 בעדכוני Windows שהופצו בין 10 במאי 2022 ל- 9 בספטמבר 2025 ואילך, מפתחות הרישום הבאים זמינים.

מפתח רישום של המרכז לתפוצת מפתחות (KDC)

מפתח רישום זה לא ייתמך לאחר התקנת עדכונים עבור Windows שיופצו בספטמבר 2025 או לאחר מכן.

הערה

חשוב
השימוש במפתח רישום זה הוא פתרון זמני עבור סביבות שדורשות זאת, ויש לבצע אותו בזהירות. השימוש במפתח רישום זה פירושו הדברים הבאים עבור הסביבה שלך:
מפתח רישום זה פועל רק במצב תאימות החל מעדכונים שהופצו ב- 10 במאי 2022.
מפתח רישום זה לא ייתמך לאחר התקנת עדכונים עבור Windows שפורסמו ב- 9 בספטמבר 2025.
הזיהוי והאימות של סיומת SID שבהם משתמשת אכיפת איגוד אישורים חזקה תלויים בערך UseSubjectAltName של מפתח הרישום של KDC. הסיומת SID תהיה בשימוש אם ערך הרישום אינו קיים או אם הערך מוגדר לערך של 0x1. הסיומת SID לא תהיה בשימוש אם UseSubjectAltName קיים, והערך מוגדר ל - 0x0.

מפתח משנה של רישום	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Value	StrongCertificateBindingEnforcement
סוג נתונים	REG_DWORD
נתונים	1 - בודק אם יש מיפוי אישורים חזק. אם כן, אימות מותר. אחרת, ה-KDC יבדוק אם האישור כולל את סיומת ה-SID החדשה ויאמת אותה. אם סיומת זו אינה קיימת, אימות מותר אם חשבון המשתמש קדם לאישור. 2 – בדיקה אם קיים מיפוי אישורים חזק. אם כן, אימות מותר. אחרת, ה-KDC יבדוק אם האישור כולל את סיומת ה-SID החדשה ויאמת אותה. אם סיומת זו אינה קיימת, האימות נדחה. 0 – משבית בדיקת מיפוי אישורים חזקה. לא מומלץ מכיוון שפעולה זו תהפוך את כל שיפורי האבטחה ללא זמינים. אם תגדיר את הערך ל- 0, תצטרך גם להגדיר את CertificateMappingMethods 0x1F כמתואר בסעיף מפתח הרישום Schannel להלן כדי שאימות מבוסס אישורים במחשב יצליח.
נדרשת הפעלה מחדש?	לא

מפתח הרישום של 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
נתונים	0x0001 - מיפוי אישור נושא/מנפיק (חלש - לא זמין כברירת מחדל) 0x0002 - מיפוי אישור מנפיק (חלש - לא זמין כברירת מחדל) 0x0004 - מיפוי אישורי UPN (חלש - לא זמין כברירת מחדל) 0x0008 - מיפוי אישורים S4U2Self (חזק) 0x0010 - S4U2Self מיפוי אישורים מפורש (חזק)
נדרשת הפעלה מחדש?	לא

לקבלת משאבים נוספים ותמיכה, עיין בסעיף 'משאבים נוספים'.

אישור תאריך לאחור מפתח רישום

לאחר התקנת עדכונים שפונים ל- CVE-2022-26931 ו - CVE-2022-26923, האימות עשוי להיכשל במקרים שבהם אישורי המשתמש ישנים יותר מזמן היצירה של המשתמש. מפתח רישום זה מאפשר אימות מוצלח כאשר אתה משתמש במיפויי אישורים חלשים בסביבה שלך והזמן לאישור הוא לפני זמן יצירת המשתמש בטווח מוגדר. מפתח רישום זה אינו משפיע על משתמשים או מחשבים עם מיפויי אישורים חזקים, מכיוון שזמן האישור וזמן יצירת המשתמש אינם נבדקים באמצעות מיפויי אישורים חזקים. למפתח רישום זה אין השפעה כאשר StrongCertificateBindingEnforcement מוגדר כ- 2.

השימוש במפתח רישום זה הוא פתרון זמני עבור סביבות שדורשות זאת, ויש לבצע אותו בזהירות. השימוש במפתח רישום זה פירושו הדברים הבאים עבור הסביבה שלך:

מפתח רישום זה פועל רק במצב תאימות החל מעדכונים שהופצו ב- 10 במאי 2022. אימות יהיה מותר במסגרת היסט הפיצוי לאחור, אך אזהרת יומן אירועים תירשם עבור האיגוד החלש.
הפיכת מפתח רישום זה לזמין מאפשרת לאמת את המשתמש כאשר זמן האישור קודם לזמן יצירת המשתמש בטווח מוגדר כמיפוי חלש. מיפויים חלשים לא ייתמכו לאחר התקנת עדכונים עבור Windows שהופצו בספטמבר 2025 או לאחר מכן.

מפתח משנה של רישום	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Value	תעודBackdatingCompensation
סוג נתונים	REG_DWORD
נתונים	ערכים לפתרון בשנים משוערות: 50 שנה: 0x5E0C89C0 25 שנים: 0x2EFE0780 10 שנים: 0x12CC0300 5 שנים: 0x9660180 3 שנים: 0x5A39A80 שנה: 0x1E13380 הערה אם אתה יודע את אורך החיים של האישורים בסביבה שלך, הגדר מפתח רישום זה למעט יותר ארוך ממשך החיים של האישור. אם אינך יודע מהם משכי הזמן של האישורים עבור הסביבה שלך, הגדר מפתח רישום זה ל- 50 שנה. קבע ברירות מחדל ל- 10 דקות כאשר מפתח זה אינו קיים, התואם ל- Active Directory Certificate Services (ADCS). הערך המרבי הוא 50 שנה (0x5E0C89C0). מפתח זה מגדיר את הפרש הזמן, בשניות, שמרכז תפוצת המפתחות (KDC) יתעלם ממנו בין זמן הנפקת אישור אימות לבין זמן יצירת חשבון עבור חשבונות משתמש/מחשב. חשוב הגדר מפתח רישום זה רק אם הסביבה שלך דורשת זאת. השימוש במפתח רישום זה משבית את בדיקת האבטחה.
נדרשת הפעלה מחדש?	לא

רשויות אישורים ארגוניות

רשויות אישורים ארגוניות (CA) יתחילו להוסיף הרחבה חדשה שאינה קריטית עם מזהה אובייקטים (OID) (1.3.6.1.4.1.311.25.2) כברירת מחדל בכל האישורים שהונפקו כנגד תבניות מקוונות לאחר התקנת עדכון Windows ב- 10 במאי 2022. באפשרותך להפסיק את ההוספה של הרחבה זו על-ידי הגדרת הסיבית 0x00080000 בערך msPKI-Enrollment-Flag של התבנית המתאימה.

דוגמה

עליך להפעיל את הפקודה certutil הבאה כדי לא לכלול אישורים של תבנית המשתמש בקבלת ההרחבה החדשה.

היכנס אל שרת רשות אישורים או לקוח Windows 10 המצורף לתחום עם מנהל ארגון או אישורים מקבילים.
פתח שורת פקודה ובחר לפעול כמנהל מערכת.
הפעל certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

הפיכת ההוספה של הרחבה זו ללא זמינה תסיר את ההגנה שמספקת ההרחבה החדשה. שקול לבצע זאת רק לאחר אחת מהפעולות הבאות:

אתה מאשר שהאישורים המתאימים אינם קבילים עבור הצפנת מפתח ציבורי לאימות ראשוני (PKINIT) באימות פרוטוקול Kerberos ב- KDC
לאישורים המתאימים מוגדרים מיפויי אישורים חזקים אחרים

סביבות הכוללות פריסות של רשות אישורים שאינם של Microsoft לא יהיו מוגנות באמצעות הרחבת SID החדשה לאחר התקנת עדכון Windows ב- 10 במאי 2022. הלקוחות המושפעים צריכים לעבוד עם ספקי רשות האישורים המתאימים כדי לטפל בבעיה זו, או לשקול להשתמש במיפויי אישורים חזקים אחרים שתוארו לעיל.

לקבלת משאבים נוספים ותמיכה, עיין בסעיף 'משאבים נוספים'.

שאלות נפוצות

לאחר עדכון רשות האישורים, האם יש לחדש את כל אישורי אימות הלקוח?

לא, אין צורך בחידוש. רשות האישורים תישלח במצב תאימות. אם אתה מעוניין במיפוי חזק באמצעות הסיומת ObjectSID, תזדקק לאישור חדש.

כיצד ישפיע מצב אכיפה מלאה על הסביבה שלי?

ב- 11 בפברואר 2025, עדכון Windows, מכשירים שאינם נמצאים כבר באכיפה (ערך הרישום StrongCertificateBindingEnforcement מוגדר ל- 2) יועברו לאכיפה. אם האימות נדחה, תראה את מזהה האירוע 39 (או מזהה האירוע 41 עבור Windows Server 2008 R2 SP1 ו- Windows Server 2008 SP2). בשלב זה תהיה לך אפשרות להגדיר את ערך מפתח הרישום בחזרה ל- 1 (מצב תאימות).

ב- 9 בספטמבר 2025, עדכון Windows, ערך הרישום StrongCertificateBindingEnforcement לא ייתמך עוד.

משאבים נוספים

לקבלת מידע נוסף אודות מיפוי אישורי לקוח TLS, עיין במאמרים הבאים: