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 લોગિન અને ચોક્કસ કોષ્ટક વાંચવાની પરવાનગી એ ત્રણ અલગ પરિણામો છે, અને ટિકિટ બંધ કરતાં પહેલાં દરેકને પોતાની ચકાસણી લાયક છે.