LmCompatibilityLevel হলো Windows-এর একটি নীতি, VPN-এর সমাধান নয়
একটি রেজিস্ট্রি মান পুরো মেশিনে নেটওয়ার্ক লগইন নিয়ন্ত্রণ করে, শুধু টানেল নয়। এটি মেরামত হিসেবে ধরার আগে জানুন প্রতিটি স্তর কী পাঠায় আর কী প্রত্যাখ্যান করে।
কেউ VPN দিয়ে একটি ফাইল শেয়ারে পৌঁছাতে পারছে না, পড়ে যে LmCompatibilityLevel কমানো NTLM সমস্যা ঠিক করে, এবং একটি শেয়ার্ড সার্ভারে সেটি বদলে ফেলে। পরের সকালে অন্য অ্যাপ্লিকেশনগুলো ব্যর্থ হয়, আর মূল সমস্যা আগের মতোই থাকে। এই সেটিংটি কখনোই প্রতি-টানেল সুইচ ছিল না; এটি পুরো মেশিনের জন্য একটি ঘোষণা—এই সিস্টেম কোন প্রমাণীকরণ প্রতিক্রিয়া পাঠাবে ও গ্রহণ করবে। একটি লগইন ঠিক করতে এটি বদলালে মেশিনের প্রতিটি লগইনের নিয়ম নতুন করে লেখা হয়।
নথিভুক্ত স্তরগুলো পড়াই একটি নীতিমূল্যের মানকে জাদু-সংখ্যা হিসেবে দেখা বন্ধ করার দ্রুততম উপায়।
তিনটি স্তর, তিনটি ভিন্ন প্রতিশ্রুতি
স্তর 1 ক্লায়েন্টকে LM ও NTLM প্রতিক্রিয়া পাঠাতে বাধ্য করে এবং দর-কষাকষি অনুমতি দিলে NTLMv2 সেশন নিরাপত্তা ব্যবহার করে। স্তর 3 ক্লায়েন্টকে কেবল NTLMv2 প্রতিক্রিয়া পাঠাতে বাধ্য করে, যা গ্রহণকারী পক্ষে প্রতিটি পুরোনো প্রতিক্রিয়া প্রত্যাখ্যান করার সমান নয়। স্তর 5 ক্লায়েন্টকে NTLMv2-তে রাখে এবং ডোমেইন কন্ট্রোলারের নথিভুক্ত LM ও NTLMv1 প্রত্যাখ্যান যোগ করে। তিনটি সংখ্যা, আর তাদের মধ্যকার ব্যবধান পছন্দ নয়, একটি নীতি-সিদ্ধান্ত।
এই পার্থক্যগুলোই ব্যাখ্যা করে কেন একটি কাজ করা ক্ষেত্র থেকে মান কপি করা অবিশ্বাস্য। ভুল কনফিগার করা ক্লায়েন্টকে 1 থেকে অনুমোদিত বেসলাইনে সরানো সঠিক হতে পারে। কিন্তু একটি ফোরাম থ্রেডে 3 উল্লেখ থাকায় কঠোরভাবে সুরক্ষিত স্থাপনাকে 5 থেকে 3-এ নামানো এমন একটি সীমা শিথিল করে যা কেউ সচেতনভাবে বেছেছিলেন, এবং মেশিন যে সব সার্ভিসের সঙ্গে কথা বলে সবার ক্ষেত্রেই তা করে।
কার্যকর নীতি পড়ুন, একটি রেজিস্ট্রি মান নয়
শুধু-পাঠ পদ্ধতিতে স্থানীয় মানটি দেখা যুক্তিসঙ্গত সূচনা: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel। মান অনুপস্থিত থাকার অর্থ কার্যকর নীতি শূন্য নয়, কারণ ডোমেইন বা স্থানীয় নিরাপত্তা নীতি এটি অন্যত্র নির্ধারণ করতে পারে এবং মেশিনের ভূমিকা এই সংখ্যাটি দিয়ে সে কী করে তা বদলে দেয়।
কোনো সিদ্ধান্তে পৌঁছানোর আগে পরিচালিত নীতি, সিস্টেমের ভূমিকা এবং প্রকৃত বিল্ড যাচাই করুন। একই মানযুক্ত একটি ওয়ার্কস্টেশন ও একটি ডোমেইন কন্ট্রোলার উপরের প্রান্তে ভিন্নভাবে আচরণ করে, আর দুটি মেশিন তুলনা করার সময় মানুষ ঠিক এই অংশটাই ভুলে যায়।
কোন প্রমাণীকরণটি সত্যিই ব্যর্থ হয়েছে তা চিহ্নিত করুন
Kerberos টিকিটের সমস্যা, NTLM প্রত্যাখ্যান এবং VPN প্রবেশের ব্যর্থতার জন্য ভিন্ন প্রমাণ দরকার। লক্ষ্য সার্ভিস, অ্যাকাউন্ট ও সুনির্দিষ্ট ত্রুটি একই নোটে একসঙ্গে রাখুন, তারপর ক্লায়েন্ট কী পছন্দ করে নয়, সার্ভিস কী চেয়েছিল তা দেখুন। সেই একটি নোটই সবচেয়ে সাধারণ ভুল বাঁকটি আটকায়—সার্ভার-পক্ষের প্রত্যাখ্যানের জবাবে ক্লায়েন্ট-পক্ষের মান বদলানো।
একটি সাধারণ লগইন ত্রুটি মিলিয়ে যাওয়া পর্যন্ত বারবার নীতি কমানো রোগনির্ণয় নয়; এটি এমন পরিবর্তন যা প্রমাণ লুকায়। অ্যাপ্লিকেশনটি Kerberos ব্যবহার করলে NTLM সামঞ্জস্যের স্তর প্রাসঙ্গিক নিয়ন্ত্রণই নয়, আর আপনি বৃথাই একটি সীমা শিথিল করেছেন।
কিছু প্রোটোকল সমর্থন ফিরিয়ে আনা যায় না
Windows 11 24H2 এবং Windows Server 2025 আর NTLMv1 নেটওয়ার্ক প্রমাণীকরণ একেবারেই অন্তর্ভুক্ত করে না। কোনো সামঞ্জস্য-সংখ্যা এমন প্রোটোকল ফেরায় না যা বিল্ড আর বাস্তবায়ন করে না, তাই পুরোনো সংস্করণে কাজে লাগা একটি ডাউনগ্রেড নতুনটিতে শুধু ব্যর্থ হবে। Microsoft ওই অপসারণটি নীতি-সেটিং থেকে আলাদাভাবে নথিভুক্ত করে, আর দুটিকে গুলিয়ে ফেললে এমন পরামর্শ তৈরি হয় যা কাজ করতে পারে না।
MSCHAPv2-ভিত্তিক একক সাইন-অনে ব্যবহৃত NTLMv1 থেকে উদ্ভূত শংসাপত্রে একটি সম্পর্কিত কিন্তু পৃথক নিষেধাজ্ঞা প্রযোজ্য। এটি উদ্ভূত-শংসাপত্রের প্রশ্ন, নেটওয়ার্ক প্রোটোকল নিজে নয়, আর এই একটি রেজিস্ট্রি মানও নয়। তিনটিকে একই বিষয় ভাবাই সেই পথ যেখানে প্রতিষ্ঠানগুলো একটি নিয়ন্ত্রণ দুর্বল করে অন্যটি ঠিক করার চেষ্টা করে।
মালিকের মাধ্যমে এটি বদলান, তারপর দুই দিকই পরীক্ষা করুন
সত্যিই সংশোধন দরকার হলে নীতি-মালিকের মাধ্যমে করুন যাতে বেসলাইন সুসংগত থাকে, এবং কেন তা লিখে রাখুন। তারপর নতুন সেটিংয়ে একটি অনুমোদিত অ্যাপ্লিকেশন এবং ইচ্ছাকৃতভাবে নিষিদ্ধ একটি প্রমাণীকরণের ঘটনা পরীক্ষা করুন, কারণ যে পরিবর্তন একটি শেয়ার ঠিক করে আর অন্যত্র নীরবে পুরোনো প্রতিক্রিয়া অনুমোদন করে, তা সাফল্য নয়। কাজ করা একটি VPN সংযোগ প্রমাণ করে প্রবেশ সফল হয়েছে। এটি মেশিনের প্রমাণীকরণ নীতি যাচাই করে না, এবং এর পেছনের প্রতিটি সার্ভিস এখনো পরিকল্পনা অনুযায়ী আচরণ করে তা তো নিশ্চিতই করে না।
ব্যর্থ সার্ভিসটি Kerberos-ভিত্তিক হলে এই সেটিংয়ের দিকে তাকানো পুরোপুরি বন্ধ করুন। আর যদি এটি সত্যিই আর ভালো করতে না-পারা একটি পুরোনো যন্ত্র হয়, তবে সেই ব্যতিক্রম নথিভুক্ত করুন ও তার পরিধি নির্ধারণ করুন, কারণ বিকল্প হলো নীরবে দুর্বল করা একটি বেসলাইন যা কেউ অনুমোদন করেছিল বলে মনে রাখে না।