এই LDAP পাসওয়ার্ড ত্রুটিটি আসলে ব্যবহারকারীর পাসওয়ার্ড নাও হতে পারে
বাইন্ড ব্যর্থতা ব্যবহারকারীর নয়, সার্ভিস অ্যাকাউন্ট বা অনুসন্ধান পরিসর থেকেও আসতে পারে। কারও পাসওয়ার্ড রিসেট করার আগে বাইন্ডগুলো আলাদা করুন।
লগ যদি শুধু বলে যে একটি বাইন্ড প্রত্যাখ্যাত হয়েছে, তখন ব্যবহারকারীর পাসওয়ার্ড রিসেট করা ভুল প্রথম পদক্ষেপ। ডিরেক্টরি প্লাগইনে একবার লগইনে একাধিক বাইন্ড থাকে, এবং প্রত্যাখ্যানটি অনুসন্ধান চালানো সার্ভিস অ্যাকাউন্টেরও হতে পারে। সেই ক্ষেত্রে ব্যবহারকারীর ক্রেডেনশিয়াল রিসেট করলে কিছুই বদলায় না। বরং এমন কাউকে লক আউট করা হয় যে কখনো সমস্যাই ছিল না।
একটি লগইন, একাধিক বাইন্ড
নিবেদিত ডিরেক্টরি অ্যাকাউন্টযুক্ত কনফিগারেশন সাধারণত চারটি ধাপ ক্রমানুসারে সম্পন্ন করে, এবং এর যেকোনোটি লগইন শেষ করতে পারে।
connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groupsপ্লাগইনটি ব্যবহারকারী-প্রমাণীকরণ সংযোগ তৈরি করে সেই একই হেল্পার দিয়ে যা প্রথম সংযোগ সামলায়, তাই সেই হেল্পার সংযোগ করার সময়, TLS নিয়ে দরকষাকষির সময়, বা সার্ভিস অ্যাকাউন্ট হিসেবে বাইন্ড করার সময় ব্যর্থ হতে পারে। পাসওয়ার্ড সম্পর্কিত উচ্চ-স্তরের বার্তাটি পরে তৈরি হয়, এবং এটি বহন করে না কোন পরিচয় জড়িত ছিল। এ কারণেই কেবল ত্রুটির লেখা আপনাকে বলতে পারে না ব্যবহারকারী নাকি সার্ভিস অ্যাকাউন্ট প্রত্যাখ্যাত হয়েছে।
বার্তার আগের লাইনগুলো পড়ুন, এবং ব্যর্থতা ঘটার মুহূর্তটি লক্ষ করুন। শুরুতেই, কোনো ব্যবহারকারী আসার আগে প্রত্যাখ্যান হলে তা কনফিগার করা অ্যাকাউন্ট বা এন্ডপয়েন্টের দিকে ইঙ্গিত করে। সফল অনুসন্ধানের পরে কেবল একজন ব্যক্তির জন্য প্রত্যাখ্যান দেখা গেলে তা সেই ব্যক্তির এন্ট্রি বা অ্যাকাউন্টের অবস্থার দিকে ইঙ্গিত করে।
ত্রুটিটিকে একটি পরিচয়ের সঙ্গে জোড়া দিন
ব্যবহারিক নিয়ম হলো তিনটি বিষয় একসঙ্গে লিখে রাখা: কখন ব্যর্থ হলো, কোন অপারেশন চলছিল, এবং কোন পরিচয় উপস্থাপিত হয়েছিল। এই ত্রয়ী ছাড়া কেবল শেষ বাক্যটি রাখা লগে দুইটি খুব ভিন্ন ত্রুটি একই রকম দেখায়।
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
কনফিগার করা অ্যাকাউন্ট ব্যর্থ হলে কোনো ব্যবহারকারী রেকর্ড স্পর্শ করার আগে সেই অ্যাকাউন্ট ও সংযোগ পরীক্ষা করুন। সফল অনুসন্ধানের পরে ব্যবহারকারী বাইন্ড ব্যর্থ হলে অনুসন্ধান যে এন্ট্রি ফিরিয়েছে তা দেখুন, আপনি যে এন্ট্রি ফিরবে ভেবেছিলেন তা নয়। দুই পথ কেবল একটি বার্তা ভাগ করে, আর কিছু নয়। কোনটি আপনি বাদ দিয়েছেন তা লিখে রাখুন, কারণ পরের ব্যক্তি ঠিক সেটাই জিজ্ঞাসা করবে।
স্বতন্ত্র নাম একটি তথ্য, অনুমান নয়
একটি নামের উপাদান অপরিচিত দেখায় বলে তা বদলানো কার্যকর কনফিগারেশন ভাঙার একটি সাধারণ উপায়। Active Directory-তে ব্যবহারকারী অবজেক্টের ডিফল্ট স্থান হলো Users নামের একটি কন্টেইনার, আর কন্টেইনার একই নামের একটি সাংগঠনিক ইউনিটের মতো একই ধরনের অবজেক্ট নয়।
ডিরেক্টরি প্রশাসকের কাছে অ্যাকাউন্টের প্রকৃত স্বতন্ত্র নাম চান, অথবা অবজেক্ট থেকেই তা পড়ুন। নিচের দুটির প্রত্যেকটিই নিজ নিজ ডিরেক্টরিতে সঠিক হতে পারে, তাই কোনোটিই স্মৃতি থেকে টাইপ করা উচিত নয়।
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=exampleস্থানান্তর বা নাম পরিবর্তন সেই মানটি বদলে দেয়, অথচ অ্যাকাউন্ট ও পাসওয়ার্ড বৈধ থাকে, ফলে গত ত্রৈমাসিকে কাজ করা কনফিগারেশন কেউ ক্রেডেনশিয়াল না ছুঁয়েও এই ত্রৈমাসিকে ব্যর্থ হতে পারে। যেকোনো পুনর্গঠনের পরে কনফিগার করা স্ট্রিংটি ডিরেক্টরির বর্তমান অ্যাট্রিবিউটের সঙ্গে তুলনা করুন। নীরব মাইগ্রেশনের পরেও এটি করুন, কেবল রিপোর্ট করা বিভ্রাটের পরেই নয়।
অনুসন্ধান পরিসর কোনো সার্ভিস অ্যাকাউন্ট নয়
বাইন্ড পরিচয় ও অনুসন্ধান পরিসর ভিন্ন প্রশ্নের উত্তর দেয়: প্লাগইন কার নামে প্রমাণীকরণ করে, এবং কোথায় মানুষ খোঁজে। সফল বাইন্ডের পরে কোনো মিলে যাওয়া ব্যবহারকারী না থাকা পরিসর, ফিল্টার বা পড়ার অনুমতির সমস্যা, এবং অ্যাকাউন্টের স্বতন্ত্র নাম ব্যবহারকারীদের বেস দিয়ে বদলালে সেটিতে কিছুই বদলায় না।
নিশ্চিত করুন যে সার্ভিসটি আপনার সম্পাদিত কনফিগারেশন লোড করেছে, এবং এর এন্ডপয়েন্ট, TLS বিশ্বাস ও প্রমাণীকরণ মোড কোনো কার্যকর প্রশাসনিক পরীক্ষার সঙ্গে মেলে। ভিন্ন অ্যাকাউন্ট দিয়ে বা ভিন্ন ডোমেইন কন্ট্রোলারের বিরুদ্ধে হাতে-কলমে খোঁজা সমতুল্য পরীক্ষা নয়।
সংরক্ষিত গোপন তথ্য যাচাই করুন, এবং পাসওয়ার্ড কোথাও না ছেপে অ্যাকাউন্টটি সক্রিয়, মেয়াদোত্তীর্ণ বা লক আউট কি না দেখুন। মেয়াদোত্তীর্ণ হওয়া সহজে বাদ পড়ে, কারণ অ্যাকাউন্টটি যে দিন আর কাজ করে না সেই দিন পর্যন্ত চলতেই থাকে। অসম্পর্কিত কোনো সার্ভিস থেকে উত্তরাধিকারসূত্রে পাওয়া লক আউটও সমান নীরব। কোনোটিই সার্ভিস অ্যাকাউন্টের নাম উল্লেখ করা বার্তা তৈরি করে না।
গ্রুপ নিয়ম শেষে আসে
বাইন্ড সফল হওয়ার পরে অনুমোদন চলে, তাই গ্রুপ যাচাই বাইন্ড ব্যর্থতার কারণ হতে পারে না, এবং গ্রুপের শর্ত সরিয়ে ফেললে তা মেরামতও হয় না। লগইন এখন গ্রুপ পর্যায়ে পৌঁছালে বাকি সমস্যা সদস্যপদ, ক্রেডেনশিয়াল নয়।
ত্রুটি মিলিয়ে দিতে সার্ভিস অ্যাকাউন্টকে বিস্তৃত ডিরেক্টরি অধিকার দেওয়া পুরো স্থাপনার প্রবেশ নীতি বদলে দেয়। এটিকে নিজস্ব পর্যালোচনাসহ একটি নিরাপত্তা সিদ্ধান্ত হিসেবে দেখুন, এমন একটি বার্তার সমাধান হিসেবে নয় যা আপনি এখনো কোনো পরিচয়ের সঙ্গে যুক্ত করেননি।