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 लगइन र कुनै विशेष तालिका पढ्ने अनुमति तीन फरक नतिजा हुन्, र टिकट बन्द गर्नुअघि प्रत्येकले आफ्नै जाँच पाउनुपर्छ।