VPN દ્વારા SQL Server શા માટે હજી પણ NTLM પર પાછું જાય છે?

તમારું કનેક્શન કામ કરે છે, લોગિન સ્વીકારાય છે, અને દરેક જણ Kerberos ની અપેક્ષા રાખતું હતું ત્યારે SQL Server NTLM વાપરે છે. એ પરિણામ VPN ની ખામી નથી, કારણ કે ટનલ ફક્ત માર્ગ પૂરો પાડે છે; સ્કીમ નક્કી કર્યું ક્લાયન્ટે માંગેલા નામે, ડિરેક્ટરીમાં નોંધાયેલ principal અને ક્લાયન્ટ ખરેખર મેળવી શક્યું એ ટિકિટે. ત્રણ શરતો એકસાથે સાચી હોવી જોઈએ, અને સેશન પોતે કહે છે કે કઈ ઝૂકી. કોઈ સેવા પ્રિન્સિપાલ નામ સંપાદિત કરે તે પહેલાં આ વાંચો.

સેશન એ સ્કીમનું નામ આપે છે જે તમને ખરેખર મળી

પ્રમાણીકરણ સ્કીમ સર્વર કે ટનલની નહીં, કનેક્શનની હોય છે, તેથી તપાસ તમને જે સેશનની ચિંતા છે તેની અંદર ચલાવવી પડે. નીચેની ક્વેરી એ જ ક્લાયન્ટ, સાધન અને ખાતામાંથી ચલાવો જેમણે રિપોર્ટ બનાવ્યો, અને પરિણામની બાજુમાં લક્ષ્ય નામ અને પરિવહન નોંધો.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

ડેટાબેઝ હોસ્ટ પરની સ્થાનિક SSMS વિન્ડોની એક પંક્તિ સંપૂર્ણપણે અલગ કનેક્શનનું વર્ણન કરે છે, તેથી ક્વેરી ક્લાયન્ટ બાજુથી ચલાવવી પડે. આઉટપુટને સમય-છાપ સાથે સાચવો, કારણ કે તેને વાંચનાર આગલી વ્યક્તિ પૂછશે કે તે ક્યારે લેવાયું. જ્યારે ઘણી એપ્લિકેશનો એક એન્ડપોઇન્ટ વહેંચે, ત્યારે દરેકમાંથી નમૂનો લો, કારણ કે બે એપ્લિકેશનો વચ્ચે ડેટા-સ્રોતનો તફાવત ઘણી વાર આખી વાર્તા હોય છે.

પ્રથમ શરત: શું નામ SPN સાથે મેળ ખાય છે?

Kerberos નામવાળી સેવાનું પ્રમાણીકરણ કરે છે, તેથી ક્લાયન્ટ ડિરેક્ટરી પાસેથી એક ચોક્કસ principal માટે ટિકિટ માંગે છે. TCP પ્રદાતા માટે દસ્તાવેજી સ્વરૂપ MSSQLSvc/ છે અને તે પછી સંપૂર્ણ લાયક હોસ્ટનામ અને, ડિફોલ્ટ ઇન્સ્ટન્સ માટે, પોર્ટ. નામવાળું ઇન્સ્ટન્સ MSSQLSvc/db01.corp.example:SQLPROD નોંધે છે, જ્યાં પ્રત્યય સંખ્યાને બદલે ઇન્સ્ટન્સનું નામ છે. એલિયાસ, બીજે ઉકેલાતા CNAME અથવા નગ્ન IP સરનામા દ્વારા લિસનર સુધી પહોંચવું માંગેલું નામ બદલે છે, અને મેળ ખાતું principal ન હોય એવી વિનંતી પાસે પાછી આપવા માટે કોઈ ટિકિટ નથી.

એટલે જ એક એપ્લિકેશન એક નેટવર્ક પર કામ કરે છે અને બીજા પર પાછી જાય છે: 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 જરૂરી હોય, ત્યારે પ્રથમ માર્ગ કેમ પાછો ગયો તે નોંધો, એક સુધારો લાગુ કરો અને એ જ ક્લાયન્ટથી ક્વેરી ફરી ચલાવો. લોન્ચર બદલ્યા પછીની સફળ ક્વેરી ઍક્સેસનો પુરાવો છે, અને તે હજી પુરાવો નથી કે પ્રમાણીકરણની જરૂરિયાત પૂરી થઈ છે.