কে ডায়াল ইন করতে পারে? VPN অ্যাক্সেসের আগে msNPAllowDialin নিরীক্ষা

পাসওয়ার্ড ঠিক আছে, অ্যাকাউন্টটি VPN গ্রুপে আছে, তবুও সংযোগটি প্রত্যাখ্যাত হচ্ছে এমন একটি বার্তা দিয়ে যেখানে কোনো নীতি উল্লেখই নেই। যখন এটি কোনো Windows রিমোট-অ্যাক্সেস সার্ভারে ঘটে, আমি প্রথমে যে জিনিসটি দেখি তা NPS নিয়ম নয়, বরং Active Directory-র একটি অ্যাট্রিবিউট যেটি কেউ খোলে না: msNPAllowDialin, অর্থাৎ Dial-in ট্যাবের পেছনের মান। এর তিনটি অবস্থা আছে, এবং তৃতীয়টি চুপচাপ সিদ্ধান্তটি অন্য জায়গায় ছেড়ে দেয়। বেশিরভাগ সময় কেউ এটি ইচ্ছাকৃতভাবে পরিবর্তন করেনি: অ্যাকাউন্টটি কোনো টেমপ্লেট থেকে ক্লোন করা হয়েছিল, বা এমন স্ক্রিপ্ট দিয়ে তৈরি হয়েছিল যা বছর আগে স্পষ্ট নিষেধ লিখে গিয়েছিল এবং আর কখনও পর্যালোচনা করা হয়নি।

নীতি পড়ার আগেই প্রত্যাখ্যান ঘটতে পারে

Windows অনুমোদন সিদ্ধান্ত তৈরি করার সময় অ্যাকাউন্টের ডায়াল-ইন অনুমতি যাচাই করে, তাই স্পষ্ট নিষেধ কথোপকথনটি তাড়াতাড়ি শেষ করে দেয়। ক্লায়েন্টে যা দেখেন তা একটি সাধারণ প্রমাণীকরণ ব্যর্থতা, কখনও কখনও সার্টিফিকেট বিনিময় শেষ হওয়ার পরে, এই কারণেই মানুষ বিকেলটা নষ্ট করে এমন ক্রেডেনশিয়াল পরীক্ষা করতে যা কখনও সমস্যাই ছিল না।

বিপরীত ঘটনাটিও সমান বিভ্রান্তিকর। যে অ্যাকাউন্টে কখনও ফ্ল্যাগ সেট হয়নি সেটি সফলভাবে সংযোগ করতে পারে, কারণ নীতিটি অনুমতি দিয়েছিল, আর তারপর একই অ্যাকাউন্ট সংযোগ করা বন্ধ করে দেয় যখন কেউ অসম্পর্কিত কারণে NPS নিয়ম সম্পাদনা করে। বাইরে থেকে দুটি ঘটনার কোনোটিই ডায়াল-ইন অনুমতির পরিবর্তনের মতো দেখায় না।

তিনটি অবস্থা, আর তৃতীয়টি অদৃশ্য

TRUE ডায়াল-ইন অনুমতি দেয়, FALSE তা প্রত্যাখ্যান করে, আর NULL মানে অ্যাকাউন্টটি রিমোট অ্যাক্সেস নীতি বা NPS অনুমোদন থেকে উত্তরটি উত্তরাধিকারসূত্রে পায়। GUI সেই তৃতীয় অবস্থাটিকে "Control access through NPS Network Policy" হিসেবে দেখায়, এবং এটি কোনো সিদ্ধান্তের বদলে অনির্বাচিত চেকবক্সের মতো পড়া যায়।

এজন্যই কনসোল থেকে অনুমতিপ্রাপ্ত ব্যবহারকারী গণনা করে প্রায় কিছুই জানা যায় না। একটি উত্তরাধিকারসূত্রে পাওয়া অ্যাকাউন্ট আজ অনুমোদিত ও কাল প্রত্যাখ্যাত হতে পারে অ্যাকাউন্ট স্পর্শ না করেই, আর FALSE অ্যাকাউন্ট এমন সার্ভারেও সংযোগ করতে পারে যার নীতি ব্যবহারকারীর ডায়াল-ইন বৈশিষ্ট্য উপেক্ষা করতে সেট করা। অ্যাট্রিবিউট ও নীতি একসাথে পড়ুন, নইলে আপনি অর্ধেক সিদ্ধান্ত নিরীক্ষা করছেন।

উত্তরাধিকারসূত্রে পাওয়া অ্যাকাউন্ট না হারিয়ে ফ্ল্যাগগুলো রপ্তানি করুন

ডোমেইন কন্ট্রোলার থেকে, বা Active Directory মডিউলসহ কোনো ওয়ার্কস্টেশন থেকে রপ্তানি চালান, এবং সারসংক্ষেপ আবার টাইপ করার বদলে কাঁচা ফাইলটি প্রমাণ হিসেবে রাখুন:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

একটি একক LDAP ফিল্টার পরিবর্তন রেকর্ডে আটকানো সহজ। এটি কেবল স্পষ্ট অনুমতিগুলো ফেরত দেয়:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

