VPN വഴി SQL Server ഇപ്പോഴും NTLM ലേക്ക് പോകുന്നത് എന്തുകൊണ്ട്?

നിങ്ങളുടെ കണക്ഷൻ പ്രവർത്തിക്കുന്നു, ലോഗിൻ സ്വീകരിക്കുന്നു, എന്നാൽ എല്ലാവരും Kerberos പ്രതീക്ഷിച്ചപ്പോൾ SQL Server NTLM ഉപയോഗിക്കുന്നു. ഈ ഫലം VPN കുറ്റമല്ല, കാരണം ടണൽ ഒരു പാത മാത്രം നൽകുന്നു; ക്ലയന്റ് ആവശ്യപ്പെട്ട പേര്, ഡയറക്ടറിയിൽ രജിസ്റ്റർ ചെയ്ത പ്രിൻസിപ്പൽ, ക്ലയന്റിന് യഥാർത്ഥത്തിൽ ലഭിക്കാൻ കഴിഞ്ഞ ടിക്കറ്റ് എന്നിവയാണ് സ്കീം നിർണ്ണയിച്ചത്. മൂന്ന് വ്യവസ്ഥകൾ ഒരേസമയം പാലിക്കണം, ഏതാണ് വഴങ്ങിയതെന്ന് സെഷൻ തന്നെ പറയുന്നു. ആരെങ്കിലും സേവന പ്രിൻസിപ്പൽ നാമം തിരുത്തുന്നതിന് മുമ്പ് ഇത് വായിക്കുക.

നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ലഭിച്ച സ്കീം സെഷൻ പേരിടുന്നു

ഓതന്റിക്കേഷൻ സ്കീം ഒരു കണക്ഷനിൽ ഉള്ളതാണ്, സർവറിലോ ടണലിലോ അല്ല, അതിനാൽ നിങ്ങൾക്ക് പ്രധാനമായ സെഷനുള്ളിൽ പരിശോധന നടത്തണം. റിപ്പോർട്ട് നിർമ്മിച്ച അതേ ക്ലയന്റിൽ നിന്നും ഉപകരണത്തിൽ നിന്നും അക്കൗണ്ടിൽ നിന്നും താഴെയുള്ള ക്വറി പ്രവർത്തിപ്പിക്കുക, ഫലത്തിന് അടുത്ത് ലക്ഷ്യ നാമവും ട്രാൻസ്പോർട്ടും രേഖപ്പെടുത്തുക.

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

ഡാറ്റാബേസ് ഹോസ്റ്റിലെ ലോക്കൽ SSMS വിൻഡോയിൽ നിന്നുള്ള ഒരു വരി തികച്ചും വ്യത്യസ്തമായ ഒരു കണക്ഷനെ വിവരിക്കുന്നു, അതിനാൽ ക്വറി ക്ലയന്റ് വശത്തുനിന്ന് പ്രവർത്തിപ്പിക്കണം. ടൈംസ്റ്റാമ്പിനൊപ്പം ഔട്ട്പുട്ട് സൂക്ഷിക്കുക, കാരണം ഇത് വായിക്കുന്ന അടുത്ത വ്യക്തി എപ്പോൾ എടുത്തതെന്ന് ചോദിക്കും. നിരവധി ആപ്ലിക്കേഷനുകൾ ഒരു എൻഡ്പോയിന്റ് പങ്കിടുമ്പോൾ ഓരോന്നിൽ നിന്നും സാമ്പിൾ എടുക്കുക, കാരണം രണ്ട് ആപ്ലിക്കേഷനുകൾ തമ്മിലുള്ള ഡാറ്റാ ഉറവിട വ്യത്യാസം പലപ്പോഴും മുഴുവൻ കഥയാണ്.

ഒന്നാം വ്യവസ്ഥ: പേര് SPN-മായി പൊരുത്തപ്പെടുന്നുണ്ടോ?

Kerberos പേരിട്ട ഒരു സേവനത്തെ ഓതന്റിക്കേറ്റ് ചെയ്യുന്നു, അതിനാൽ ക്ലയന്റ് ഒരു നിർദ്ദിഷ്ട പ്രിൻസിപ്പലിനുള്ള ടിക്കറ്റ് ഡയറക്ടറിയോട് ആവശ്യപ്പെടുന്നു. TCP ദാതാവിന് രേഖപ്പെടുത്തിയ രൂപം MSSQLSvc/ ആണ്, തുടർന്ന് പൂർണ്ണമായി യോഗ്യതയുള്ള ഹോസ്റ്റ് നാമവും ഡിഫോൾട്ട് ഇൻസ്റ്റൻസിന് പോർട്ടും. പേരിട്ട ഇൻസ്റ്റൻസ് MSSQLSvc/db01.corp.example:SQLPROD രജിസ്റ്റർ ചെയ്യുന്നു, അവിടെ പ്രത്യയം സംഖ്യയ്ക്ക് പകരം ഇൻസ്റ്റൻസ് നാമമാണ്. അലിയാസ്, മറ്റൊരിടത്ത് പരിഹരിക്കുന്ന CNAME, അല്ലെങ്കിൽ വെറും IP വിലാസം വഴി ലിസണറിലെത്തുന്നത് ആവശ്യപ്പെട്ട പേരിനെ മാറ്റുന്നു, പൊരുത്തപ്പെടുന്ന പ്രിൻസിപ്പൽ ഇല്ലാത്ത അഭ്യർത്ഥനയ്ക്ക് തിരികെ നൽകാൻ ടിക്കറ്റില്ല.

അതുകൊണ്ടാണ് ഒരു ആപ്ലിക്കേഷൻ ഒരു നെറ്റ്വർക്കിൽ പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ പിന്നോട്ട് പോകുകയും ചെയ്യുന്നത്: 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 നിർബന്ധമാണെങ്കിൽ ആദ്യ പാത എന്തുകൊണ്ട് പിന്നോട്ട് പോയെന്ന് രേഖപ്പെടുത്തുക, ഒരു തിരുത്ത് പ്രയോഗിക്കുക, അതേ ക്ലയന്റിൽ നിന്ന് ക്വറി വീണ്ടും പ്രവർത്തിപ്പിക്കുക. ലോഞ്ചർ മാറ്റത്തിന് ശേഷമുള്ള വിജയകരമായ ക്വറി ആക്സസിന്റെ തെളിവാണ്, ഓതന്റിക്കേഷൻ ആവശ്യകത പാലിച്ചു എന്നതിന്റെ തെളിവല്ല ഇതുവരെ.