Mac-এ Kerberos SSO ও VPN: দুটি সাইন-ইন পথের তুলনা

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

দুটি প্রক্রিয়া, একটি সাইন-ইন স্ক্রিন

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

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

Kerberos এক্সটেনশনের নেটওয়ার্কে যা দরকার

Apple-এর Kerberos SSO এক্সটেনশন গাইড সক্রিয় টিকিট সংগ্রহসহ নেটিভ Active Directory প্রমাণীকরণ বর্ণনা করে, যা ডোমেইন বাইন্ডিংয়ের বদলে স্থানীয় অ্যাকাউন্টের সঙ্গে জোড়া লাগে। এটি যা করতে পারে না তা হলো ডোমেইন নিয়ন্ত্রকদের পর্যন্ত একটি পথ উদ্ভাবন করা। Mac-এর দরকার এমন একটি রিজলভার যা Kerberos সার্ভিস রেকর্ডের উত্তর দেয়, এবং এমন একটি রুট যা অনুমোদিত টানেলের মধ্য দিয়ে সেগুলোতে পৌঁছায়। পরিষ্কারভাবে ইনস্টল হওয়া একটি প্রোফাইল কিছুই প্রমাণ করে না, যতক্ষণ ক্লায়েন্ট থেকে ডোমেইন সত্যিই আবিষ্কার করা না যায়।

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

klist
sudo sntp -sS time.apple.com

প্রতি-অ্যাপ VPN ঠিক করে এক্সটেনশনটি কাজ করতে পারবে কি না

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

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

ব্রাউজার পরিচয় সেশন একটি ভিন্ন চুক্তি

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

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

ধাপে ধাপে যান, অংশে অংশে নয়

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

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

প্রতিটি স্তরের মালিকও লিখে রাখুন, কারণ যে Kerberos ডোমেইনের কেউ রক্ষণাবেক্ষণ করে না তা পুরোনো হয়ে যায়। যে চেইন কেউ বর্ণনা করতে পারে না, তা এমন চেইন যা কেউ ডিবাগ করতে পারে না।