তারপর ডায়াল-ইন ধারা ছাড়া আবার কোয়েরি করুন এবং এমন অ্যাকাউন্ট খুঁজুন যাদের মান অনুপস্থিত। এগুলোই উত্তরাধিকারসূত্রে পাওয়া অ্যাকাউন্ট, সাধারণত ডোমেইনের বৃহত্তম দল, আর এগুলো বাদ দিলে নিরীক্ষা পরিণত হয় সেই কয়েকজনের তালিকায় যাদের হাতে সেট করতে কেউ মনে রেখেছিল।

ফ্ল্যাগকে গ্রুপ অ্যাক্সেস ও অ্যাকাউন্টের অবস্থা থেকে আলাদা করুন

অ্যাট্রিবিউট একটি প্রশ্নের উত্তর দেয়: এই অ্যাকাউন্ট কি ডায়াল ইন করতে পারবে। ব্যক্তিটি এখনও এখানে কাজ করে কি না, অ্যাকাউন্ট সক্রিয় কি না, বা হেল্প-ডেস্কের নোটে কোনো শেয়ার করা পাসওয়ার্ড পড়ে আছে কি না — কিছুই বলে না। রপ্তানিটিকে সক্রিয় অবস্থা, শেষ লগইনের তারিখ এবং সার্ভারে প্রবেশাধিকার দেওয়া গ্রুপ সদস্যপদের সাথে জুড়ে দেখুন।

যে সমন্বয়গুলো আসে সেগুলোই আপনার পদক্ষেপের ভিত্তি। নিষ্ক্রিয় অ্যাকাউন্ট TRUE নিয়ে শুধু শব্দ। সক্রিয় অ্যাকাউন্ট TRUE নিয়ে এক বছর লগইন না করলে সেটি অপসারণের প্রার্থী। আর VPN গ্রুপে থাকা এমন উত্তরাধিকারসূত্রে পাওয়া অ্যাকাউন্ট যা কেউ ব্যাখ্যা করতে পারে না — সেটাই আসল অনুসন্ধান, কারণ কোনো একক সেটিং কেন এটি দেওয়া হয়েছিল তা লিপিবদ্ধ করে না।

এটি সেই ডোমেইন কন্ট্রোলার থেকে পড়ুন যার বিপরীতে VPN সার্ভারটি সত্যিই প্রমাণীকরণ করে। রেপ্লিকেশন বিলম্ব এমন মান দেখাতে পারে যা সার্ভার ইতিমধ্যে প্রতিস্থাপন করেছে, আর বাসি DC মান উদ্ধৃত করা নিরীক্ষাকে কেউ আবার যাচাই করার সঙ্গে সঙ্গেই চ্যালেঞ্জ করা হবে।

একটি অ্যাকাউন্ট পরিবর্তন করুন এবং প্রমাণ করুন যে পরিবর্তনটি পৌঁছেছে

প্রবেশাধিকার সরাতে অ্যাট্রিবিউটটি FALSE করুন, এটি মুছে ফেলার বদলে। মুছে ফেলা অ্যাকাউন্টটিকে নীতি-উত্তরাধিকারে ফিরিয়ে দেয়, যা পরবর্তী সংযোগে আবার অনুমতি দিতে পারে, আর পরিবর্তনটি সংশোধনের মতো দেখালেও আসলে এটি ভিন্ন একটি সিদ্ধান্ত:

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

দ্বিতীয় লাইনটি হলো উত্তরাধিকার রিসেট, ইচ্ছাকৃতভাবে আলাদা রাখা যাতে কেউ দুটি অপারেশন গুলিয়ে না ফেলে। তারপর দ্বিতীয় সেশন থেকে নিশ্চিত করুন, অ্যাট্রিবিউট আবার পড়ুন, এবং কনসোলের রিফ্রেশে ভরসা না করে প্রত্যাখ্যানের জন্য NPS অ্যাকাউন্টিং ইভেন্ট দেখুন।

অবশেষে, প্রতিটি রিমোট-অ্যাক্সেস পরিষেবার জন্য কোন প্রক্রিয়াটি সিদ্ধান্তের মালিক তা লিখে রাখুন। যদি নীতি ব্যবহারকারীর ডায়াল-ইন বৈশিষ্ট্য উপেক্ষা করে, তাহলে গ্রুপ শর্তই প্রামাণিক আর অ্যাট্রিবিউট কেবল সেই পরিষেবার জন্য পরামর্শমূলক। একই ডোমেইনে দুটি পরিষেবা বৈধভাবে ভিন্ন উত্তর দিতে পারে, এবং পর্যালোচনা রেকর্ডে প্রতি পরিষেবার জন্য এক লাইনে তা বলা উচিত।

নিরীক্ষায় টিকে থাকা ফলাফল সংক্ষিপ্ত: কে সংযোগ করতে পারবে, কোন প্রক্রিয়ায়, কখন পর্যালোচিত, কার দ্বারা। ডায়াল-ইন ফ্ল্যাগ প্রথম দুটি উত্তর দেয়; বাকিটা কেবল নীতির পর্যালোচনাই দেয়।