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