VPN সংযোগ হয়, কিন্তু SQL Server Windows প্রমাণীকরণ প্রত্যাখ্যান করে
VPN লগইন কাজ করে, কিন্তু SQL Server Windows প্রমাণীকরণ প্রত্যাখ্যান করে: টানেল অ্যাকাউন্টের সঙ্গে ক্লায়েন্টের টোকেন মিলিয়ে দেখুন, তারপর সার্ভারে auth_scheme পড়ুন।
টানেল উঠে আসে, সার্ভার 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 বোঝায় শংসাপত্র গৃহীত হয়েছে কিন্তু সার্ভারে প্রবেশ ব্যর্থ হয়েছে। পুরো বার্তার বদলে প্রশাসকের কাছে স্টেটটি চান, কারণ বার্তাটি একা ইচ্ছাকৃতভাবে অস্পষ্ট।
| What you observe | What it suggests |
|---|---|
| Timeout, no listener | Route, firewall or wrong port |
| Login failed, state 5 | Name not resolved in the domain |
| Login failed, state 11 | Authenticated but no server access |
| Connected as NTLM | Target name or SPN mismatch |
যখন পরিচয় পৌঁছায় আর Kerberos তবুও ব্যর্থ হয়
সার্ভার যদি অভীষ্ট Windows পরিচয় দেখে আর সমন্বিত প্রমাণীকরণ তবুও ব্যর্থ হয়, তবে সমস্যা বিনিময়টিতেই। Kerberos-এর জন্য SQL সার্ভিস অ্যাকাউন্টের নামে নিবন্ধিত সার্ভিস প্রিন্সিপাল নাম (SPN) এবং এমন ক্লায়েন্ট দরকার যা সেই নামের সঙ্গে মিলে যায় এমন নামে সার্ভিস চায়। IP ঠিকানায় সংযোগ করলে নামভিত্তিক SPN-এর সঙ্গে মেলা সম্ভব নয়, আর একটি উপনাম তখনই মিলতে পারে যদি সেটিও নিবন্ধিত থাকে। সবার আগে ক্লায়েন্ট যে নাম টাইপ করেছে তা দেখুন, কারণ হোস্টনামে কাজ করে IP-তে ব্যর্থ হওয়া সংযোগ ঠিক এই সমস্যাটিই বর্ণনা করে।
প্রশাসককে পরীক্ষা-ভুলের মাধ্যমে অনুলিপি SPN তৈরির বদলে নিবন্ধিত পরিচয় ও সার্ভিস অ্যাকাউন্টটি পর্যালোচনা করতে বলুন। অনুলিপি নিবন্ধন বিরতিহীন ব্যর্থতা তৈরি করে, যেগুলো মূল সমস্যার চেয়ে নির্ণয় করা কঠিন।
প্রমাণীকরণ কাজ করার পরেও লগইনের একটি ডেটাবেস ব্যবহারকারী ও অনুমতি দরকার। সফল VPN লগইন, সফল Windows লগইন এবং নির্দিষ্ট একটি টেবিল পড়ার অনুমতি তিনটি আলাদা ফলাফল, আর টিকিট বন্ধ করার আগে প্রত্যেকটির নিজস্ব যাচাই প্রাপ্য।