התחברות PIV נכשלת ב-Windows עם EAP-TLS? בדקו את נתיב החתימה

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

התחילו בפרופיל ובשיטת EAP

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

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

ודאו איזו תעודה נבחרה

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

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

בדקו את פעולת המפתח בלי לנחש את ה-PIN

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

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

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

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

קראו את שני הצדדים של לחיצת היד

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

אספו את אירועי Windows ואת האירועים בצד השרת עם חותמות זמן מיושרות, ואז זהו איזה צד יצר את הכשל הראשון. RFC 5216 מתאר את שלב הוכחת החזקה ב-EAP-TLS, והתרעת לחיצת יד כללית אינה נוקבת בעצמה בסיבה מקומית הקשורה למפתח. השוואת חותמות הזמן היא שהופכת שני יומנים לרצף.

שמרו על גבולות ברורים בדוח

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

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