VPN कनेक्ट होता है, पर SQL Server Windows प्रमाणीकरण अस्वीकार करता है
VPN लॉगिन काम करता है, SQL Server Windows प्रमाणीकरण अस्वीकार करता है: टनल खाते की तुलना क्लाइंट के टोकन से करें, फिर सर्वर पर auth_scheme पढ़ें।
टनल उठते हैं, सर्वर 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;Windows लॉगिन विफल होने पर SQL लॉगिन पर जाना एक ऐसा वैकल्पिक उपाय है जो पहचान का सवाल छिपा देता है, और इसके लिए आमतौर पर नया लॉगिन और पासवर्ड बनाना फिर भी पड़ता है। अगर परिनियोजन को 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 अनुमान के बजाय दृश्य तथ्य बन जाते हैं। जहाँ आपने Kerberos की अपेक्षा की वहाँ NTLM की सूचना देने वाला कनेक्शन पासवर्ड की समस्या नहीं, नाम-समाधान या SPN की समस्या है।
त्रुटि संख्या इसे और सँकरा करती है। स्थिति 5 का अर्थ आमतौर पर यह है कि लॉगिन नाम बिल्कुल हल नहीं हुआ, स्थिति 8 का अर्थ आमतौर पर यह है कि पासवर्ड मेल नहीं खाया, और स्थिति 11 का अर्थ है कि क्रेडेंशियल स्वीकार हुआ पर सर्वर तक पहुँच विफल रही। व्यवस्थापक से पूरा संदेश नहीं, स्थिति माँगें, क्योंकि संदेश अकेला जानबूझकर अस्पष्ट है।
| What you observe | What it suggests |
|---|---|
| Timeout, no listener | Route, firewall or wrong port |
| Login failed, state 5 | Name not resolved in the domain |
| Login failed, state 11 | Authenticated but no server access |
| Connected as NTLM | Target name or SPN mismatch |
जब पहचान आती है और Kerberos अब भी विफल होता है
अगर सर्वर इच्छित Windows पहचान देखता है और एकीकृत प्रमाणीकरण अब भी विफल होता है, तो समस्या विनिमय ही है। Kerberos को SQL सेवा खाते के लिए पंजीकृत सेवा प्रमुख नाम (SPN) और ऐसा क्लाइंट चाहिए जो उससे मेल खाते नाम से सेवा माँगे। IP पते से कनेक्ट करना नाम-आधारित SPN से मेल नहीं खा सकता, और उपनाम तभी मेल खा सकता है जब वह भी पंजीकृत हो। सबसे पहले वह नाम जाँचें जो क्लाइंट ने टाइप किया, क्योंकि होस्टनाम से काम करने वाला और IP से विफल होने वाला कनेक्शन ठीक इसी समस्या का वर्णन करता है।
व्यवस्थापक से अनुरोध करें कि वे परीक्षण-त्रुटि से नकली SPN बनाने के बजाय पंजीकृत पहचान और सेवा खाते की समीक्षा करें। नकली पंजीकरण रुक-रुककर विफलताएँ पैदा करते हैं जिनका निदान मूल समस्या से कठिन है।
प्रमाणीकरण काम करने के बाद भी लॉगिन को डेटाबेस उपयोगकर्ता और अनुमतियाँ चाहिए। सफल VPN लॉगिन, सफल Windows लॉगिन और किसी विशेष तालिका को पढ़ने की अनुमति तीन अलग परिणाम हैं, और टिकट बंद करने से पहले हर एक अपनी जाँच का हकदार है।