SMB signing ו-LDAP channel binding — לסגור בעבודה המעשית את "החצי השני" של הגנת NTLM
· עודכן בתאריך: · Go Komura · NTLM, Kerberos, Windows, Active Directory, אבטחה, מערכות מידע, SMB, LDAP, PowerShell
“התחלנו לבצע audit ל-NTLM, ואנחנו מתקנים גם חיבורים שכתבו כתובת IP ישירות. אז איך מתכוננים לתקיפות relay בחודשים שנדרשים עד שמסלקים כל תלות?”
ההגנה לתקופה הזאת היא SMB signing, יחד עם LDAP signing ו-LDAP channel binding. אלה אינן הגדרות שעוצרות את NTLM עצמו; הן הגדרות שחוסמות, בכל יעד, תקיפות שמעבירות אימות לחיבור אחר. מפעילים אותן במקביל לצמצום NTLM, ומתייחסים אליהן כ-hardening שנשאר גם אחרי ש-NTLM מוסר.12
הגישה זהה בשניהם: audit → לתקן את האפליקציות וההתקנים שמתחברים → לאכוף. אבל ההגדרות שבודקים והאירועים שקוראים שונים בין SMB ל-LDAP. המאמר מפריד קודם בין התפקידים, ואחר כך מסביר לכל אחד מהם את הבדיקה, את התיקון ואת תהליך ההטמעה.
זהו המאמר השלישי בסדרת NTLM. את נוהל ה-audit של NTLM אפשר לקרוא ב-“האם ביטול NTLM יעצור אפליקציות עסקיות?”, ואת אופן הפעולה של פרוטוקולי האימות ב-“NTLM ו-Kerberos באיורים”.
1. קודם כל המסקנה: מפרידים בין שלוש ההגנות לפי היעד
| הגנה | ממה היא מגנה, והתפקיד שלה | מה בודקים לפני אכיפה |
|---|---|---|
| SMB signing | מזהה שינוי לרעה והתחזות בהודעות SMB, כמו אלה שמשמשות לשיתוף קבצים | אם היעד והמקור תומכים ב-signing, ואם נעשה שימוש בגישת guest |
| LDAP signing | דוחה SASL binds שלא דורשים signing, ו-simple binds על חיבורים בטקסט גלוי | האפליקציות וההתקנים שמייצרים חיבורים לא חתומים |
| LDAP channel binding | קושר אימות Windows (SASL bind) מעל LDAPS ל-TLS channel הזה | אם הלקוח יודע לטפל ב-channel binding token (CBT) |
LDAP signing הוא אימות שלמות, LDAPS הוא הצפנת TLS של כל החיבור, ו-channel binding הוא הקישור בין האימות ל-TLS channel. “עברנו ל-LDAPS” ו”אנחנו מאמתים CBT” אינם אותו דבר. בנוסף, ל-simple bind אין CBT והוא מחוץ לאימות של channel binding. פרקים 5 ו-6 מסבירים כל אחד מהם בנפרד.34
ב-SMB, Windows 11 24H2 במהדורות Enterprise, Pro ו-Education דורש signing כברירת מחדל בשני הכיוונים, ו-Windows Server 2025 דורש אותו כברירת מחדל בצד היוצא. מהדורת Home מחוץ לשינוי הזה, ולכן בודקים גם את המהדורה ולא רק את גרסת ה-OS.5
ב-LDAP, לעומת זאת, סדרת העדכונים ב-KB4520412 שאליה המאמר מפנה אינה משנה את מדיניות ברירת המחדל של signing או של channel binding. צריך להבדיל בין התקנת העדכון לבין הגדרת אכיפה. אין להכליל את מה שכתוב בעדכון הזה לברירת מחדל של כל OS וכל תנאי פריסה; בודקים את התצורה של הסביבה שמולכם.4
| מה שרוצים לדעת, או מה שנתקע | איפה לקרוא |
|---|---|
| רוצים להבין איך צמצום NTLM קשור לדרישת signing | פרק 2: למה signing עובד נגד תקיפות relay |
| רוצים לבדוק את ההשפעה על SMB לפני עדכון ה-OS | פרק 3: ברירות מחדל ואיך עובד ה-signing, פרק 4: מ-audit להטמעה |
| NAS או מדפסת משולבת לא מצליחים להתחבר לתיקייה משותפת | סעיף 4.3: שגיאות signing וחסימת guest |
| רוצים לדרוש signing בלי לשבור אינטגרציות LDAP | פרק 5: סוגי bind, אירועים ונוהל האכיפה |
| רוצים להתכונן ל-relay של אימות מעל LDAPS | פרק 6: מה מכסה CBT ואיך מגדירים אותו |
| רוצים לתקן את ההתקנים ואת אפליקציות ה-.NET שה-audit מצא | פרק 7: טבלת החלטות לתיקונים, עם דוגמאות קוד |
ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 28, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle
2. למה צריך signing: הגנה במקביל לצמצום NTLM
2.1. אפשר להעביר את האימות הלאה, אבל אי אפשר לייצר חתימה תקפה
החולשה הבסיסית של NTLM היא שאין בו אימות הדדי. כיוון שהלקוח אינו יכול לאמת את זהות השרת, תוקף יכול להתחזות לשרת האמיתי, לגרום ללקוח להזדהות מולו, ולהעביר את תגובת האימות הזאת לשרת האמיתי. זו תקיפת ה-relay. גם Microsoft מתעדת שאימות NTLM ו-NTLMv2 חשוף ל-SMB relay ולתקיפות man-in-the-middle.2
עצירה מלאה של NTLM מייתרת את ה-NTLM relay. אבל מיפוי ותיקון התלויות שנסקרו במאמר הראשון נמשכים חודשים. מה שמגן על היעדים בינתיים הוא ה-signing.
flowchart LR
CL["לקוח"]
AT["תוקף<br/>(שרת מזויף)"]
SV["שרת אמיתי"]
CL -->|"1. תגובת אימות"| AT
AT -->|"2. מועבר כמו שהוא"| SV
SV -.->|"3. אם signing נדרש:<br/>לתוקף אין session key<br/>והוא לא יכול לייצר חתימה תקפה, ולכן זה נכשל"| AT
איור 1: תוקף שהעביר רק את תגובת האימות אינו יכול לייצר חתימה תקפה מה-session key
כתוצאה מהאימות, מי שמחזיקים ב-session key שמשמש ל-signing הם הלקוח והשרת האמיתי. תוקף שהעביר רק את תגובת האימות אינו מחזיק במפתח הזה ואינו יכול לזייף הודעות המשך בחיבור שבו signing נדרש. חלוקת העבודה היא SMB signing לתקיפות relay לתוך SMB, ו-LDAP signing יחד עם channel binding לתקיפות relay לתוך LDAP/LDAPS של domain controller.
2.2. גם אחרי שדורשים signing, ממשיכים לעבור ל-Kerberos
כדי להפיק יותר מ-signing, בודקים גם את שיטת האימות. כיוון שה-session key נגזר מהסיסמה, מומלץ להשתמש ב-Kerberos ולא ב-NTLMv2 כדי להתחיל ממפתח חזק יותר. Microsoft מונה גם את ההימנעות משימוש בכתובות IP או ב-CNAME לחיבור לשיתוף.1
הסיבה היא שחיבור לפי כתובת IP, או לפי alias שלא נרשם לו SPN מתאים, גורם לשימוש ב-NTLM ולא ב-Kerberos. רישום SPN ל-alias שממשיכים להשתמש בו נסקר במאמר הראשון.
צמצום התלויות ב-NTLM ודרישת signing הם מהלכים שמבצעים במקביל. גם זיהוי שינוי לרעה דרך signing וגם channel binding חלים על sessions שאומתו ב-Kerberos, ולכן אלה אינן הגדרות שמסירים אחרי ש-NTLM מוסר.1
3. SMB signing: לבדוק איך זה עובד ומה ברירות המחדל
3.1. להפריד בין “תומך ב-signing” לבין “דורש signing”
SMB signing מצרף חתימה לכל הודעה בעזרת ה-session key ו-cipher suite. החתימה בכותרת ה-SMB כוללת hash של כל ההודעה ושל זהות השולח והמקבל, ולכן היא מפסיקה להתאים אם משהו בדרך שונה לרעה. זהו זיהוי ה-tampering, והוא מה שמגן מפני התחזות ו-relay.1
הציר שבודקים בתצורה אינו מופעל מול מושבת, אלא האם signing נדרש. מ-SMB 2.x ואילך EnableSecuritySignature מתעלמים ממנו, ורק ל-RequireSecuritySignature יש משמעות. אם הלקוח או השרת דורשים אותו, החיבור הזה נחתם. חיבור נשאר בלי חתימה רק כששני הצדדים אינם דורשים אותה.1
ל-signing יש עלות חישובית, אבל האלגוריתם עבר מ-MD5 ב-SMB1 ל-HMAC-SHA-256 ב-SMB 2.02 ול-AES-CMAC ב-SMB 3.0, וב-Windows Server 2022 וב-Windows 11 נוספה האצה שמבוססת על AES-128-GMAC. אין לדחות את זה בגלל רושם ישן ש-signing איטי; מודדים על מכונת pilot ומחליטים לפי התוצאה.1
3.2. לבדוק את ה-OS, את המהדורה ואת הכיוון היוצא והנכנס
מתחילים בבדיקת המהדורה והגרסה של ה-OS תחת Settings > System > About. בטבלה שלמטה, יוצא (outgoing) הוא המחשב שמתחבר כלקוח SMB, ונכנס (incoming) הוא זה שמקבל חיבורים כשרת SMB. מחפשים את השורה שאליה נכנסים המחשבים והשרתים שלכם.
| OS / מהדורה | יוצא (לקוח) | נכנס (שרת) |
|---|---|---|
| Windows 11 24H2 Enterprise / Pro / Education | נדרש | נדרש |
| Windows Server 2025 | נדרש | לא נדרש |
| Windows 11 24H2 Home | לא נדרש | לא נדרש |
| Windows / Windows Server קודמים | לא נדרש | לא נדרש |
| Domain controller (התנהגות ותיקה) | — | נדרש (לחיבורים ל-SYSVOL ול-NETLOGON) |
שלוש השורות העליונות הן ברירות מחדל ש-Microsoft מציינת במפורש.5 השורה התחתונה, ה-domain controller, היא תנאי נפרד ותיק: הוא דורש SMB signing מכל דבר שמתחבר ל-SYSVOL או ל-NETLOGON. הפצת Group Policy וסקריפטים של logon עבדה זה זמן רב בהנחה ש-signing פעיל.1
גם ב-Windows 11 24H2, מהדורת Home אינה דורשת signing באף כיוון והיא מחוץ לשינוי ברירת המחדל הזה. הטענה שעדכון מחשב Home לבדו הופך את signing לנדרש אינה נכונה. הטבלה אינה ערובה לשינויים עתידיים או להגדרות נקודתיות, ולכן כשנתקלים בכשל חיבור בודקים את המהדורה, ואחר כך גם את הערכים בפועל מסעיף 4.1.5
במהדורות Enterprise, Pro ו-Education, עדכון ל-24H2 הופך חיבורי SMB מהמחשב הזה לכאלה שדורשים signing כברירת מחדל. Windows עצמו תומך ב-signing, ולכן הגורמים שכדאי למפות קודם הם התקנים של צד שלישי שאינם תומכים בו או שהשביתו אותו. בודקים יחידות NAS ישנות, את ההגדרות שקשורות ל-scan-to-folder במדפסות משולבות, Samba על Linux משובץ וכדומה.
4. SMB signing: audit, לתקן את ההתקנים ואז לדרוש
4.1. לבדוק את דרישת ה-signing הנוכחית ואת המדיניות שמנהלת אותה
# דרישת signing בצד הלקוח (יוצא)
Get-SmbClientConfiguration | FL RequireSecuritySignature
# דרישת signing בצד השרת (נכנס)
Get-SmbServerConfiguration | FL RequireSecuritySignature
True פירושו נדרש, False פירושו לא נדרש. בודקים בנפרד את הצד היוצא ואת הצד הנכנס.5
ב-Group Policy הן מנוהלות תחת Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. משתמשים בשתי ההגדרות הבאות, כל אחת לתפקיד שלה.1
| תפקיד | מדיניות |
|---|---|
| לקוח (יוצא) | Microsoft network client: Digitally sign communications (always) |
| שרת (נכנס) | Microsoft network server: Digitally sign communications (always) |
המילה “always” בשם המדיניות היא זו שמשמעותה “נדרש”. אם עוד לא יודעים אילו התקנים אינם תומכים, לא אוכפים את זה בכל מקום בשלב הזה; עוברים ל-audit שלמטה.
4.2. לאתר ב-audit את הגורמים שלא יכולים לחתום
מ-Windows 11 24H2 ואילך זמין audit שמזהה לקוחות ושרתים של צד שלישי שאינם תומכים ב-signing או בהצפנה. הפקודות הבאות מפעילות אותו עבור signing.1
# צד השרת: זיהוי לקוחות שאינם תומכים ב-signing
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
# צד הלקוח: זיהוי שרתים שאינם תומכים ב-signing
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true
צד השרת בוחן את הלקוחות שמתחברים אליו; צד הלקוח בוחן את השרתים שאליהם הוא מתחבר. ב-Group Policy, המקבילות הן הגדרות כמו “Audit client does not support signing” תחת Lanman Server ו-Lanman Workstation ב-Computer Configuration\Administrative Templates\Network.1
לאותה תכונת audit יש גם -AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption לאיתור גורמים שאינם תומכים בהצפנה. אבל אלה הכנה לדרישת הצפנת SMB בעתיד. יש התקנים שתומכים ב-signing אבל לא בהצפנה, ולכן אין לערבב את תוצאות ה-audit של ההצפנה בהחלטה שאכיפת ה-signing מוכנה.1
היומנים ומזהי האירועים שבהם משתמשים ה-audit של signing וההצפנה הם אלה. קוראים גם את גוף האירוע ומאמתים שזו אכן בעיית ה-signing שנחקרת כאן.1
| יומן | Event ID |
|---|---|
| Applications and Services Logs\Microsoft\Windows\SMBClient\Audit | 31998, 31999 |
| Applications and Services Logs\Microsoft\Windows\SMBServer\Audit | 3021, 3022 |
ב-Event Viewer בודקים כך.
- פותחים
eventvwr.mscועוברים ל-Applications and Services Logs > Microsoft > Windows > SMBClient > Audit. בצד השרת פותחים באותה רמה את SMBServer > Audit. - משתמשים ב-“Filter Current Log” בחלונית הימנית ומציינים את מזהי האירועים
31998,31999, או3021,3022בצד השרת. - פותחים את האירועים, בודקים את סוג הבעיה ואת הפרטים על הגורם שזוהה, ובונים רשימה של התקנים שלא יכולים לחתום.
כדי לאסוף אותם בכמות עם PowerShell, משתמשים בדוגמה הבאה.
# צד הלקוח: אירועי audit שזיהו שרתים שאינם תומכים ב-signing
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message
# צד השרת: אירועי audit שזיהו לקוחות שאינם תומכים ב-signing
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message
הדוגמה הזאת מביאה יחד את מזהי ה-audit של signing ושל הצפנה. אין להתייחס לכל אירוע שמוצג כמקרה של חוסר תמיכה ב-signing; מפרידים בין signing להצפנה לפי Message.
אם אין אירועים מתאימים — למשל מיד אחרי הפעלת ה-audit — Get-WinEvent מחזיר שגיאה של “לא נמצאו אירועים”. ה--ErrorAction SilentlyContinue בדוגמה נועד להשתיק אותה. על איך לכתוב את הסינון ראו גם “חקירת יומני אירועים באופן מעשי עם Get-WinEvent”.
מריצים את ה-audit, כמו ב-audit של NTLM, עד שמחזור העבודה משלים סיבוב מלא. יומנים מיד אחרי ההפעלה אינם שקולים לבדיקת כל היעדים.
4.3. לתקן בנפרד שגיאות signing וחסימת guest
חיבור מסביבה שדורשת signing אל גורם שאינו יכול לחתום מפיק את השגיאה הבאה.5
0xc000a000
STATUS_INVALID_SIGNATURE
The cryptographic signature is invalid.
המקרה השני הוא דחייה של גישת guest. גם גישת guest אינה יכולה לשמש בחיבור שדורש signing, ולכן NAS שמשתמשים בו בלי אימות מפיק שגיאה כמו זו.5
You can't access this shared folder because your organization's security policies
block unauthenticated guest access.
הטיפול הראשון הוא להפעיל SMB signing בהתקן ולהתחבר עם credentials ולא כ-guest. אם צריך, שוקלים עדכון firmware או שינוי בנתיב החיבור.
ה-workaround של Set-SmbClientConfiguration -RequireSecuritySignature $false בצד הלקוח מרפה את צד שגיאת ה-signing. חסימת ה-guest נשלטת גם בהגדרת לקוח נפרדת שאוסרת guest logons לא מאובטחים, ולכן הסרת דרישת ה-signing לבדה אינה מבטלת את הדחייה של חיבורי guest.
Microsoft אינה ממליצה להשבית signing כ-workaround להתקנים של צד שלישי, וגם לא לנסות להשתמש ב-signing עם חשבון guest.5 גם כשבאמת צריך להרפות משהו, לא הופכים אותו לנוהג קבוע; מנהלים אותו כחריגה מוגבלת בזמן עד החלפת ההתקן.
4.4. לעבור מ-pilot להטמעה מלאה
| שלב | מה עושים | איך יודעים שסיימנו |
|---|---|---|
| 1. Audit | מפעילים את ה-audit מסעיף 4.2 ואוספים אירועים על מחזור עבודה מלא | יש רשימה של הגורמים שאינם תומכים ב-signing |
| 2. תיקון התקנים | מפעילים signing בהגדרות ה-SMB של יחידות NAS, מדפסות משולבות ומכונות Linux. מעבירים מ-guest ל-credentials | לא מופיעים עוד אירועי audit של signing |
| 3. Pilot | מחילים RequireSecuritySignature $true לפני כולם על כמה מכונות, למשל מחשבי מחלקת ה-IT |
מחזור עבודה אחד עובר בלי בעיות |
| 4. הטמעה | מפיצים לכולם דרך Group Policy. עוקבים אחרי התקנים שאי אפשר לתקן ברשם כחריגות מוגבלות בזמן | מספר החריגות קטן מספיק כדי לנהל |
ככל שיותר מהדורות עוברות ל-24H2 ואילך, כך יותר לקוחות דורשים signing כברירת מחדל. המועד האחרון בפועל נקבע לפי תוכנית עדכון ה-OS, ולכן כוללים את ה-audit הזה ואת תיקוני ההתקנים בעבודות המוקדמות למעבר ל-Windows 11. אסטרטגיית המעבר מ-Windows 10 נסקרת ב-“אפשרויות אחרי סיום התמיכה ב-Windows 10”.
5. LDAP signing: לבדוק את סוגי ה-bind לפני שאוכפים
אחרי SMB מגיעים חיבורי LDAP ל-domain controllers ול-AD LDS. תעבורת LDAP לא חתומה חשופה לתקיפות replay ו-man-in-the-middle, והשרת עלול לקבל החלטות על סמך בקשות שיורטו ושונו.3
מתחילים בהפרדה בין סוגי ה-“bind” שמשמשים לאימות.
| מונח | משמעות |
|---|---|
| SASL bind | bind שמשתמש ב-SASL (Simple Authentication and Security Layer), המסגרת שמעבירה אימות Windows (Negotiate, Kerberos, NTLM, Digest) מעל LDAP. אפשר לדרוש ממנו signing (אימות שלמות) |
| Simple bind | bind שמכניס את שם המשתמש והסיסמה ישירות לתוך בקשת ה-LDAP. אין לו מסגרת signing, ולכן בחיבור בטקסט גלוי הסיסמה עוברת כפי שהיא |
דרישת LDAP signing דוחה SASL binds שאינם דורשים signing ו-simple binds על חיבורים בטקסט גלוי (לא SSL/TLS). Signing הוא אימות שלמות, והוא נפרד מהצפנה. ל-simple bind אין מסגרת signing, ולכן כל מה שחייב להמשיך להשתמש ב-simple bind צריך לעבור ל-LDAPS.3
5.1. לקרוא את האירועים כ”ספירות” ו”מקורות” בנפרד
גם LDAP signing וגם channel binding בפרק הבא משתמשים ביומן ה-Directory Service של ה-domain controller. ב-Event Viewer פותחים Applications and Services Logs > Directory Service.
| אירוע | מה הוא מציין | חל על | מתי נרשם |
|---|---|---|---|
| 2886 | תזכורת שדרישת ה-signing אינה מוגדרת | LDAP signing | נרשם כברירת מחדל (באתחול Directory Service)3 |
| 2887 | ספירה של SASL binds לא חתומים ו-simple binds בטקסט גלוי ב-24 השעות האחרונות | LDAP signing | נרשם כברירת מחדל (כל 24 שעות)3 |
| 2888 | ספירה של binds בעייתיים שנדחו ב-24 השעות האחרונות | LDAP signing | כל 24 שעות אחרי הגדרת הדחייה3 |
| 2889 | כתובת ה-IP של מקור ה-bind הבעייתי, והזהות ששימשה לאימות | LDAP signing | לא נרשם כברירת מחדל. מגדירים את הגדרת האבחון “16 LDAP Interface Events” ל-23 |
| 3039 | לקוח שנכשל באימות CBT | Channel binding | עדכונים מ-10 במרץ 2020 ואילך4 |
| 3040 | ספירה של LDAPS binds לא מוגנים ב-24 השעות האחרונות | Channel binding | עדכונים מ-10 במרץ 2020 ואילך4 |
| 3041 | תזכורת שממליצה לעבור לאכיפה | Channel binding | עדכונים מ-10 במרץ 2020 ואילך4 |
| 3074 / 3075 | audit של לקוחות שאינם יכולים לתמוך ב-CBT | Channel binding | נוסף בעדכונים מאוגוסט עד נובמבר 2023. ב-Windows Server 2019 זמין בלי הפעלה ידנית מינואר 2024 ואילך4 |
ההבחנה שצריך לעשות היא בין אירועים מצטברים שמראים כמה נשאר (2887 ו-3040) לבין אירועים בודדים שמזהים את המקור (2889, 3039, 3074 ו-3075). כל עוד נשארים חיבורים בעייתיים, מתקנים אותם ולא עוברים לאכיפה.
הביטוי “זמין בלי הפעלה ידנית” בטבלה מתאר שהעדכון הופך את תכונת ה-audit לשמישה. אין לקרוא אותו כאילו האירועים תמיד מופיעים בכל תצורה; בודקים את ה-OS, את העדכונים שהותקנו ואת הגדרות האבחון מול KB4520412. פרק 6 מפריד גם את הנקודה ש-simple binds נמצאים מחוץ לאימות ה-CBT.4
5.2. עם 2887 רואים מה נשאר, ועם 2889 מזהים את המקור
ב-LDAP signing משתמשים ב-2886, 2887, 2888 ו-2889. 2886 הוא תזכורת שמזכירה להגדיר, 2887 הוא הספירה כל 24 שעות של binds בעייתיים, ו-2888 הוא הספירה אחרי שהדחייה מוגדרת. רק 2889, זה שמראה את המקור, חסר כברירת מחדל.3
קודם בודקים ב-2887 אם נשארו binds לא חתומים. אם הספירה אינה אפס, מגדירים את הגדרת האבחון “16 LDAP Interface Events” ל-2 (Basic) כדי ש-2889 יירשם, ומאתרים את כתובת ה-IP של המקור ואת הזהות ששימשה לאימות.3
2889 אינו אירוע מצטבר אלא רשומה לכל bind שנפגע. בסביבה שבה נשארים חיבורים בתדירות גבוהה הוא ממלא מהר את יומן ה-Directory Service, ולכן מחזירים את הגדרת האבחון לרמה המקורית (0 כברירת מחדל) אחרי זיהוי המקורות. אם מתכוונים להמשיך לרשום אותו, מסדרים קודם העברת יומנים וקיבולת שמירה.
מה שבודקים: אימות AD ואינטגרציה עם מערכת משאבי אנוש במערכות עסקיות, חיפוש בספר כתובות LDAP במדפסות משולבות, אימות LDAP בהתקני רשת וכדומה. התקנים במיוחד מוגדרים לעיתים קרובות ל-simple bind בטקסט גלוי, ולכן בודקים את הגדרות ה-LDAP שלהם. התיקון הוא מעבר ל-LDAPS (פורט 636) או ל-SASL bind חתום. פרק 7 מרכז דוגמאות קונקרטיות.
5.3. אחרי התיקונים דורשים signing, ומאמתים את התנהגות הדחייה
אחרי שהמקורות תוקנו, מגדירים ב-Group Policy את הדברים הבאים.3
| צד להגדיר | מה מגדירים |
|---|---|
| Domain controller | תחת “Security Options” ב-Default Domain Controller Policy, מגדירים את “Domain controller: LDAP server signing requirements” ל-Require signing |
| לקוח | מגדירים את “Network security: LDAP client signing requirements” ל-Require signing |
מאמתים את התצורה עם ldp.exe. מתחברים לפורט 389 בלי TLS ומנסים simple bind; אם מתקבלת השגיאה הבאה, הגדרת הדחייה פעילה. זהו מבחן של התנהגות הדחייה, ולא נוהל לעבודה עם binds בטקסט גלוי בפרודקשן. עושים זאת עם credentials שיועדו לבדיקה.3
Ldap_simple_bind_s() failed: Strong Authentication Required
6. LDAP channel binding: לבדוק גם את האימות מעל LDAPS
6.1. הצפנת TLS וקשירת האימות ל-channel הם שני דברים
LDAPS מצפין את התעבורה ב-TLS. אבל הצפנה לבדה אינה מספיקה מול relay שמאמת את הלקוח ואחר כך מעביר את האימות הזה לחיבור TLS נפרד משל התוקף. ה-channel binding token (CBT) הוא ערך שקושר את האימות ל-TLS channel עצמו, וכך הופך relay ל-channel אחר לזיהוי.4
מה שהוא מכסה: חיבורים שמבצעים אימות Windows (SASL bind) כמו NTLM או Kerberos מעל LDAPS. ל-simple bind אין CBT והוא מחוץ לאימות הזה. מה שמגן על simple bind מעל LDAPS הוא הצפנת TLS וניהול credentials; הגדרת הערך ל-Always לא תגרום ללקוחות simple bind להופיע באירועי ה-audit של CBT.
6.2. להתאים את הערכים 0, 1 ו-2 להגדרות המדיניות
שולטים בזה דרך ה-Registry ב-domain controller, או דרך הגדרת ה-Group Policy המתאימה.4
| הגדרה | מיקום / ערך |
|---|---|
| Registry | LdapEnforceChannelBinding (REG_DWORD) תחת HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters |
| משמעות הערכים | 0 = לא לאמת / 1 = לאמת כשהלקוח תומך / 2 = תמיד לאמת |
| Group Policy | “Domain controller: LDAP server channel binding token requirements” (Never / When supported / Always מתאימים ל-0/1/2 שלמעלה) |
When supported ו-Always אינם אותו דבר. מפרידים בין השלב שמאמת לקוחות שתומכים לבין השלב שדורש אימות תמיד בחיבורים שבכיסוי, ועוברים ל-Always רק אחרי שאימתתם את מצב התמיכה.
6.3. לאתר את המקורות עם 3039, 3040, 3074 ו-3075
הסתכלות מפורטת יותר באירועי channel binding מטבלת ההימצאות המהירה בסעיף 5.1 נותנת את הדברים הבאים. העדכון מ-10 במרץ 2020 הוסיף את האירועים הקשורים, ועדכונים מ-2023 ואילך הרחיבו את ה-audit.4
| אירוע | משמעות |
|---|---|
| 3039 | לקוח שביצע LDAP bind מעל SSL/TLS נכשל באימות channel binding token |
| 3040 | ספירה של LDAPS binds לא מוגנים שבוצעו ב-24 השעות האחרונות |
| 3041 | תזכורת שממליצה לאכוף אימות channel binding |
| 3074 / 3075 | אירועי audit ללקוחות שאינם יכולים לתמוך ב-channel binding (נוספו בעדכונים מאוגוסט עד נובמבר 2023; ב-Windows Server 2019 זמינים בלי הפעלה ידנית מינואר 2024 ואילך) |
גם נוהל ההטמעה של Microsoft עצמה עוקב אחרי אותו סדר: לנטר 2889, 3039 ו-3074/3075 ביומן ה-Directory Service ב-כל domain controller, לזהות את ההתקנים הבעייתיים, לבדוק מול הספקים שלהם, ולאכוף אחרי שטופלו.4
אין להתייחס למעבר ל-LDAPS כאל סוף העבודה; בודקים גם את שיטת האימות ואת התמיכה ב-CBT. ההבחנה מסעיף 6.1 גם מלמדת שלא לחפש simple binds שמחוץ לכיסוי רק באירועי ה-CBT.
6.4. אין להסיק שהתקנת העדכון סיימה את האכיפה
KB4520412 מציין שהעדכון מ-10 במרץ 2020, וסדרת העדכונים שהמסמך מכסה, אינם משנים את מדיניות ברירת המחדל של LDAP signing או של channel binding.4
לכן, בסביבה שבה רק הותקן העדכון ולא נאכף דבר, עבודת התצורה נשארת על המנהל. אין לבלבל את זה עם שינוי ברירת המחדל של SMB ב-24H2; מאמתים בנפרד שתכונת ה-audit זמינה ושההגנה נאכפת. כל עוד אפשר לבחור מתי לאכוף, מתכננים ומבצעים את התיקונים בצד המתחבר.
7. לתקן אפליקציות עסקיות והתקנים לפי הסיבה
7.1. להתאים בין הגורמים שמופיעים באירועים לבין התיקון
| מה נמצא | סיבה | איך מתקנים |
|---|---|---|
| סריקה ל-SMB במדפסת משולבת או בסורק (שגיאת signing) | ההתקן אינו תומך ב-SMB signing, או שהשבית אותו | מפעילים signing בהתקן. מעדכנים firmware. אם אי אפשר, מעבירים את נתיב המסירה מ-SMB (למשל למשלוח במייל) |
| חיבורי guest ל-NAS | עבודה בלי אימות | משנים לחיבור עם credentials. משביתים guest בצד השיתוף |
| חיפוש בספר כתובות LDAP במדפסת משולבת (2889) | simple bind בטקסט גלוי | משנים את הגדרות ה-LDAP של ההתקן ל-LDAPS (פורט 636) ומתקינים את תעודת ה-CA בהתקן |
| אינטגרציית אימות AD במערכת עסקית (2889) | התצורה היא simple bind בטקסט גלוי | עוברים ל-LDAPS בהגדרות המוצר, או ל-SASL (Negotiate) עם signing. בודקים את מצב התמיכה מול הספק |
| אפליקציית .NET שפותחה בבית (2889) | הקוד משתמש ב-AuthType.Basic עם פורט 389 |
תיקון הקוד שלמטה |
| 3039 מופיע למרות שמשתמשים ב-LDAPS | הספרייה בצד הלקוח אינה תומכת ב-CBT | מעדכנים OS וספרייה. אפליקציות שמשתמשות ב-LDAP stack הסטנדרטי של Windows מכוסות לרוב בעדכון OS, אבל ספריות עם מימוש עצמאי דורשות בדיקה נפרדת |
חוסר תמיכה ב-signing, עבודה עם guest, simple binds בטקסט גלוי וחוסר תמיכה ב-CBT — כל אחד מהם מתוקן במקום אחר. גם כשהתסמין זהה, “לא מצליח להתחבר”, אין להרפות הגדרות באופן גורף; בוחרים את התגובה לפי האירוע ולפי שיטת החיבור.
7.2. באפליקציות .NET בודקים את שיטת האימות ואת הגדרות ה-TLS
באפליקציית .NET שפותחה בבית בודקים קודם אם היא שולחת simple bind עם AuthType.Basic לפורט 389 בטקסט גלוי. הדוגמה הבאה היא דוגמה גרועה, כזו שנדחית ברגע שאוכפים LDAP signing. היא אינה דוגמה שנועדה לרוץ עם credentials אמיתיים.
// דוגמה גרועה: simple bind לפורט 389 בטקסט גלוי. נדחה ברגע שאוכפים LDAP signing
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));
בתיקון, אם סביבת ה-domain מאפשרת לבחור, קובעים כברירת מחדל Negotiate יחד עם בקשה ל-signing ולהצפנה. אם נדרש simple bind, משתמשים ב-LDAPS. שתי הדוגמאות שלמטה הן קטעים שמנגידים בין האפשרויות. הן לא נועדו לרוץ בהמשך לדוגמה הגרועה שלמעלה.
// דוגמה טובה 1: לבקש Negotiate יחד עם signing והצפנה (Kerberos נבחר כשה-SPN ופתרון השמות מסתדרים)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind(); // אימות בחשבון שתחתיו רץ התהליך
// דוגמה טובה 2: אם משתמשים ב-simple bind, תמיד דרך LDAPS
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));
ה-Negotiate בדוגמה הטובה 1 מעדיף Kerberos, אבל לא כופה אותו. בתנאים כמו חיבור לפי כתובת IP, או SPN שלא נרשם או שנרשם פעמיים, הוא נופל חזרה ל-NTLM. גם אז ה-signing וההצפנה שהקוד ביקש נכנסים לתוקף.
כדי לאמת שאימות Kerberos עובד, בודקים עם klist שהתקבל ticket לשירות המדובר. אם הגדרתם את ה-audit היוצא של NTLM במאמר הראשון ל-“Audit all”, היעדר אירוע 8001 הוא גם ראיה מחזקת. אבל להסיק “אין 8001” כשמדיניות ה-audit עדיין מושבתת לא אומר דבר.
ה-simple bind בדוגמה הטובה 2 מוצפן ב-TLS, אבל הוא אינו כפוף לאימות CBT. מה שחשוב הוא לא להתייחס אליו כאל אותה הגנה כמו בדוגמה הטובה 1. אם משתמשים ב-DirectoryEntry (ADSI), מציינים במפורש AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing.
העיקרון של כתיבת היעד כ-FQDN ולא ככתובת IP חל גם על SASL binds עם Kerberos. מתקנים יחד איתו גם את פתרון השמות ואת ה-SPNs, ולא עוצרים אחרי שהחליפו רק את שיטת האימות בקוד.
8. סיכום: להשלים audit, תיקון ואכיפה בכל נתיב
SMB signing, LDAP signing ו-LDAP channel binding אינם תחליף להגדרות שעוצרות את NTLM. הם הגנות שמונעות relay בזמן שמצמצמים את התלויות ב-NTLM, ו-hardening קבוע שנשאר גם אחרי המעבר ל-Kerberos.12
ב-SMB בודקים את ה-OS, את המהדורה ואת ברירות המחדל של הכיוון היוצא והנכנס, ומתקנים קודם את ההתקנים שאינם תומכים ב-signing ואת ההגדרות שמבוססות על guest. תוכנית העדכון למהדורות המושפעות של Windows 11 24H2 הופכת למועד האחרון של ההכנה הזאת. ב-LDAP בודקים binds לא חתומים דרך 2887 ו-2889 ובעיות שקשורות ל-CBT דרך 3039, 3040, 3074 ו-3075, ואוכפים רק אחרי שהמקורות תוקנו.534
התקנת עדכון, הפעלת תכונת audit ואכיפת הגנה הם שלבים נפרדים. במיוחד אין להסיק שהאכיפה הושלמה רק מפני שהותקנו עדכוני ה-LDAP מ-KB4520412. מאמתים זאת גם כשזוכרים ש-simple binds נמצאים מחוץ לאימות ה-CBT.4
באפליקציות שלכם, עצם הסרת ה-simple binds בטקסט גלוי וכתובות ה-IP שכתובות ישירות בקוד היא כבר שיפור גדול. את קו הסיום אין לשפוט לפי “שינינו את ההגדרה” אלא לפי האם השלמתם מחזור עבודה מלא של audit ותיקון, אימתתם את ההתנהגות ב-pilot ואז עברתם לאכיפה.
מאמרים קשורים
- האם ביטול NTLM יעצור אפליקציות עסקיות? — איך לאסוף יומני audit וסדר ביטול התלויות
- NTLM ו-Kerberos באיורים — למה האימות נופל ל-NTLM
- מלכודות של כונני רשת ונתיבי UNC — עבודה עם שרתי קבצים (תיקיות משותפות) מאפליקציה עסקית
- חקירת יומני אירועים באופן מעשי עם Get-WinEvent — מהירות הסינון קובעת את זמן החקירה
- אפשרויות מעשיות אחרי סיום התמיכה ב-Windows 10 — טבלת החלטות ל-ESU, LTSC והחלפה
- Checklist מינימלי לאבטחה בפיתוח אפליקציות Windows
תחומי ייעוץ קשורים
KomuraSoft LLC מטפלת בשינויים באפליקציות עסקיות שנדרשים בעקבות אכיפת SMB signing ו-LDAP signing, ובחקירת כשלי חיבור סביב אימות ושיתוף קבצים.
מקורות
-
Microsoft Learn, Overview of Server Message Block signing in Windows. על כך ש-SMB signing מצרף חתימה לכל הודעה בעזרת ה-session key ו-cipher suite; על כך שהחתימה בכותרת ה-SMB כוללת hash של כל ההודעה ושל זהות השולח והמקבל, ומספקת הגנה מפני תקיפות relay והתחזות; על כך ש-SMB1 חותם ב-MD5, SMB 2.02 ב-HMAC-SHA-256 ו-SMB 3.0 ב-AES-CMAC, ושב-Windows Server 2022 וב-Windows 11 הוצגה האצת signing ב-AES-128-GMAC; על כך שמ-SMB 2.x ואילך ההגדרה
EnableSecuritySignatureמתעלמים ממנה ורק ל-RequireSecuritySignatureיש השפעה, שהחתימה מתבצעת כשהלקוח או השרת דורשים אותה, ושמדלגים עליה רק כשאף אחד מהם אינו דורש; על כך ש-domain controllers דורשים כברירת מחדל SMB signing מכל גורם שמתחבר אליהם (SYSVOL ו-NETLOGON); על כך שה-session key נגזר מהסיסמה, ולכן מומלצים סיסמאות ארוכות ומורכבות ו-Kerberos, ושחיבור לפי כתובת IP או CNAME גורם לשימוש ב-NTLM ולא ב-Kerberos; על כך שמיקום המדיניות הוא “Microsoft network client/server: Digitally sign communications (always)” וערכי ה-Registry הםRequireSecuritySignatureתחת LanManWorkstation/LanManServer; ועל ה-audit שנוסף מ-Windows 11 גרסה 24H2 ואילך ומזהה לקוחות ושרתים של צד שלישי שאינם תומכים ב-signing או בהצפנה (Set-SmbServerConfiguration -AuditClientDoesNotSupportSigningוכדומה), שנרשם תחת SMBClient/Audit במזהי אירועים 31998 ו-31999 ותחת SMBServer/Audit במזהי אירועים 3021 ו-3022. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 -
Microsoft Learn, Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers. על כך שאימות NTLM ו-NTLMv2 חשוף למגוון תקיפות זדוניות, כולל SMB relay, תקיפות man-in-the-middle ותקיפות brute-force. ↩ ↩2 ↩3
-
Microsoft Learn, How to enable LDAP signing in Windows Server. על כך שהגדרת שרת ספרייה לדחות SASL LDAP binds (Negotiate, Kerberos, NTLM, Digest) שאינם דורשים signing (אימות שלמות) ודחיית LDAP simple binds על חיבורים בטקסט גלוי (לא SSL/TLS) משפרת מאוד את האבטחה; על כך שתעבורת רשת לא חתומה חשופה לתקיפות replay ו-man-in-the-middle, ושכתוצאה מכך שרת LDAP עלול לפעול לפי בקשה מזויפת; על כך ששינוי תצורה כזה שובר לקוחות שתלויים ב-binds האלה, ולכן יש לבדוק דרך אירוע 2887 (ספירה כל 24 שעות), ואירוע 2889 (שכולל את כתובת ה-IP של הלקוח ואת הזהות ששימשה לאימות) נרשם אחרי שמעלים את הגדרת האבחון “16 LDAP Interface Events” ל-2 (Basic); על כך שאירוע 2888 נאסף כל 24 שעות אחרי שהדחייה מוגדרת; על כך שאירוע 2886 נרשם באתחול ה-Directory Service כדי להזכיר להגדיר; על כך שהאכיפה דורשת להגדיר את “Domain controller: LDAP server signing requirements” ב-Default Domain Controller Policy ל-“Require signing”, ואת הצד הלקוח “Network security: LDAP client signing requirements” בהתאם; ועל כך שחיבור לפורט 389 עם
ldp.exeוניסיון simple bind שמחזיר “Ldap_simple_bind_s() failed: Strong Authentication Required” מעידים שהתצורה פעילה. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 -
Microsoft Support, 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows (KB4520412). על כך ש-LDAP channel binding ו-LDAP signing הם אמצעים לשיפור האבטחה של התקשורת בין לקוחות LDAP ל-Active Directory domain controllers; על משמעות ערך ה-Registry
LdapEnforceChannelBinding(HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, DWORD) — 0 = לא לאמת אף פעם, 1 = לאמת אם הלקוח תומך, 2 = תמיד לאמת — ועל הגדרת ה-Group Policy המתאימה “Domain controller: LDAP server channel binding token requirements”; על כך שהעדכון מ-10 במרץ 2020 הוסיף אירועים חדשים שקשורים ל-channel binding (3039 = לקוח שביצע LDAP bind מעל SSL/TLS ונכשל באימות channel binding token, 3040 = ספירה של LDAPS binds לא מוגנים ב-24 השעות האחרונות, 3041 = המלצה לאכוף); על כך שהעדכונים מאוגוסט עד נובמבר 2023 הוסיפו את אירועי ה-audit 3074 ו-3075 ללקוחות שאינם יכולים לתמוך ב-channel binding, ושהם זמינים ב-Windows Server 2019 מינואר 2024 ואילך בלי הפעלה ידנית; על כך שהעדכון מ-10 במרץ 2020 והעדכונים הנוכחיים אינם משנים את מדיניות ברירת המחדל של LDAP signing או של LDAP channel binding; ועל נוהל הפריסה של ניטור אירועים 2889, 3039, 3074 ו-3075 בכל ה-domain controllers כדי לזהות התקנים בעייתיים, לבדוק מול הספקים שלהם, ורק אחר כך לאכוף. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 -
Microsoft Learn, Control SMB signing behavior. על כך ש-Windows 11 גרסה 24H2 במהדורות Enterprise, Pro ו-Education דורש SMB signing בחיבורים יוצאים ובנכנסים; על כך ש-Windows Server 2025 דורש SMB signing רק בצד היוצא; על כך ש-Windows 11 גרסה 24H2 Home אינו דורש signing לא ביציאה ולא בכניסה; על כך שחיבור לשרת SMB של צד שלישי שאינו מתיר signing מפיק את השגיאה 0xc000a000 (STATUS_INVALID_SIGNATURE, “The cryptographic signature is invalid”); על כך שחיבור להתקני צד שלישי שמשתמשים בחשבונות guest מפיק שגיאה כמו “You can’t access this shared folder because your organization’s security policies block unauthenticated guest access”; על כך שדרישת signing גם משביתה גישת guest; על כך ש-Microsoft אינה ממליצה להשבית SMB signing ולא לנסות לחתום עם חשבונות guest כ-workaround לשרתי צד שלישי; ועל ההגדרה דרך הפרמטר
-RequireSecuritySignatureשלSet-SmbClientConfiguration/Set-SmbServerConfigurationוהבדיקה דרךGet-SmbClientConfiguration/Get-SmbServerConfiguration. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
מאמרים קשורים
מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.
האם הוצאת NTLM משימוש תעצור את אפליקציות העסק? — איך לאסוף לוגי ביקורת ובאיזה סדר לחסל תלויות
המאמר מסביר איך מאתרים היכן Windows ואפליקציות עסקיות תלויות ב-NTLM: מדיניות ביקורת, אירועים 8001-8004 ביומן NTLM/Operational, הסיבות והת...
NTLM מול Kerberos בהדגמה — למה האימות "נופל" ל-NTLM
השוואה מאוירת בין NTLM ל-Kerberos: challenge/response מול כרטיסים, TGT ו-service tickets, התנאים שבהם Negotiate נופל ל-NTLM כשאין SPN, מת...
למה תיקייה משותפת ב-Windows עובדת לפעמים ונכשלת בפעמים אחרות — troubleshooting של Kerberos, NTLM ו-Credentials
מאבחנים גישה לסירוגין לתיקייה משותפת ב-Windows לפי תסמינים ולוגים. בודקים שמות מול כתובות IP, כשלים רק באפליקציה, סיסמאות ריקות, שגיאה 12...
Windows LAPS — להפסיק סיסמת Administrator מקומית משותפת לכל המחשבים
סיסמת Administrator מקומית משותפת לכל המחשבים היא כר פורה ל-Pass-the-Hash: פריצה למחשב אחד מתפשטת לכל השאר. המאמר מסביר את הסיבוב האוטומט...
סדר name resolution ב-Windows — hosts, DNS cache, LLMNR/mDNS ו-DoH
האם hosts, ה-DNS cache, שרת DNS או LLMNR/mDNS ענו קובע למה חלק מהמחשבים נכשלים. לומדים את סדר name resolution ב-Windows, מה DoH משנה, ואי...
נושאים קשורים
העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.
נושאים טכניים ב-Windows
שער לנושאי פיתוח Windows, חקירת תקלות וניצול נכסים קיימים.
שירותים הקשורים לנושא הזה
המאמר קשור ישירות לשירותים הבאים.
פיתוח יישומי Windows
יישומים עסקיים, חיבור התקנים וכלי תקשורת, מהגדרת הדרישות ועד הפיתוח.
שאלות נפוצות
שאלות נפוצות בפניות בנושא המאמר.
- אם נדרוש SMB signing, שרת הקבצים לא יאט?
- לחתימה יש עלות חישובית, אבל האלגוריתמים השתפרו בכל דור. מול MD5 ב-SMB1, ב-SMB 2.02 עברו ל-HMAC-SHA-256 וב-SMB 3.0 ל-AES-CMAC, וב-Windows Server 2022 וב-Windows 11 נוספה האצת signing שמבוססת על AES-128-GMAC. גם domain controllers דורשים מזה זמן SMB signing מכל גורם שמתחבר ל-SYSVOL ול-NETLOGON, ולכן הפצת Group Policy עבדה תמיד בהנחה ש-signing פעיל. לפני שמוותרים בגלל ביצועים, מומלץ להפוך אותו לחובה קודם על מכונת pilot ולמדוד. הבדל מורגש מופיע רק בדפוסי שימוש מסוימים, כמו העברה רציפה של קבצים גדולים.
- ה-NAS הפסיק להתחבר אחרי המעבר ל-Windows 11 24H2. האם SMB signing הוא הסיבה?
- בדרך כלל כן. ב-Windows 11 גרסה 24H2, מהדורות Enterprise, Pro ו-Education, SMB signing נדרש כברירת מחדל הן בחיבורים יוצאים והן בנכנסים, ולכן חיבור ל-NAS של צד שלישי שאינו תומך ב-signing (או שהשבית אותו) נכשל עם 0xc000a000 (STATUS_INVALID_SIGNATURE). דרישת signing גם משביתה גישת guest, ולכן ב-NAS שמוגדר לעבודה בלי אימות מתקבלת השגיאה "You can't access this shared folder because your organization's security policies block unauthenticated guest access." הטיפול הראשון הוא להפעיל SMB signing בצד ה-NAS ולהתחבר עם credentials ולא כ-guest. יש workaround בצד הלקוח שמבטל את דרישת ה-signing, אבל הוא פותר רק את צד שגיאת ה-signing. חסימת חיבורי guest נשלטת בהגדרת לקוח נפרדת (איסור guest logons לא מאובטחים) ולא ב-signing, ולכן הם ימשיכו להיכשל עד שלא מרפים גם בהגדרה הזאת. Microsoft אינה ממליצה להשבית signing ולא לעבוד עם חשבונות guest.
- מה ההבדל בין LDAP signing ל-LDAPS (LDAP over SSL/TLS)?
- אלה שני דברים שונים. LDAP signing דורש אימות שלמות (signing) על SASL binds (Negotiate, Kerberos, NTLM, Digest) שמתבצעים על חיבור LDAP בפורט 389, והוא אינו מצפין את התעבורה. LDAPS מצפין את כל החיבור ב-SSL/TLS. LDAP channel binding היא שכבה נוספת מעל LDAPS: היא קושרת את האימות ל-TLS channel ובכך מונעת תקיפות שמעבירות רק את ה-credentials לחיבור TLS אחר. כדי להגן על domain controller כדאי לחשוב על שלושה צעדים יחד: להפסיק simple binds בטקסט גלוי, לדרוש signing על SASL binds, ולדרוש אימות של channel binding token לאימות Windows (SASL binds) מעל LDAPS. שימו לב של-simple bind אין CBT והוא מחוץ לאימות של channel binding; מה שמגן על simple bind מעל LDAPS הוא הצפנת ה-TLS עצמה.
- באיזה סדר מהדקים את ההגדרות האלה?
- הסדר הוא audit, ואז תיקון, ואז אכיפה — בדיוק כמו בהגבלת NTLM. מתחילים ב-SMB: מפעילים את ה-audit שקיים מ-Windows 11 24H2 ואילך ומזהה גורמים שאינם תומכים ב-signing, ומשתמשים בו כדי למפות את ההתקנים שלא יכולים לחתום. ב-LDAP בודקים ב-Directory Service log של ה-domain controller את אירוע 2887 (ספירת binds לא חתומים כל 24 שעות); אם הספירה אינה אפס, מגדירים את הגדרת האבחון "16 LDAP Interface Events" ל-2 ומזהים את הלקוחות מאירוע 2889. ב-channel binding עושים אותו דבר עם אירועים 3039 ו-3040 ועם אירועי ה-audit 3074 ו-3075 שנוספו בעדכונים מ-2023 ואילך. אחרי שכל מקור בעייתי תוקן, עוברים לאכיפה: דורשים SMB signing, דורשים LDAP signing, ומעבירים את channel binding ל-Always. העיקרון היחיד הוא לא לקפוץ ישר לאכיפה.