ה-VPN מתחבר, אבל SQL Server דוחה אימות Windows

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

התסמין: שרת נגיש, כניסה נדחית

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

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

שתי זהויות, מנהרה אחת

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

חיבור מחשב אישי ל-VPN גם אינו מצרף אותו לדומיין. שינוי שם של חשבון מקומי והתאמת הסיסמה שלו למשתמש דומיין אינם הליך רישום, והם מייצרים אסימון שבקר הדומיין לא יקבל בתור אותו משתמש.

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

קראו את המצב שהלקוח ביקש

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

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

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

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

שאלו את השרת מה הוא באמת ראה

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

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

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

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

כשהזהות מגיעה ו-Kerberos עדיין נכשל

אם השרת רואה את זהות ה-Windows המיועדת והאימות המשולב עדיין נכשל, החליפין עצמו הוא הבעיה. Kerberos זקוק לשם השירות הראשי הרשום עבור חשבון שירות ה-SQL וללקוח שמבקש את השירות בשם שתואם לו. חיבור לפי כתובת IP אינו יכול להתאים ל-SPN מבוסס שם, וכינוי יכול להתאים רק אם גם הוא רשום. בדקו קודם את השם שהלקוח הקליד, כי חיבור שעובד לפי שם מארח ונכשל לפי IP מתאר בדיוק את הבעיה הזו.

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

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