VPN গ্রুপ পলিসির জন্য ASA LDAP গ্রুপ ম্যাপিং বনাম DAP

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

দুই প্রক্রিয়া, দুই সিদ্ধান্তের বিন্দু

সিদ্ধান্তটি তিনটি প্রশ্নে নেমে আসে। সিদ্ধান্তটি কি ডিরেক্টরির একটি মাত্র অ্যাট্রিবিউট মানের উপর নির্ভর করে, এর কি সেই মানের চেয়ে বেশি কিছু দরকার, এবং দুটোই মিললে কোন প্রক্রিয়াটি জিততে পারে?

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

অ্যাট্রিবিউট ম্যাপের পথ, কনফিগারেশনের ক্রমে

ম্যাপের পথ শুরু হয় AAA সার্ভার সংজ্ঞা থেকে। অ্যাট্রিবিউট ম্যাপটি অবশ্যই সেই LDAP সার্ভার এন্ট্রিতে সংযুক্ত থাকতে হবে যা সংযোগ প্রোফাইলটি আসলে ব্যবহার করে; যে ম্যাপ চলমান কনফিগারেশনে আছে কিন্তু সেই সার্ভার দ্বারা উল্লেখিত নয়, তা কিছুই বদলায় না। সংযুক্তির সেই লাইনটিই বাকি কনফিগারেশনকে সক্রিয় করে। ASA LDAP ম্যাপিং নির্দেশিকা হলো 9.x রিলিজে ম্যাপ সিনট্যাক্সের রেফারেন্স।

ম্যাপের ভিতরে একটি স্টেটমেন্ট ডিরেক্টরি অ্যাট্রিবিউট এবং এটি যে ASA অ্যাট্রিবিউটকে পুষ্ট করে তার নাম বলে, আর পরবর্তী স্টেটমেন্টগুলো নির্দিষ্ট মান রূপান্তর করে। map-name memberOf Group-Policy এর পরে map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly হলো আকৃতি: বাঁ দিকটি ডিরেক্টরি যা ফিরিয়েছে, ডান দিকটি এমন একটি গ্রুপ পলিসির নাম যা আগে থেকেই থাকতে হবে। একটি স্বাতন্ত্র্যসূচক নাম আর একটি পলিসি প্রদর্শন-নাম পরস্পর বিনিময়যোগ্য নয়, এবং যেকোনো স্ট্রিংয়ে সামান্য অমিল লগইনে কোনো ত্রুটি তৈরি করে না।

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

DAP-এর পথ, এবং এটি কী যোগ করে

DAP শর্ত মূল্যায়ন করে এবং AAA ফলাফলের উপরে অ্যাট্রিবিউট প্রয়োগ করে। একটি রেকর্ডে অগ্রাধিকার, একটি অ্যাকশন এবং একগুচ্ছ শর্ত থাকে; রেকর্ডগুলো অগ্রাধিকার ক্রমে মূল্যায়িত হয় এবং অ্যাকশন ঠিক করে মূল্যায়ন চলবে না থামবে। এটি মান অনুসন্ধানের চেয়ে ভিন্ন সম্পাদন মডেল, আর ঠিক তাই এটি এমন নিয়ম প্রকাশ করতে পারে যা ম্যাপ পারে না।

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

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

যেখানে দুটো মিলছে না

অগ্রাধিকারই সেই অংশ যা ডিজাইন ভাঙে। যখন একটি সেশন একইসঙ্গে ম্যাপ এন্ট্রি এবং DAP রেকর্ডের সঙ্গে মেলে, ফলাফল নির্ভর করে রিলিজ এবং রেকর্ডের অ্যাকশনের উপর, তাই যেকোনো একটি প্রক্রিয়া ফলাফলের মালিক — এমন ধরে নেওয়ার বদলে নিজের ASA-তে যাচাই করুন।

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

সক্রিয় সেশন থেকে প্রমাণ পড়া

কনফিগারেশন থেকে নয়, একটি নতুন সেশন থেকে উত্তরটি পড়ুন। show vpn-sessiondb detail anyconnect filter name jdoe সেশনটি আসলে যে গ্রুপ পলিসি পেয়েছে তা ছাপে, আর show running-config ldap attribute-map নিশ্চিত করে ম্যাপ কোন মানগুলো ফিরিয়ে দিতে পারত। ডিরেক্টরির দিকে test aaa-server authentication LDAP-AD username jdoe password <password> ASA যে অ্যাট্রিবিউটগুলো ফেরত পেয়েছে তা দেখায়, আর debug ldap 255 পরীক্ষাটি আপনার প্রত্যাশার সঙ্গে না মিললে সেই বিনিময় দেখায়।

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