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 আবশ্যক হলে প্রথম পথ কেন ফিরে গেল তা লিখে রাখুন, একটি সংশোধন প্রয়োগ করুন এবং একই ক্লায়েন্ট থেকে কোয়েরিটি আবার চালান। লঞ্চার বদলানোর পর সফল কোয়েরি অ্যাক্সেসের প্রমাণ, এবং এটি এখনও প্রমাণ নয় যে প্রমাণীকরণের শর্তটি পূরণ হয়েছে।