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

לא נמצאו מיפויי אישורים חזקים, והאישור לא כלל את הסיומת החדשה של מזהה האבטחה (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 למידע נוסף. משתמש: <שם ראשי> נושא אישור: <הנושא בתיבה אישור> Issuer certificate issuer: <Issuer Fully Qualified Domain Name (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 למידע נוסף. משתמש: <שם ראשי> נושא אישור: <הנושא בתיבה אישור> Issuer certificate issuer: <Issuer FQDN> מספר סידורי של אישור: <הסידורי של אישור> טביעת אצבע של אישור: <טביעת אצבע של אישור> זמן הנפקת אישור: <FILETIME of certificate> זמן יצירת חשבון: <FILETIME של אובייקט ראשי ב- AD>

ה- 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 של מנהל אימות> נושא אישור: <הנושא בתיבה אישור> Issuer certificate issuer: <Issuer FQDN> מספר סידורי של אישור: <הסידורי של אישור> טביעת אצבע של אישור: <טביעת אצבע של אישור> SID של אישור: <SID נמצא באישור הרחבת האישור>

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

• Issuer: CN=CONTOSO-DC-CA, DC=contoso, DC=com

• SerialNumber: 2B0000000011AC000000012

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

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

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

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

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

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

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

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

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

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

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

• חפש אירועים רלוונטיים ביומן האירועים של המערכת בבקר התחום שהחשבון מנסה לאמת מולו.

• אם האישור ישן יותר מהחשבון, החזר את האישור או הוסף מיפוי altSecurityIdentities מאובטח לחשבון (ראה מיפויי אישורים).

• אם האישור מכיל סיומת SID, ודא שה- SID תואם לחשבון.

• אם האישור משמש לאימות חשבונות שונים אחדים, כל חשבון יצטרכו מיפוי altSecurityIdentities נפרד.

• אם האישור אינו כולל מיפוי מאובטח לחשבון, הוסף אותו או צא מהתחום במצב תאימות עד להוספה.

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

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

• בפרוטוקול Kerberos Certificate S4U, בקשת האימות זורמת משרת היישומים לבקר התחום, ולא מהלקוח לבקר התחום. לכן, אירועים רלוונטיים יהיו בשרת היישומים.

מפתח רישום זה משנה את מצב האכיפה של ה- KDC למצב לא זמין, מצב תאימות או מצב אכיפה מלאה.

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

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

Schannel ינסה למפות כל שיטת מיפוי אישורים שהפעלת עד שהאישור יצליח. Schannel מנסה למפות תחילה את מיפויי השירות למשתמש לעצמי (S4U2Self). מיפויי האישורים Subject/Issuer, Issuer ו- UPN נחשבים כעת לחלשים והוגדר כלא זמינים כברירת מחדל. הסכום של מסיכת הסיביות של האפשרויות שנבחרו קובע את רשימת שיטות מיפוי האישורים הזמינות.

ברירת המחדל של מפתח הרישום SChannel 0x1F והיא כעת 0x18. אם אתה נתקל בכשלים באימות עם יישומי שרת מבוססי Schannel, מומלץ לבצע בדיקה. הוסף או שנה את ערך מפתח הרישום CertificateMappingMethods בבקר התחום והגדר אותו 0x1F ובדוק אם פעולה זו מטפל בבעיה. עיין ביומני האירועים של המערכת בבקר התחום לקבלת מידע נוסף על השגיאות המפורטות במאמר זה. זכור כי שינוי ערך מפתח הרישום של SChannel בחזרה לברירת המחדל הקודמת (0x1F) יחזור להשתמש בשיטות מיפוי אישורים חלשות.

מפתח משנה של רישום	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel
‏‏ערך	CertificateMappingMethods
סוג נתונים	DWORD
‏‏נתונים	0x0001 - מיפוי אישור נושא/נושא (חלש – לא זמין כברירת מחדל) 0x0002 - מיפוי אישור הנפפיק (חלש – לא זמין כברירת מחדל) 0x0004 - מיפוי אישור UPN (חלש – לא זמין כברירת מחדל) 0x0008 - מיפוי אישור S4U2Self (חזק) 0x0010 - S4U2האישור המפורש מיפוי (חזק)
נדרשת הפעלה מחדש?	לא

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

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

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

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

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

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

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

1. היכנס לשרת רשות אישורים או ללקוח המצורף לתחום באמצעות Windows 10 ארגוני או עם האישורים המקבילים.

2. פתח שורת פקודה ובחר הפעל כמנהל מערכת.

3. הפעל את certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000. 

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

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

2. לאישורים המתאימים יש מיפויי אישורים חזקים אחרים שתצורתם נקבעה

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

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

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

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

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