VPN के जरिए SQL Server अब भी 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 खुद पंजीकृत कर सकता है जब उसके सेवा खाते के पास उन्हें लिखने की अनुमति हो, जो सुविधाजनक है और यह भी समझाता है कि सेवा खाता बदलने के बाद नकल कैसे दिखती है।

आप जिस नाम की अपेक्षा करते हैं वह डायरेक्टरी से पूछें, फिर सूची बनाएँ कि खाते के पास वास्तव में क्या है। कौन-सी वस्तु प्रविष्टि रखती है, यह इससे अधिक महत्वपूर्ण है कि नाम फ़ॉरेस्ट में कहीं मौजूद है या नहीं। बेमेल का अर्थ है कि लॉगिन कभी समस्या थी ही नहीं, और 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 आवश्यक हो, तो दर्ज करें कि पहला रास्ता क्यों लौटा, एक सुधार लागू करें और उसी क्लाइंट से क्वेरी फिर चलाएँ। लॉन्चर बदलने के बाद सफल क्वेरी पहुँच का सबूत है, और यह अभी सबूत नहीं है कि प्रमाणीकरण की आवश्यकता पूरी हुई।