OpenVPN-এ LDAP প্রমাণীকরণ কাজ করে কিন্তু গ্রুপ যাচাই ব্যর্থ হয়: কোথায় দেখবেন
প্রমাণীকরণ পাস করতে পারে যখন গ্রুপ যাচাই সবাইকে প্রত্যাখ্যান করে। Authorization ব্লক, সদস্যপদ অ্যাট্রিবিউট ও ডিরেক্টরি এন্ডপয়েন্ট যথাক্রমে দেখুন।
ক্রেডেনশিয়াল পাস করে, টানেল উপরে উঠতে শুরু করে, তারপর সেশনটি পাসওয়ার্ড নয় বরং গ্রুপ নিয়ে একটি বার্তা দিয়ে ব্যর্থ হয়। এই সমন্বয় ব্যর্থতাটিকে LDAP প্লাগইনের কাজের দ্বিতীয়ার্ধে রাখে: বাইন্ড ও পাসওয়ার্ড যাচাই সফল হয়েছে, আর তার পরে আসা সদস্যপদ সিদ্ধান্ত হয়নি। দুই অর্ধই একই কনফিগারেশন স্ট্যানজা থেকে পড়ে, তাই এক জায়গায় সংশোধন অন্যটিকে অক্ষত রাখতে পারে। যে লগ লাইনটি ধাপটির নাম বলে সেখান থেকে শুরু করুন, আপনি যে অ্যাকাউন্ট দিয়ে পরীক্ষা করছেন সেখান থেকে নয়।
প্রত্যাখ্যানকে অনুমোদনের উত্তর হিসেবে ধরুন
প্লাগইন একটি সার্ভিস বাইন্ড করে, অ্যাকাউন্ট খোঁজে, দেওয়া পাসওয়ার্ড যাচাই করে, তারপর জিজ্ঞাসা করে সেই অ্যাকাউন্টটি অনুমোদিত কোনো গ্রুপের অন্তর্গত কি না। এগুলি চারটি আলাদা কাজ, এবং কেবল শেষটিই গ্রুপ নিয়ে। তাই সফল বাইন্ডের পরে আসা প্রত্যাখ্যান পাসওয়ার্ড সম্পর্কে কিছুই বলে না, এমনকি যখন ক্লায়েন্ট একটি সাধারণ প্রমাণীকরণ ত্রুটি দেখায়। কনফিগারেশন বদলানোর আগে প্লাগইনের লগ স্তর বাড়ানোই আউটপুটে চারটিকে আলাদা করে।
গ্রুপ মূল্যায়নটাই খুঁজুন। যখন কোনো গ্রুপ কোয়েরি একেবারেই দেখা যায় না, তখন অনুমোদন ব্লকে পৌঁছানো হচ্ছে না, যার অর্থ সাধারণত একটি নির্দেশনা তার মালিকানাধীন স্ট্যানজার বাইরে রয়েছে, অথবা একটি আবশ্যক অপশন অনুপস্থিত। যখন কোয়েরি দেখা যায় এবং কিছু ফেরত দেয় না, তখন এন্ডপয়েন্ট বা ফিল্টার আপনার বোঝানো প্রশ্নের চেয়ে অন্য প্রশ্নের উত্তর দিচ্ছে।
সদস্যপদ ফিল্টারে থাকে না গ্রুপ ব্লকে, তা নির্ধারণ করুন
সমর্থিত দুটি রূপ আছে, এবং সেগুলি মেশানোই একটি সচল কনফিগারেশনকে অচল করে তোলে। প্রথমটি ব্যবহারকারী অবজেক্টে একটি অ্যাট্রিবিউট চেয়ে সদস্যপদকে ব্যবহারকারী অনুসন্ধানে ঠেলে দেয়; দ্বিতীয়টি ব্যবহারকারী অনুসন্ধান অপরিবর্তিত রেখে প্লাগইনকে পরে গ্রুপ অবজেক্ট খুঁজতে দেয়। প্রতিটি ডিপ্লয়মেন্টে একটি বেছে নিন এবং কোনটি বেছেছেন লিখে রাখুন।
<Authorization>
BaseDN "OU=People,DC=example,DC=org"
SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
RequireGroup false
</Authorization>সেই রূপে ফিল্টার সবকিছু ঠিক করে, তাই RequireGroup অবশ্যই false হতে হবে, নইলে প্লাগইন এমন গ্রুপ অবজেক্ট খুঁজতে যায় যা ফিল্টার কখনও উল্লেখ করেনি। ফিল্টারের অ্যাট্রিবিউটটি ব্যবহারকারী অবজেক্টে থাকতে হবে এবং পূরণ করা থাকতে হবে, যা গ্রুপগুলি নেস্টেড হলে নিশ্চিত নয়।
অন্য রূপটি অনুসন্ধান সরল রাখে এবং তার পরে একটি গ্রুপ লুকআপ যোগ করে। গ্রুপ অবজেক্টটি স্পষ্টভাবে নামকরণ করা হয়, এবং প্লাগইন ব্যবহারকারীকে ডিরেক্টরি তার জন্য যে সদস্যরা ফেরত দেয় তাদের সাথে তুলনা করে। ব্যবহারকারী ফিল্টারে কিছুই বদলায় না, যা এই রূপটিকে অডিট করা সহজ করে তোলে যখন অন্য দল গ্রুপ পরিচালনা করে।
<Authorization>
BaseDN "OU=People,DC=example,DC=org"
SearchFilter "(sAMAccountName=%u)"
RequireGroup true
Group "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>অন্ধ জায়গাটি ভাগ করা: সাধারণ সদস্যপদ তুলনা নেস্টেড গ্রুপ প্রসারিত করে না, তাই যে অ্যাকাউন্টের অ্যাক্সেস প্যারেন্ট গ্রুপের মধ্য দিয়ে আসে সেটি ব্যর্থ হয়, অথচ কনসোল এখনও সদস্যপদ দেখায়। Active Directory গ্রুপে member প্রকাশ করে, অন্য স্কিমাগুলি uniqueMember ব্যবহার করে, এবং ভুল অ্যাট্রিবিউটে ইশারা করলে ত্রুটির বদলে খালি ফলাফল আসে।
এমন এন্ডপয়েন্ট বেছে নিন যা গ্রুপ অবজেক্ট ধারণ করে
URL ঠিক করে প্লাগইন কোন ডিরেক্টরিকে জিজ্ঞাসা করবে, এবং 389 পোর্টের একটি ডোমেইন কন্ট্রোলার কেবল নিজের নামকরণ প্রসঙ্গের উত্তর দেয়। 3268 পোর্টের একটি গ্লোবাল ক্যাটালগ সমগ্র ফরেস্টের উত্তর দেয়, শুধু-পাঠ এবং আংশিক অ্যাট্রিবিউট সেট নিয়ে। যখন অ্যাকাউন্টগুলি এক ডোমেইনে আর VPN গ্রুপ অন্য ডোমেইনে থাকে, তখন একক-ডোমেইন কোয়েরি ব্যবহারকারীকে খুঁজে পেয়েও সদস্যপদ মিস করতে পারে। এই ক্ষেত্রেই URL ক্যাটালগ পোর্টে সরানো প্রত্যাখ্যান সমাধান করে, আর এই ক্ষেত্রেই মানুষ বেশি দূরে সাধারণীকরণ করে।
আংশিক অ্যাট্রিবিউট সেটই সীমা: ক্যাটালগ যে অ্যাট্রিবিউট রাখে না সেটিতে ফিল্টার করা যায় না, তাই একই পরিবর্তন এক ডিপ্লয়মেন্টকে কাজ করাতে পারে আর অন্যকে কিছুই ফেরত দিতে না পারে। স্ট্যানজা পুনর্লিখনের আগে এন্ডপয়েন্টটি প্রকৃত ব্যবহারকারী ও গ্রুপের জন্য আসলে কী ফেরত দেয় তা নিশ্চিত করুন। রেফারেল ও TLS আবার আলাদা বিষয়, কারণ রেফারেল অনুসরণ করতে হয় এবং TLS দরকার এমন এন্ডপয়েন্টের মিলিত ট্রাস্ট ফাইল দরকার।
অ্যাকাউন্টের অবস্থা ও অনুসন্ধান পরিধি নিজ নিজ ফিল্ডে রাখুন
নিষ্ক্রিয় পতাকাটি ফিল্টারে থাকা উচিত, গ্রুপ যাচাইয়ে নয়। Active Directory-তে এটি userAccountControl-এর দ্বিতীয় বিট, এবং সেই শর্ত ছাড়া বৈধ পাসওয়ার্ডসহ একটি নিষ্ক্রিয় অ্যাকাউন্ট প্রমাণীকরণ করে তারপর গ্রুপ ধাপে ব্যর্থ হয়, যা অনুমোদন ত্রুটির মতো দেখায়। অনুসন্ধান পরিধি বেস DN-এ থাকা উচিত, কারণ ডোমেইন রুট থেকে শুরু করা ধীরতর এবং আপনি যে সাংগঠনিক ইউনিট কভার করতে চেয়েছিলেন তার বাইরের অবজেক্ট মিলতে পারে।
বাইন্ড অ্যাকাউন্টের অধিকারও সংকীর্ণ রাখুন। বিস্তৃত ডিরেক্টরি অধিকার ভুল কনফিগার করা ফিল্টারকে সফল কোয়েরিতে পরিণত করে এবং কেউ অ্যাকাউন্ট অডিট না করা পর্যন্ত বাগটি লুকিয়ে রাখে। সদস্যপদ ডিরেক্টরিতেই বদলান, কখনও স্থানীয় ব্যতিক্রম তালিকায় নয়, যাতে অ্যাক্সেস সরাতে অ্যাকাউন্ট নিষ্ক্রিয় করাই যথেষ্ট হয়। যদি অন্য দল গ্রুপ পরিচালনা করে, ফিল্টার লেখার আগে তারা যে অ্যাট্রিবিউট পূরণ করে তা নিয়ে একমত হন।
তিনটি অ্যাকাউন্ট দিয়ে ফলাফল প্রমাণ করুন
কনফিগারেশনটি তিনটি পরিচয়ের বিরুদ্ধে চালান: একজন অনুমোদিত সদস্য, গ্রুপের বাইরের একটি বৈধ অ্যাকাউন্ট, এবং একটি অ্যাকাউন্ট যা নিষ্ক্রিয় করা হয়েছে। যদি তিনটিই প্রত্যাখ্যাত হয়, বাইন্ড বা গ্রুপ কোয়েরি নষ্ট; যদি তিনটিই গৃহীত হয়, কোনো গ্রুপ শর্তই প্রয়োগ হচ্ছে না। মিশ্র ফলাফলই একমাত্র ফলাফল যা প্রমাণ করে কনফিগারেশন আপনার দরকারের ক্ষেত্রগুলি পৃথক করে।
প্লাগইনকে দোষারোপের আগে একই তিনটি উত্তর সরাসরি ডিরেক্টরি থেকে পড়ুন। প্রথম কোয়েরি ফিল্টার যে গ্রুপ অ্যাট্রিবিউটের উপর নির্ভর করে তা দেখায়, এবং দ্বিতীয়টি অ্যাকাউন্ট-নিয়ন্ত্রণ মান দেখায়। আপনার নিজের বেস DN, অ্যাকাউন্ট ও এন্ডপয়েন্ট বসান:
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControlযে ব্যবহারকারীর memberOf খালি ফিরে আসে সে ডিরেক্টরির সত্য, প্লাগইনের বাগ নয়, আর নিষ্ক্রিয় করার পরেও যে অ্যাকাউন্ট প্রমাণীকরণ করে তার মানে ফিল্টারে অ্যাকাউন্ট-নিয়ন্ত্রণ শর্তটি নেই। আগে সেই প্রমাণ ঠিক করুন, তারপর তিন-অ্যাকাউন্ট পরীক্ষা আবার চালান। ব্যর্থ ধাপের নাম বলা লগ লাইনটি কনফিগারেশন পরিবর্তনের পাশে রাখুন, যাতে পরের ব্যক্তি অনুসন্ধান পুনরাবৃত্তি না করে অনুমোদনকে প্রমাণীকরণ থেকে আলাদা করতে পারেন।