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

כמה תעודות, אחת מוצעת

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

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

בדקו את המאגר לפני עריכת הפרופיל

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

Get-VpnConnection -Name 'Office' | Select-Object Name, TunnelType, AuthenticationMethod
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList

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

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

מסנן המנפיק רוצה אובייקט

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

$issuerPath = Read-Host 'Certificate-provider path for the approved issuer CA'
$issuer = Get-Item -LiteralPath $issuerPath
Set-VpnConnection -Name 'Office' -MachineCertificateIssuerFilter $issuer

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

מסנן השימוש רוצה מחרוזת OID

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

Set-VpnConnection -Name 'Office' -MachineCertificateEKUFilter '1.3.6.1.5.5.7.3.2'

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

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

הוכיחו איזו תעודה הלקוח הציע

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

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

מאמרים קשורים