מדוע SQL Server דרך VPN עדיין נופל חזרה ל-NTLM?

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

ההפעלה נוקבת בשם הסכימה שבאמת קיבלתם

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

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

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

תנאי ראשון: האם השם תואם ל-SPN?

Kerberos מאמת שירות בעל שם, ולכן הלקוח מבקש מהספרייה כרטיס עבור זהות ראשית אחת מסוימת. עבור ספק ה-TCP הצורה המתועדת היא MSSQLSvc/ ואחריה שם המארח המלא, ועבור מופע ברירת מחדל גם הפורט. מופע בעל שם רושם MSSQLSvc/db01.corp.example:SQLPROD, כאשר הסיומת היא שם המופע במקום מספר. הגעה למאזין דרך כינוי, דרך CNAME שנפתר במקום אחר או דרך כתובת IP חשופה משנה את השם המבוקש, ולבקשה בלי זהות ראשית מתאימה אין כרטיס להחזיר.

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

תנאי שני: האם ה-SPN בחשבון הנכון?

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

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

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

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

תנאי שלישי: האם הלקוח יכול בכלל להשיג כרטיס?

SPN נכון חסר תועלת אם הלקוח אינו יכול להגיע לבקר תחום או שאין לו הקשר אישורים שמיש. ההחלפה זקוקה ל-KDC ול-DNS דרך ה-VPN, ומנהרה שמנתבת רק את פורט SQL נכשלת בדיוק בשלב הזה. יש לבדוק נגישות מאותו מחשב ומאותו חשבון, לא מחומת האש שלפניהם.

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

klist
klist -li 0x3e7

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

החלפת המשגר היא משתנה אחד, לא תיקון

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

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

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