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 സേവന അക്കൗണ്ടിനായി രജിസ്റ്റർ ചെയ്ത സേവന പ്രിൻസിപ്പൽ നാമവും അതുമായി ഒത്തുപോകുന്ന പേരിൽ സേവനം ആവശ്യപ്പെടുന്ന ക്ലയന്റും വേണം. IP വിലാസത്തിലൂടെ കണക്ട് ചെയ്യുന്നത് പേരടിസ്ഥാനമാക്കിയ SPN-നോട് ഒത്തുപോകാൻ കഴിയില്ല, ഒരു അപരനാമം അതും രജിസ്റ്റർ ചെയ്തിട്ടുണ്ടെങ്കിൽ മാത്രമേ ഒത്തുപോകൂ. എല്ലാറ്റിനും മുമ്പ് ക്ലയന്റ് ടൈപ്പ് ചെയ്ത പേര് പരിശോധിക്കുക, കാരണം ഹോസ്റ്റ്നാമിൽ പ്രവർത്തിച്ച് IP-യിൽ പരാജയപ്പെടുന്ന കണക്ഷൻ കൃത്യമായി ഈ പ്രശ്നമാണ് വിവരിക്കുന്നത്.

പരീക്ഷണവും പിഴവും വഴി പകർപ്പ് SPN-കൾ സൃഷ്ടിക്കുന്നതിന് പകരം രജിസ്റ്റർ ചെയ്ത ഐഡന്റിറ്റിയും സേവന അക്കൗണ്ടും അവലോകനം ചെയ്യാൻ അഡ്മിനിസ്ട്രേറ്ററിനോട് ആവശ്യപ്പെടുക. പകർപ്പ് രജിസ്ട്രേഷനുകൾ യഥാർത്ഥ പ്രശ്നത്തേക്കാൾ രോഗനിർണയം ബുദ്ധിമുട്ടുള്ള ഇടവേള പരാജയങ്ങൾ ഉണ്ടാക്കുന്നു.

പ്രമാണീകരണം പ്രവർത്തിച്ചതിന് ശേഷവും ലോഗിന് ഒരു ഡാറ്റാബേസ് ഉപയോക്താവും അനുമതികളും വേണം. വിജയകരമായ VPN ലോഗിൻ, വിജയകരമായ Windows ലോഗിൻ, ഒരു നിർദ്ദിഷ്ട പട്ടിക വായിക്കാനുള്ള അനുമതി എന്നിവ മൂന്ന് വേറിട്ട ഫലങ്ങളാണ്, ടിക്കറ്റ് അടയ്ക്കുന്നതിന് മുമ്പ് ഓരോന്നും അതിന്റേതായ പരിശോധന അർഹിക്കുന്നു.