VPN जोडले जाते, पण SQL Server Windows प्रमाणीकरण नाकारते

टनल वर येतात, सर्व्हर 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 चा अर्थ ओळखपत्र स्वीकारले पण सर्व्हरवरील प्रवेश अयशस्वी झाला. प्रशासकाला संपूर्ण संदेशाऐवजी स्थिती विचारा, कारण संदेश एकटा जाणूनबुजून अस्पष्ट आहे.

ओळख आली तरी Kerberos अजूनही अयशस्वी होत असताना

सर्व्हरला इच्छित Windows ओळख दिसत असूनही एकात्मिक प्रमाणीकरण अजूनही अयशस्वी होत असल्यास समस्या देवाणघेवाणीतच आहे. Kerberos ला SQL सेवा खात्यासाठी नोंदवलेले सेवा प्रमुख नाव (SPN) आणि त्याशी जुळणाऱ्या नावाने सेवा मागणारा क्लायंट आवश्यक आहे. IP पत्त्याने कनेक्ट केल्यास नाव-आधारित SPN शी जुळू शकत नाही, आणि टोपणनाव तेही नोंदवले असेल तरच जुळू शकते. सर्वात आधी क्लायंटने टाइप केलेले नाव तपासा, कारण होस्टनावाने काम करणारे आणि IP ने अयशस्वी होणारे कनेक्शन नेमकी हीच समस्या वर्णन करते.

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

प्रमाणीकरण काम केल्यानंतरही लॉगिनला डेटाबेस वापरकर्ता आणि परवानग्या लागतात. यशस्वी VPN लॉगिन, यशस्वी Windows लॉगिन आणि विशिष्ट तक्ता वाचण्याची परवानगी या तीन वेगळ्या निकाल आहेत, आणि तिकीट बंद करण्यापूर्वी प्रत्येकाला स्वतःची तपासणी हवी आहे.