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 අනිවාර්ය වූ විට පළමු මාර්ගය ඇයි ආපසු ගියේද යන්න සටහන් කර, එක් නිවැරදි කිරීමක් යොදා, එම සේවාදායකයාගෙන්ම ප්‍රශ්නය නැවත ක්‍රියාත්මක කරන්න. ආරම්භකයා වෙනස් කිරීමෙන් පසු සාර්ථක ප්‍රශ්නයක් ප්‍රවේශයට සාක්ෂියක් වන අතර, සත්‍යාපන අවශ්‍යතාවය ඉටු වූ බවට සාක්ෂියක් තවම නොවේ.