একসময় দক্ষিণ আমেরিকাতে একটি সুন্দর উষ্ণ ভার্চুয়াল-জঙ্গল ছিল এবং সেখানে স্কুইড সার্ভার থাকত। এখানে নেটওয়ার্কটির উপলব্ধিযোগ্য চিত্র রয়েছে:
<the Internet>
|
|
A | B
Users <---------> [squid-Server] <---> [LDAP-Server]
যখন Usersইন্টারনেটের সাথে অনুরোধ অ্যাক্সেস, squidতাদের নাম এবং পাসপোর্ট জিজ্ঞেস করে, তাদের পরিচয় প্রমাণ LDAPএবং যদি LDAP তাঁদেরও অনুমোদন, তারপর তিনি তাদের মঞ্জুর করেন।
কিছু স্নিফার ব্যবহারকারী এবং স্কুইড [পথ এ] এর মধ্যে পথে পাসপোর্ট চুরি না করা পর্যন্ত সবাই খুশি ছিল। এই বিপর্যয় ঘটেছিল কারণ স্কুইড Basic-Authenticationপদ্ধতি ব্যবহার করা হয়েছিল ।
জঙ্গলের লোকজন এই সমস্যা সমাধানের জন্য জড়ো হয়েছিল। কিছু বানি NTLMপদ্ধতি ব্যবহারের প্রস্তাব দিয়েছিল । Prefered সাপ Digest-Authenticationযখন Kerberosগাছ দ্বারা বাঞ্ছনীয়।
সর্বোপরি, জঙ্গলের লোকেদের দ্বারা প্রদত্ত অনেকগুলি সমাধান বিভ্রান্ত হয়েছিল! সিংহ পরিস্থিতি শেষ করার সিদ্ধান্ত নিয়েছে। তিনি সমাধানের নিয়মগুলি চিৎকার করেছিলেন:
- সমাধান কি নিরাপদ হবে!
- বেশিরভাগ ব্রাউজার এবং সফ্টওয়্যারগুলির জন্য সমাধানের কাজটি (যেমন সফ্টওয়্যার ডাউনলোড করুন)
- সমাধানটি সহজ হতে পারে এবং অন্যান্য বিশাল সাবসিস্টেমের দরকার নেই (সাম্বা সার্ভারের মতো)
- পদ্ধতিটি বিশেষ ডোমেনের উপর নির্ভর করবে না। (যেমন অ্যাক্টিভ ডিরেক্টরি)
তারপরে, একটি বানর দ্বারা প্রস্তাবিত একটি খুব সংবেদনশীল-বিস্তৃত-চতুর সমাধান, তাকে জঙ্গলের নতুন রাজা করে তোলে!
আপনি কি সমাধান করতে পারেন অনুমান করতে পারেন?
টিপ: সিংহের
মধ্যবর্তী পথ squidএবং LDAPসুরক্ষিত, সুতরাং সমাধানটিকে এটি সুরক্ষিত করতে হবে না।
দ্রষ্টব্য: দুঃখিত যদি গল্পটি বিরক্তিকর এবং অগোছালো হয় তবে এর বেশিরভাগই বাস্তব! =)
/~\/~\/~\ /\~/~\/~\/~\/~\ ((/~\/~\/~\/~\/~\)) (/~\/~\/~\/~\/~\/~\/~\) (//// ~ ~ \\\\) (\\\\( (0) (0) )////) (\\\\( __\-/__ )////) (\\\( /-\ )///) (\\\( (""""") )///) (\\\( \^^^/ )///) (\\\( )///) (\/~\/~\/~\/) ** (\/~\/~\/) *####* | | **** /| | | |\ \\ _/ | | | | \_ _________// Thanks! (,,)(,,)_(,,)(,,)--------'
হালনাগাদ:
ম্যাসিমো ব্যাখ্যা করেছিলেন যে Users- squidএবং squid- এর মধ্যে প্রমাণীকরণের পদ্ধতিটি LDAPএকই রকম হয় না। আমরা ব্যবহারকারীর কাছ থেকে প্রমাণীকরণের তথ্য এবং সত্যায়িত সংগৃহীত ডেটাতে সালিসি পদ্ধতি ব্যবহার করতে সালিসির পদ্ধতি ব্যবহার করতে পারি।
তবে একটি সমস্যা রয়েছে: সমস্ত প্রকারের প্রমাণীকরণকারীর ইনপুট / আউটপুট এক রকম নয়। উদাহরণ স্বরূপ:
- একটি
Basicপ্রমাণীকরণকারীর একটি লাইনে "ব্যবহারকারীর পাসওয়ার্ড" জুটি পড়তে হবে এবংOKযদি ব্যবহারকারী-পাস সঠিক হয় বা একটি উত্তর দেয়ERR - একটি
Digestপ্রমাণকারী একটি পড়া উচিতusername:realmএবং উত্তর একটি হেক্স এনকোডেডHA(A1)অথবা একটিERR।
ক্লায়েন্ট-স্কুইড পদ্ধতি এবং স্কুইড-এলডিএপ পদ্ধতির মধ্যে সরাসরি সম্পর্ক নেই বলে ধারণা করা হয়েছে, ক্লায়েন্টের কাছ থেকে সংগৃহীত ডেটা স্কুইড-এলডিএপ অংশে ব্যবহৃত পদ্ধতির সাথে সামঞ্জস্যপূর্ণ হতে হবে। সুতরাং, আমরা যদি ব্যবহারকারীদের পক্ষে প্রমাণীকরণের পদ্ধতিটি পরিবর্তন করি তবে আমাদের সম্ভবত আমাদের প্রমাণীকরণকারীও পরিবর্তন করা উচিত।
সুতরাং সমস্যাটি এটিকে সহজতর করে:
প্রথম স্তরে, আমি (বানর!) ব্যবহারকারীর পক্ষে একটি ভাল প্রমাণীকরণ পদ্ধতি খুঁজছি। বেশিরভাগ ব্রাউজার দ্বারা সুরক্ষিত এবং সমর্থিত কোন পদ্ধতিটি আপনি সুপারিশ করেন ? আমি মাঝে বিভ্রান্ত মধ্যে আছি
NTLM,KerberosএবংDigest।যেখানে আমি এমন একটি প্রমাণীকরণকারীর সন্ধান করতে পারি যা নির্বাচিত পদ্ধতির শংসাপত্রগুলির তথ্য সমর্থন করে এবং এলডিএপি-এর মাধ্যমে প্রমাণীকরণ করে।