VPN मधून SQL Server अजूनही NTLM वर का परततो?

तुमचे कनेक्शन कार्यरत आहे, लॉगिन स्वीकारले जाते, आणि सर्वांनी Kerberos अपेक्षित असताना SQL Server NTLM वापरत आहे. हा निकाल 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 नोंदवू शकतो, जे सोयीचे आहे आणि सेवा खाते बदलल्यानंतर प्रत कशी दिसते हेही स्पष्ट करते.

तुम्ही अपेक्षित असलेल्या नावाबद्दल डिरेक्टरीला विचारा, नंतर खात्याकडे प्रत्यक्षात काय आहे याची यादी करा. कोणत्या ऑब्जेक्टकडे नोंद आहे हे नाव जंगलात कुठेतरी आहे का यापेक्षा अधिक महत्त्वाचे आहे. विसंगती म्हणजे लॉगिन कधीच समस्या नव्हती, आणि Microsoft ची SPN मार्गदर्शिका स्वरूप आणि ज्या प्रकरणांमध्ये डोमेन प्रशासकाने नोंद तयार करावी लागते त्यांचे दस्तऐवजीकरण करते.

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

आणखी एक नोंद जोडणे सुरक्षित प्रयोग नाही. प्रत किंवा विरोधाभासी नोंदणी कार्यरत क्लायंट तोडू शकते, म्हणून बदलापूर्वी मालकी तपासा आणि नंतर पुन्हा तपासा.

तिसरी अट: क्लायंटला तिकीट मिळू शकते का?

क्लायंट डोमेन नियंत्रकापर्यंत पोहोचू शकत नसेल किंवा वापरण्यायोग्य क्रेडेन्शियल संदर्भ नसेल तर योग्य SPN निरुपयोगी आहे. देवघेवीला VPN मधून KDC आणि DNS आवश्यक आहे, आणि केवळ SQL पोर्ट मार्गित करणारा बोगदा नेमक्या याच टप्प्यावर अयशस्वी होतो. पोहोचक्षमता त्यांच्यासमोरील फायरवॉलवरून नाही, तर त्याच मशीन आणि त्याच खात्यातून तपासली पाहिजे.

मशीनवर आणि अनुप्रयोग चालवणाऱ्या खात्याखाली तिकीट कॅश तपासा. उन्नत विंडोमधून मिळालेली मशीन-व्यापी यादी दुसऱ्या वापरकर्त्याच्या रूपात चालणाऱ्या सेवेबद्दल काहीही सांगत नाही, आणि त्या वापरकर्त्यासाठी रिकामी कॅश असुविधा नसून एक शोध आहे.

klist
klist -li 0x3e7

मग माघार काय करू शकते हे ठरवा. धोरण Kerberos मागत असल्यास NTLM स्पष्टपणे नाकारले पाहिजे, कारण शांत माघार कॉन्फिगरेशन त्रुटीचे आवश्यकतेचे उल्लंघन करणाऱ्या कार्यरत कनेक्शनमध्ये रूपांतर करते. काही अनुप्रयोगांसाठी NTLM स्वीकार्य राहिल्यास त्यांची नावे द्या आणि प्रत्येक NTLM सत्राला घटना मानणे थांबवा.

लाँचर बदलणे हे एक चल आहे, उपाय नाही

दुसऱ्या क्रेडेन्शियलखाली SSMS सुरू केल्याने अनपेक्षित बाहेर जाणारी ओळख बरी होऊ शकते, जो समस्येचा खरा वर्ग आहे. ते लक्ष्य नाव, नोंदणी किंवा तिकिटाच्या मार्गाबद्दल काहीही सिद्ध करत नाही, आणि सर्व्हरने काय स्वीकारले ते बदलत नाही.

तुलना नियंत्रित ठेवा: तोच एंडपॉइंट, तोच प्रदाता, ज्ञात अंमलबजावणी संदर्भ, नंतर नवीन कनेक्शन ज्याची स्कीम तुम्ही तपासता. स्वीकारलेले लॉगिन आणि त्याच्या डेटाबेस परवानग्या स्वतंत्रपणे पुष्टी करा, कारण प्रवेश आणि प्रमाणीकरण वेगवेगळ्या कारणांमुळे अयशस्वी होतात.

Kerberos आवश्यक असल्यास पहिला मार्ग का मागे पडला ते नोंदवा, एक दुरुस्ती लागू करा आणि त्याच क्लायंटवरून क्वेरी पुन्हा चालवा. लाँचर बदलल्यानंतर यशस्वी क्वेरी हा प्रवेशाचा पुरावा आहे, आणि याची अजून पुरावा नाही की प्रमाणीकरणाची आवश्यकता पूर्ण झाली.