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

একটি কাজের অ্যাকশন কী পড়ার যোগ্য রেখে যায়

নির্ধারিত কাজের আর্গুমেন্ট তার সংজ্ঞার অংশ, লুকানো রানটাইম মান নয়। যে কেউ কাজটি পড়তে, তার ব্যাকআপ পুনরুদ্ধার করতে বা তার XML রপ্তানি করতে পারে, সে আপনার টাইপ করা স্ট্রিংটি হুবহু দেখে। চলার সময় একই স্ট্রিং প্রসেস তালিকায় দেখায়। একটি মনিটরিং এজেন্ট এটি এমন লগে অনুলিপি করতে পারে যা আপনি কখনও দেখেন না।

schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list

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

সংরক্ষিত প্রি-শেয়ার্ড কী আসলে কী দেয়

Add-VpnConnection -L2tpPsk কীটি কাজের বদলে সংযোগের ফোনবুক এন্ট্রিতে লেখে। এটি কাজের অ্যাকশনের চেয়ে ছোট প্রকাশের পৃষ্ঠ। তবুও এটি পুনরুদ্ধারযোগ্য গোপন তথ্য, কারণ মেশিনের একজন প্রশাসক ফোনবুক পড়তে পারেন।

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

Winlogon ক্রেডেনশিয়াল গোপন তথ্য সরায় এবং নির্ভরতা যোগ করে

-UseWinlogonCredential একটি ভিন্ন পথ নেয়। সংযোগটি প্রমাণীকরণ করে MSCHAPv2 দিয়ে লগইন করা ব্যবহারকারীর ক্রেডেনশিয়ালের বিপরীতে। সেই অ্যাকাউন্টের জন্য অতিরিক্ত কিছু সংরক্ষণ করা হয় না।

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

সার্টিফিকেট প্রমাণীকরণ স্কেল করে কারণ কিছুই সংরক্ষিত থাকে না

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

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

পরবর্তী ঘোরানোর আগে আর্টিফ্যাক্টগুলো পর্যালোচনা করুন

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

কাজের নিজের নোটে প্রমাণীকরণ পদ্ধতি ও অ্যাকাউন্ট লিখে রাখুন। সার্ভারের নীতি বদলানো পরবর্তী ব্যক্তিকে জানতে হবে কোন নকশা চলছে। সেই উত্তর শুধু পুনঃসংযোগের আচরণ থেকে দেখা যায় না। পরবর্তী ঘোরানো যেখানে প্রথমে তাকাবে সেখানে তা লিখুন।

সম্পর্কিত নিবন্ধ