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

লক্ষণ: অ্যাকাউন্ট আছে, সেশন নেই

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

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

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

কাউকে সরানোর আগে শৃঙ্খল মানচিত্র করুন

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

LinkQuestion it answers
Client profileWhich method and server name does the client use?
Inner methodIs there a second authentication step?
Server identityWhich certificate or name must the client accept?
Gateway to backendWhich protocol, port and shared secret?
Attribute mappingWhich returned value becomes group membership?
Resource policyWhat the resulting session may reach

সাধারণ ডিরেক্টরি লগইন সেই শৃঙ্খলের প্রায় কিছুই পার করে না। এটি প্রমাণ করে অ্যাকাউন্ট আছে এবং পাসওয়ার্ড কাজ করে, অর্থাৎ ঠিক সেই অংশ যা কখনও সন্দেহের মধ্যে ছিল না।

হ্যাশ পদ্ধতির মধ্যে ভ্রমণ করে না

ক্রেডেনশিয়ালের সামঞ্জস্য একবার যাচাই করতে হবে, কোনো দল সরানোর আগে। FreeRADIUS বিভাজন স্পষ্টভাবে নথিভুক্ত করে: সার্ভার নিজে যে CHAP যাচাই করে তার প্রকৃত পাসওয়ার্ড দরকার, এবং MS-CHAP সেই পাসওয়ার্ড বা উপযুক্ত NT উপাদান গ্রহণ করে। অন্য উদ্দেশ্যে তৈরি হ্যাশ দুটির কোনোটিতেই মেলে না, তা যতই শক্তিশালী হোক।

পার্থক্য হলো প্রমাণ কে গণনা করে। যে পদ্ধতি ডিরেক্টরির সঙ্গে বেঁধে যাচাই করে সে ডিরেক্টরিকে যা যাচাই করতে পারে তা করতে দেয়। যে পদ্ধতি চ্যালেঞ্জ প্রতিক্রিয়া পুনর্গণনা করে যাচাই করে তার নিজেই গোপনীয়তা দরকার, কারণ সার্ভারকেও একই গণনা করতে হয়।

যেখানে উপাদান নেই, সেখানে সৎ বিকল্প হল সমর্থিত রিসেট, পুনঃনথিভুক্তি, বাহ্যিক যাচাই পরিষেবা বা পদ্ধতি পরিবর্তন। পুনরুদ্ধারযোগ্য পাসওয়ার্ডের সাময়িক রপ্তানি সেই তালিকায় নেই। এটি প্রকল্পের সবচেয়ে বিশৃঙ্খল সপ্তাহে সাদা পাঠের ক্রেডেনশিয়াল ভাণ্ডার তৈরি করে, এবং সাধারণত মাইগ্রেশনের পরেও টিকে থাকে।

পাইলট দল, তারপর জীবনচক্র পরিবর্তন

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

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

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

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

প্রত্যাবর্তন ক্রেডেনশিয়াল পুনরুদ্ধার করতে পারে না

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

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

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

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