Okta WiFi Authentication: সেটআপের পদক্ষেপ, বিকল্প এবং সমাধান
Published
Okta WiFi প্রামাণীকরণ সম্পর্কে জনপ্রিয় পরামর্শ হলো আপনার অ্যাক্সেস পয়েন্টগুলোকে Okta-র দিকে নির্দেশ করা, MFA চালু করা এবং শেয়ার করা পাসওয়ার্ড তুলে দেওয়া। তবে এই বাক্যের ওপর ভিত্তি করে আপনার রোলআউট তৈরি করবেন না। Okta আপনার অ্যাক্সেস পয়েন্টগুলোতে সরাসরি কোনো ওয়্যারলেস প্রামাণীকর্তা নয়, একটি নেটিভ 802.1X সাপ্লিক্যান্ট প্রায়শই একটি ইন্টারেক্টিভ চ্যালেঞ্জ সঠিকভাবে প্রদর্শন করতে পারে না, এবং যে অংশটি একটি পুরো সাইটের সংযোগ বিচ্ছিন্ন করে দেয় তা সাধারণত সার্টিফিকেট ট্রাস্ট বা একটি খারাপ ডিভাইস প্রোফাইল, MFA প্রম্পট নয়।
তার মানে এই নয় যে আইডেন্টিটি ভিত্তিক WiFi ভুল দিক। Okta Secure Sign-In Trends Report 2024 রিপোর্ট করেছে যে ২০২৪ সালের জানুয়ারী পর্যন্ত Okta Workforce Identity ব্যবহারকারীদের ৬৬% মাল্টিফ্যাক্টর অথেন্টিকেশন দিয়ে সাইন ইন করেছেন, যেখানে প্রশাসকদের মধ্যে এই ব্যবহারের হার ৯১% ছুঁয়েছে। এই পরিসংখ্যানগুলি অ্যাপ্লিকেশন সাইন-ইন বর্ণনা করে, WiFi সেশন নয়, তবে তারা দেখায় যে আইডেন্টিটি অ্যাসুরেন্স একই ডিরেক্টরিতে শুধুমাত্র পাসওয়ার্ডের স্থান নিচ্ছে যা আপনি নেটওয়ার্ক নীতির জন্য ব্যবহার করবেন।
আমি একটি কঠিন প্রশ্ন দিয়ে শুরু করব। কোন কম্পোনেন্ট EAP এক্সচেঞ্জ বন্ধ করে, কোন সিস্টেম ডিভাইসে ট্রাস্ট ইস্যু এবং রিনিউ করে, এবং যেকোনো একটি পরিবর্তিত হলে কী ঘটে? একটি ল্যাবে এই তিনটি প্রশ্নের উত্তর দিন এবং Okta WiFi অ্যাথেনটিকেশন পরিচালনাযোগ্য হয়ে উঠবে। এগুলো এড়িয়ে গেলে আপনাকে প্রতিটি অপারেটিং সিস্টেমে একটি করে প্রোডাকশন SSID ডিবাগ করতে হবে।
সূচিপত্র
- আপনার নেটওয়ার্ক সমর্থন করে এমন Okta ইন্টিগ্রেশন পাথ বেছে নিন
- সংযুক্ত করার আগে সার্টিফিকেট ট্রাস্ট এবং ডিভাইস অনবোর্ডিং
- ধাপে ধাপে কিভাবে Okta RADIUS Agent সেট আপ করবেন
- কন্ডিশনাল অ্যাক্সেস এবং ডিভাইস পোসচার নিয়ম সেট করুন
- ব্যর্থ Okta WiFi লগইন ট্রাবলশুট করা
- সাইটগুলি সম্প্রসারণ করার আগে পাইলট নিশ্চিত করুন
আপনার নেটওয়ার্ক সমর্থন করে এমন Okta ইন্টিগ্রেশন পাথটি বেছে নিন
Okta নিজের থেকে আপনার অ্যাক্সেস পয়েন্টগুলিতে 802.1X চালায় না। একটি ওয়ারলেস কন্ট্রোলার, অ্যাক্সেস পয়েন্ট, বা পৃথক RADIUS সার্ভিসকে প্রমানীকরণকারী হিসেবে কাজ করতে হয়, প্রতিটি অনুরোধ ফরওয়ার্ড করতে হয়, এবং যে Access-Accept, Access-Reject, VLAN, বা রোল ফেরত আসে তা প্রয়োগ করতে হয়। Okta আইডেন্টিটি সংক্রান্ত সিদ্ধান্ত প্রদান করে। এটি WLAN ফেসিং প্রোটোকলের কাজকে সরিয়ে দেয় না।
সেই কারণেই প্রথম পছন্দটি কোনও Okta সেটিংস নয়। এটি এমন একটি আর্কিটেকচার যা আপনার কন্ট্রোলার এবং ক্লায়েন্টরা প্রকৃতপক্ষে সম্পূর্ণ করতে পারে। Okta Cisco Meraki RADIUS ইন্টিগ্রেশন ডকুমেন্টেশনে একটি 802.1X EAP সিকিউরিটি কনফিগারেশনের বর্ণনা দেওয়া হয়েছে যেখানে ওয়্যারলেস ক্লায়েন্ট নেটওয়ার্ক অথেন্টিকেশনের সময় একটি Okta ইউজারনেম এবং পাসওয়ার্ড প্রদান করে। এটি একটি নির্দিষ্ট ডকুমেন্ট করা Meraki পাথ, প্রতিটি কন্ট্রোলার এবং EAP পদ্ধতি একইভাবে কাজ করবে তার কোনো প্রমাণ নয়।
চারটি পাথ যা বিভিন্ন সমস্যার সমাধান করে
| বিকল্প | Okta শংসাপত্র যাচাই করে | সবচেয়ে উপযুক্ত | প্রধান সীমাবদ্ধতা |
|---|---|---|---|
| Okta RADIUS Server Agent | PAP-এর মাধ্যমে ব্যবহারকারীর নাম এবং পাসওয়ার্ড | ল্যাব-যাচাইকৃত PAP পাথসহ লেগাসি কন্ট্রোলার | Okta ডকুমেন্টেশনে WiFi ইনফ্রাস্ট্রাকচার সমর্থিত হিসেবে তালিকাভুক্ত নেই |
| Cisco Meraki 802.1X-এ Okta শংসাপত্র | EAP আদান-প্রদানে Okta ব্যবহারকারীর নাম এবং পাসওয়ার্ড | Meraki WLAN যা Okta-এর নথিভুক্ত EAP সিকিউরিটি সেটআপ অনুসরন করে | Okta নথির Meraki কনফিগারেশনের সাথে সম্পর্কিত |
| Captive Portal-এ SAML বা SSO সাইন-ইন | আইডেন্টিটি প্রোভাইডারের মাধ্যমে ব্রাউজার সাইন-ইন | অতিথি এবং BYOD অনবোর্ডিং | 802.1X-এ কর্মীদের ডিভাইস প্রামাণীকরণ করে না |
| ডিরেক্টরি গ্রুপ মেম্বারশিপ সহ MDM-ইস্যুকৃত সার্টিফিকেট | MDM দ্বারা ইস্যুকৃত EAP-TLS ক্লায়েন্ট সার্টিফিকেট | বিভিন্ন সাইটের পরিচালিত কর্মী ডিভাইসসমূহ | একটি সার্টিফিকেট অথরিটি, MDM প্রোফাইল বিতরণ এবং একটি নবায়ন পরিকল্পনার প্রয়োজন |
RADIUS এজেন্ট সারিটি সাবধানে পড়ুন। এটিকে একটি লেগ্যাসি নেটওয়ার্ক অ্যাক্সেস ব্রিজ হিসেবে বিবেচনা করুন, একটি নেটিভ WiFi আইডেন্টিটি প্লেন হিসেবে নয়। সার্টিফিকেট ভিত্তিক EAP-TLS কেন্দ্রিক নির্মিত একটি কনভেনশনাল WPA2 বা WPA3-Enterprise ডিজাইন সরাসরি এমন একটি এজেন্টের সাথে কাজ করবে বলে ধরে নেওয়া যায় না যার ডকুমেন্টেড প্রোটোকল হল PAP, এবং বিশেষ RADIUS অ্যাপ্লিকেশন সিনারিওর জন্য কেবল EAP-TTLS এবং EAP-GTC তালিকাভুক্ত করা হয়েছে।
Captive Portal SSO সম্পূর্ণ ভিন্ন কাজ করে। এটি গেস্ট এবং আনম্যানেজড BYOD-কে ইন্টারনেট অ্যাক্সেস দেওয়ার আগে একটি ব্রাউজার জার্নি প্রদান করে এবং কে কানেক্টেড আছে তা রেকর্ড করতে পারে। এটি কিন্তু কর্মীদের ল্যাপটপকে প্রথম প্যাকেট থেকেই এনক্রিপ্টেড 802.1X অ্যাক্সেস দেয় না এবং হেডলেস ডিভাইসগুলি এটি সম্পন্ন করতে পারে না। কর্মীদের নেটওয়ার্ক অ্যাথেনটিকেশনের জায়গায় একটি সাধারণ পোর্টাল ডেমোকে বিকল্প হিসেবে ব্যবহার করতে দেবেন না।
সিদ্ধান্ত নিতে তিনটি মানদণ্ড ব্যবহার করুন
- কন্ট্রোলার এবং EAP সাপোর্ট: সঠিক কন্ট্রোলার মডেল, ফার্মওয়্যার, সাপ্লিক্যান্ট এবং EAP মেথড একসাথে নিশ্চিত করুন। 802.1X-এর জন্য ডাটাশিটের দাবি আপনার PAP, EAP-TTLS, বা EAP-TLS পাথকে প্রমাণ করে না।
- ডিভাইস ম্যানেজমেন্ট: ম্যানেজড ল্যাপটপ এবং ফোনগুলো স্বয়ংক্রিয়ভাবে সার্টিফিকেট ও ট্রাস্ট প্রোফাইল পেতে পারে। আনম্যানেজড ডিভাইসগুলোর জন্য পাসওয়ার্ড ভিত্তিক অনবোর্ডিং বা একটি পোর্টাল লেনের প্রয়োজন হয়।
- প্রভাবের মাত্রা (Blast radius): যেসব সাইট, SSID, এবং কন্ট্রোলার টাইপ একসাথে পরিবর্তিত হয় সেগুলো গণনা করুন। বেশি সংখ্যক সাইটের ক্ষেত্রে ম্যানুয়াল সেটআপের বদলে সেন্ট্রালাইজড প্রোফাইল এবং সার্টিফিকেট ডেলিভারির প্রয়োজন বেশি।
সিদ্ধান্তের নিয়ম: একটি ল্যাব পরীক্ষা করার পরেই কেবল RADIUS এজেন্ট ব্যবহার করুন যা সুনির্দিষ্ট কন্ট্রোলার এবং ক্লায়েন্টের সংমিশ্রণ প্রমাণ করে। পরিচালিত কর্মীদের ডিভাইসের জন্য, প্রথমে সার্টিফিকেট পাথ পরিকল্পনা করুন এবং পাসওয়ার্ডগুলিকে ফলব্যাক হিসেবে বিবেচনা করুন।
সংযুক্ত হওয়ার আগে সার্টিফিকেট ট্রাস্ট এবং ডিভাইস অনবোর্ডিং
একটি হেল্প ডেস্কে পৌঁছানো অধিকাংশ Okta WiFi ব্যর্থতাই MFA ব্যর্থতা নয়। সেগুলো হল ট্রাস্টের ব্যর্থতা। ডিভাইসটি RADIUS সার্ভার সার্টিফিকেটকে বিশ্বাস করে না, 802.1X প্রোফাইল ভুল EAP মেথড বা সার্ভারকে নির্দেশ করে, ক্লায়েন্ট সার্টিফিকেট পৌঁছায়নি, অথবা ব্যবহারকারী পলিসির জন্য প্রয়োজনীয় ফ্যাক্টরটি এনরোল করেননি। Okta সঠিকভাবে পরিচয় মূল্যায়ন করতে পারে, অথচ ডিভাইসটি জিজ্ঞেস করার মতো যথেষ্ট দূর এগোতেই পারে না।
এনরোলমেন্ট পয়েন্টটি নথিভুক্ত, তাত্ত্বিক নয়। Okta RADIUS অ্যাপ্লিকেশন ডকুমেন্টেশন উল্লেখ করে যে EAP-TTLS পাসওয়ার্ড এবং পাসকোড প্রামাণীকরণ সমর্থন করে তবে EAP-TTLS এনরোলমেন্ট সমর্থন করে না, তাই ব্যবহারকারীরা প্রয়োজনীয় ফ্যাক্টরে আগে থেকে এনরোল না থাকলে প্রামাণীকরণ ব্যর্থ হতে পারে। Okta-এর Meraki ট্রাবলশুটিং অবৈধ বা অবিশ্বাস্য সার্টিফিকেট এবং ভুলভাবে চালিত 802.1X প্রোফাইলকেও সংযোগ ব্যর্থতার কারণ হিসেবে চিহ্নিত করে। প্রথমে এনরোল করুন। পরে সংযোগ করুন।
দুটি EAP পছন্দের সততার সাথে তুলনা করুন
| পদ্ধতি | প্রেরিত শংসাপত্র | প্রথম সংযোগের আগে এনরোলমেন্ট | যেখানে এটি প্রযোজ্য | যার জন্য পরিকল্পনা করতে ব্যর্থতা |
|---|---|---|---|---|
| পাসওয়ার্ড বা পাসকোড সহ EAP-TTLS | একটি TLS টানেলের মধ্যে Okta পাসওয়ার্ড বা পাসকোড | প্রয়োজনীয়, কারণ EAP-TTLS এনরোলমেন্ট সমর্থন করে না | এনরোল করা ব্যবহারকারীদের সাথে মিশ্র বা অনিয়ন্ত্রিত ডিভাইস | যে ব্যবহারকারীরা এখনও ফ্যাক্টরে এনরোল হননি তারা সংযোগ করতে পারবেন না |
| MDM-ইস্যুকৃত সার্টিফিকেট সহ EAP-TLS | SCEP এর মাধ্যমে ইস্যু করা ক্লায়েন্ট সার্টিফিকেট | প্রয়োজনীয়, যেখানে MDM দ্বারা সার্টিফিকেট পুশ করা হয় | স্কেলে পরিচালিত কর্পোরেট ডিভাইসসমূহ | একটি মেয়াদোত্তীর্ণ সার্ভার বা ক্লায়েন্ট সার্টিফিকেট পুরো সাইটে অ্যাক্সেস সরিয়ে দেয় |
EAP-TTLS ডিজাইনে পাসওয়ার্ড বজায় রাখে। এগুলো ফিিশিং, পুনরায় ব্যবহার, হেল্প ডেস্ক রিসেট এবং একটি WiFi সাপ্লিক্যান্টে জটিল চ্যালেঞ্জ পরিচালনার ঝুঁকির মুখে পড়ে। EAP-TLS ওয়্যারলেস এক্সচেঞ্জ থেকে পাসওয়ার্ড সরিয়ে দেয় এবং মিউচুয়াল প্রামাণীকরণ প্রদান করে, তবে এটি কাজটিকে আপনার সার্টিফিকেট অথরিটি, SCEP ইস্যুয়েন্স, রিনিউয়াল এবং রিভোকেশন পাইপলাইনে স্থানান্তর করে। কোনোটিই বিনামূল্যে নয়। আপনি কেবল বেছে নিচ্ছেন যে অপারেশনের চাপটি কোথায় থাকবে।
অধিকাংশ গাইড এড়িয়ে যায় এমন লাইফসাইকেল তৈরি করুন
- সার্টিফিকেট অথরিটি নির্বাচন করুন: কোন CA RADIUS সার্ভার সার্টিফিকেটে স্বাক্ষর করবে এবং কোন CA ক্লায়েন্ট সার্টিফিকেট ইস্যু করবে তা নির্ধারণ করুন। প্রোফাইলে এগুলি গুলিয়ে ফেলবেন না এবং পাবলিক সার্ভার সার্টিফিকেটের মেয়াদ শেষ হওয়ার বিষয়টি যেন আপনাকে অবাক না করে।
- আগাম নবায়নের সময়সূচী করুন: মেয়াদ শেষ হওয়ার বেশ আগেই সার্ভার সার্টিফিকেট নবায়ন করুন, পুরানোটি কাজ করার সময়ই নতুন ট্রাস্ট অ্যাঙ্কর পুশ করুন এবং ডিভাইসগুলি প্রত্যাশিত সার্ভারের নাম যাচাই করছে কিনা তা নিশ্চিত করুন।
- MDM-এর মাধ্যমে প্রোফাইল পুশ করুন: SSID, EAP প্রকার, বিশ্বস্ত CA, সার্ভারের নাম এবং SCEP সার্টিফিকেট সরবরাহ করতে Intune, Jamf বা আপনার বিদ্যমান MDM ব্যবহার করুন। ম্যানুয়াল ইনস্টলেশন স্কেল করে না এবং অডিট করা যায় না।
- প্রয়োগের আগে অনবোর্ডিংয়ের ক্রম নির্ধারণ করুন: ডিভাইসগুলিকে একটি সাময়িক অনবোর্ডিং পাথ দিন, প্রোফাইল এবং সার্টিফিকেট পৌঁছেছে কিনা নিশ্চিত করুন, তারপর কর্মী SSID প্রয়োগ করুন। কোন ট্রাস্ট না থাকা একটি ডিভাইস তার ট্রাস্ট সংগ্রহ করার জন্য কর্মী নেটওয়ার্ক ব্যবহার করতে পারে না।
- বাতিলকরণ এবং পুনরুদ্ধারের পরিকল্পনা করুন: একটি ডিভাইস হারিয়ে গেলে, একটি সার্টিফিকেট বাতিল হলে, একটি CA পরিবর্তিত হলে বা MDM প্রোফাইল সরানো হলে কী হবে তা সংজ্ঞায়িত করুন। একটি অতিরিক্ত ডিভাইসে পুনরায় ইস্যু পরীক্ষা করুন।
যেকোনো সাইট পরিবর্তনের আগে একটি টেস্ট ম্যাট্রিক্স পরিচালনা করুন। Windows, macOS, iOS, এবং Android প্রতিটি পরিচালিত এবং অপরিচালিত হিসেবে, প্রথম সংযোগ, পুনরায় সংযোগ, অ্যাক্সেস পয়েন্টগুলোর মধ্যে রোমিং এবং একটি সিমুলেটেড সার্টিফিকেট নবায়নের পরে পরীক্ষা করুন। এতে একজন অনথিভুক্ত ব্যবহারকারী এবং প্রোফাইল সরিয়ে নেওয়া হয়েছে এমন একটি ডিভাইস অন্তর্ভুক্ত করুন।
ধরুন শুক্রবারে একটি শাখায় কোনো সতর্কবার্তা ছাড়াই একটি প্রোফাইল পুশ ব্যর্থ হয়েছে। সোমবারে, সেই স্থানের প্রতিটি ম্যানেজড ডিভাইস সার্ভার সার্টিফিকেট প্রত্যাখ্যান করছে, অথচ হেডকোয়ার্টার, যা প্রোফাইলটি পেয়েছিল, সেখানে ঠিকভাবে কাজ করছে। Okta পলিসি পরিবর্তিত হয়নি। পরিবর্তন হয়েছে ট্রাস্ট ডেলিভারিতে। এই কারণেই পোস্ট ইনসিডেন্স পর্যালোচনার জন্য ফেলে না রেখে আপনার গো লাইভ ক্রাইটেরিয়াতেই প্রোফাইল রিপোর্টিং রাখা উচিত।
ধাপে ধাপে কীভাবে Okta RADIUS এজেন্ট সেট আপ করবেন
অনুরোধের পাথ দিয়ে শুরু করুন, কারণ একটি লগইন ব্যর্থ হলে কোথায় দেখতে হবে তা এটি আপনাকে বলে। কন্ট্রোলার Okta RADIUS Server Agent-এ একটি RADIUS অনুরোধ পাঠায়, এজেন্ট Okta API গুলিকে কল করে, Okta পলিসি মূল্যায়ন করে, একটি ঐচ্ছিক MFA চ্যালেঞ্জ নেটওয়ার্ক ডিভাইসের মাধ্যমে ফিরে আসে, এবং এজেন্ট কন্ট্রোলারে Access-Accept বা Access-Reject ফেরত পাঠায়। প্রতিটি ধাপ অন্যদের ক্ষতি না করেই ব্যর্থ হতে পারে।
নিচের ডেপ্লয়মেন্ট সিকোয়েন্সটি Okta-র নেটওয়ার্ক অ্যাক্সেস সার্ভার গাইড-এর মডেলটি অনুসরণ করে, যা এজেন্টকে নেটওয়ার্ক অ্যাক্সেস সার্ভার এবং UDP port 1812-এর মাধ্যমে Okta পলিসি মূল্যায়নের মধ্যে অবস্থান দেয়। প্রথম পরীক্ষা থেকেই প্যাকেট এবং এজেন্ট লগিং উপলব্ধ রেখে, একটি ল্যাবে এই ক্রমানুসারে এটি তৈরি করুন।
ক্রমানুসারে ল্যাব পাথ তৈরি করুন
- একটি সার্ভিস হিসেবে এজেন্ট ইনস্টল করুন। একটি Windows বা Linux হোস্ট যা ওয়্যারলেস কন্ট্রোলার এবং Okta উভয়ের সাথেই যোগাযোগ করতে পারে, সেটিতে Okta RADIUS Server Agent ইনস্টল করুন। এটিকে এমন কোনো ওয়ার্কস্টেশনে রাখবেন না যা স্লিপ মোডে চলে যায়, অপ্রত্যাশিতভাবে প্যাচ করে বা কোনো নথিবিহীন ফায়ারওয়াল রুলের পেছনে অবস্থান করে। সাধারণ ভুল হলো সার্ভার কনসোল থেকে Okta-র পৌঁছানোর যোগ্যতা প্রমাণ করা, কিন্তু এজেন্ট পর্যন্ত কন্ট্রোলারের পৌঁছানোর যোগ্যতা কখনোই প্রমাণ না করা।
- Okta-তে RADIUS অ্যাপ্লিকেশন তৈরি করুন। অ্যাপ্লিকেশনটি তৈরি করুন, এজেন্টের প্রয়োজনীয় সেটিংসগুলো নোট করুন এবং এটির পরিবেশিত SSID ও সাইট স্কোপের সাথে নামটি সম্পর্কিত রাখুন। অস্পষ্ট অ্যাপের নাম পরবর্তীতে লগ খোঁজার কাজকে ধীরগতির করে তোলে। শুধুমাত্র উভয়ই RADIUS ব্যবহার করে বলেই Wi-Fi-এর জন্য কোনো VPN RADIUS অ্যাপ পুনরায় ব্যবহার করবেন না।
- কন্ট্রোলারকে RADIUS ক্লায়েন্ট হিসেবে কনফিগার করুন। ওয়্যারলেস কন্ট্রোলার বা নেটওয়ার্ক অ্যাক্সেস সার্ভারকে এজেন্ট IP অ্যাড্রেসের দিকে নির্দেশ করুন, UDP 1812 সেট করুন এবং উভয় প্রান্তে একটি মেলানো শেয়ার্ড সিক্রেট লিখুন। সিক্রেটটি টাইপ করুন, কোনো চ্যাট মেসেজ থেকে পেস্ট করবেন না যা শেষে একটি অতিরিক্ত স্পেস যোগ করতে পারে। সিক্রেট না মিললে ক্লায়েন্টের ক্ষেত্রে প্রায়শই এটিকে ভুল পাসওয়ার্ড বলে মনে হয়।
- উৎস সীমাবদ্ধ করুন। ক্লায়েন্ট সোর্স IP বা Okta নেটওয়ার্ক জোন কেবল কন্ট্রোলার অ্যাড্রেসগুলোর মধ্যেই সীমিত রাখুন। এটি যথেচ্ছ অভ্যন্তরীণ হোস্টগুলোকে এজেন্টে অথেনটিকেশন রিকোয়েস্ট পাঠানো থেকে বিরত রাখে। সাধারণ ভুল হলো টেস্টিংয়ের সময় ম্যানেজমেন্ট সাবনেট ব্যবহারের অনুমতি দেওয়া এবং পরে তা কখনোই সীমিত না করা।
- সঠিক Okta গ্রুপগুলো বরাদ্দ করুন। RADIUS অ্যাপ্লিকেশনটি কেবল সেই গ্রুপগুলোতে বরাদ্দ করুন যাদের এই SSID পাওয়া উচিত। গ্রুপ বরাদ্দ হলো আপনার কর্মী, ঠিকাদার এবং অ্যাডমিনিস্ট্রেটরদের প্রাথমিক সীমানা। পুরো কোম্পানিকে এটি বরাদ্দ করবেন না এবং পরবর্তীতে এমন ফায়ারওয়াল রুল দিয়ে সেগমেন্টেশন ঠিক করার প্রতিশ্রুতি দেবেন না যা এখনও কেউ লেখেনি।
- অ্যাক্সেপ্ট এবং রিজেক্ট টেস্ট করুন। বরাদ্দকৃত গ্রুপের ভেতরের একটি টেস্ট অ্যাকাউন্টের মাধ্যমে একটি ল্যাব ক্লায়েন্ট কানেক্ট করুন, তারপর অ্যাকাউন্টটি সরিয়ে নেওয়ার পর আবার একই অ্যাকাউন্ট টেস্ট করুন। আপনার কন্ট্রোলার লগ এবং Okta লগ উভয়েই উভয় ফলাফলের প্রয়োজন। কেবল সফলতা টেস্ট করা রিভোকেশন সম্পর্কে কিছুই প্রমাণ করে না।
- চ্যালেঞ্জ আচরণটি প্রমাণ করুন। পলিসিতে যদি MFA-র প্রয়োজন হয়, তবে নির্দিষ্ট ক্লায়েন্ট সাপ্লিক্যান্ট এবং কন্ট্রোলার তাদের টাইমআউটের মধ্যে চ্যালেঞ্জ উপস্থাপন ও তা ফেরত পাঠাতে পারে কিনা তা নিশ্চিত করুন। অনেকেই এটি সঠিকভাবে করতে পারে না। প্রম্পটটি কখনোই দেখা না গেলে, প্রোটোকলের সীমাবদ্ধতা বোঝার আগেই প্রোডাকশনে পলিসি দুর্বল করে এর সমাধান করবেন না।
অন্য কিছু টিউন করার আগে, একটি সম্পূর্ণ ল্যাব প্রমানীকরণ দেখুন এবং আপনার লগের সাথে প্রতিটি ধাপ তুলনা করুন।
Meraki ভ্যারিয়েন্টের জন্য, ক্লায়েন্ট Okta-র ডকুমেন্টেড 802.1X EAP কনফিগারেশনের অধীনে একটি Okta ইউজারনেম এবং পাসওয়ার্ড প্রদান করে। SSID সেটিংস পরিবর্তন করা চালিয়ে যাওয়ার আগে টেস্ট ক্লায়েন্টে সার্টিফিকেট ট্রাস্ট এবং ডেপ্লয় করা প্রোফাইল যাচাই করুন। একটি অবৈধ সার্টিফিকেট বা ভুল প্রোফাইল একটি সঠিক কন্ট্রোলার কনফিগারেশনকে ব্যর্থ করবে, তাই হাত দিয়ে ইনস্টল করার বদলে MDM-এর মাধ্যমে প্রোফাইল পুশ করুন।
আপনার ডিজাইনে যদি EAP পদ্ধতি বা এমন স্কেলের প্রয়োজন হয় যা একটি অন-প্রিমিসেস এজেন্ট সঠিকভাবে পরিচালনা করতে পারে না, তবে একাধিক সাইট জুড়ে এজেন্ট সার্ভার বৃদ্ধি করার আগে একটি ম্যানmanaged RADIUS-as-a-Service স্তরের সাথে সেই সীমাবদ্ধতা তুলনা করুন। আপনি যাই পছন্দ করুন না কেন, একটি পৃথক ইমার্জেন্সি অ্যাডমিনিস্ট্রেটর পথ রাখুন যা এজেন্ট, Okta API, বা MFA পরিষেবার ওপর নির্ভর করে না। প্রথম সার্টিফিকেট বা WAN ঘটনার সময় আপনার এটির প্রয়োজন হবে, তার পরে নয়।
একটি ল্যাপটপ একবার কানেক্ট হয়েছে বলেই কোনো কনফিগারেশন চালু করবেন না। এটি তখনই চালু করুন যখন গ্রহণ, প্রত্যাখ্যান, গ্রুপ রিমুভাল, টাইমআউট এবং এজেন্ট রিস্টার্ট সবই আপনার ডকুমেন্ট করা উপায়ে আচরণ করে।
কন্ডিশনাল অ্যাক্সেস এবং ডিভাইস পোস্টার নিয়ম সেট করুন
প্রতিটি নিয়ন্ত্রণকে এমন স্তরে রাখুন যা এটি কার্যকর করতে পারে। Okta নির্ধারণ করে ব্যবহারকারী কে, তারা কোন গ্রুপের অন্তর্ভুক্ত এবং কোন ফ্যাক্টর পলিসি প্রযোজ্য। MDM নির্ধারণ করে ডিভাইসটি এনরোল করা এবং কমপ্লায়েন্ট কিনা এবং এর সার্টিফিকেট ও WiFi প্রোফাইল প্রদান করে। RADIUS এজেন্ট বা কন্ট্রোলার সেই ইনপুটগুলোকে Access-Accept বা Access-Reject-এ রূপান্তর করে এবং প্রাপ্ত VLAN বা রোল প্রয়োগ করে।
RADIUS অ্যাপ্লিকেশনে গ্রুপ অ্যাসাইনমেন্ট নির্ধারণ করে কে আদৌ SSID-এ যোগ দিতে পারবে। সেই অ্যাপ্লিকেশনের ফ্যাক্টর পলিসি নির্ধারণ করে MFA প্রয়োজন কিনা, তবে কন্ট্রোলার এবং সাপ্লিক্যান্টকে এখনও চ্যালেঞ্জটি বহন করতে হয়। ডিভাইসের অবস্থা কোনো পাসওয়ার্ড থেকে আসে না। এটি আসে MDM এনরোলমেন্ট এবং একটি বৈধ সার্টিফিকেটের উপস্থিতি থেকে, তাই একটি আনম্যানেজড ব্যক্তিগত ডিভাইস কেবল তার মালিকের কাছে বৈধ ক্রেডেনশিয়াল থাকার কারণে স্টাফ নেটওয়ার্কে যুক্ত হওয়া উচিত নয়।
ডিরেক্টরি গ্রুপ মেম্বারশিপ গ্রহণের পরেও প্লেসমেন্ট পরিচালনা করতে পারে। প্রতিটি গ্রুপকে একটি VLAN বা রোলের সাথে ম্যাপ করুন, Access-Accept-এ সেই অ্যাট্রিবিউটটি ফেরত দিন এবং ম্যাপিংটিকে নিরীক্ষা করার মতো যথেষ্ট ছোট রাখুন। উৎস সীমাবদ্ধতা Okta নেটওয়ার্ক জোনে এবং এজেন্টের ওপর থাকা উচিত। কেবল কন্ট্রোলার অ্যাড্রেসগুলি বৈধ RADIUS উৎস হওয়া উচিত। বিস্তৃত নেটওয়ার্ক অ্যাক্সেস সিদ্ধান্তগুলি আপনার সামগ্রিক নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল সলিউশনগুলির সাথে সামঞ্জস্যপূর্ণ হওয়া উচিত, নির্দিষ্ট SSID সংক্রান্ত ব্যতিক্রমের সেট হওয়া উচিত নয়।
রোলআউটের আগে তিনটি পরীক্ষা চালান
- রিভোকেশন টেস্ট: এটি বরাদ্দ করা গ্রুপ থেকে একটি আসল টেস্ট অ্যাকাউন্ট সরিয়ে দিন এবং পরবর্তী সংযোগটি প্রত্যাখ্যাত হয়েছে কিনা তা নিশ্চিত করুন। তারপর অ্যাকাউন্টটি নিষ্ক্রিয় করুন এবং এটি পুনরাবৃত্তি করুন।
- পোস্টার টেস্ট: একটি এনরোল করা কমপ্লায়েন্ট ডিভাইস, একটি এনরোল করা নন-কমপ্লায়েন্ট ডিভাইস এবং একটি এনরোল না থাকা ডিভাইস দিয়ে চেষ্টা করুন। কেবল প্রথমটি স্টাফ VLAN-এ পৌঁছায় কিনা তা নিশ্চিত করুন।
- অডিট ডকুমেন্ট: আপনার হেল্প ডেস্ক পড়তে পারে এমন একটি ডকুমেন্টে প্রতিটি গ্রুপ থেকে VLAN ম্যাপিং, প্রতিটি গ্রুপের মালিক এবং পৃথক গেস্ট রুল সেট রেকর্ড করুন।
আইডেন্টিটি, এন্ডপয়েন্ট এবং নেটওয়ার্ক ডিভাইসের ক্ষেত্রে এই সীমানাগুলি জোরদার করা টিমগুলি আরও বিস্তর তথ্যের জন্য IT protection from Wisely দরকারী বলে মনে করতে পারেন। এই রোলআউটের জন্য, পরীক্ষাটি সীমিত রাখুন। ল্যাবে কোনো কন্ট্রোল যদি কোনো গ্রহণ, প্রত্যাখ্যান বা VLAN পরিবর্তন করে দেখাতে না পারে, তবে সেটি এখনও কনফিগার করা হয়নি।
ব্যর্থ হওয়া Okta Wi-Fi লগইনগুলোর ট্রাবলশুটিং
ব্যবহারকারীরা যে উপসর্গের কথা সবচেয়ে বেশি জানান সেখান থেকে শুরু করুন। যে ক্লায়েন্ট কখনও ক্রেডেনশিয়াল প্রম্পট দেখায় না সে সাধারণত Okta-র জন্য অপেক্ষা করছে না। এটি হয় তার 802.1X প্রোফাইল মিস করছে, ভুল EAP পদ্ধতি অফার করছে, অথবা ক্রেডেনশিয়াল পাঠানোর আগেই সার্ভার সার্টিফিকেট প্রত্যাখ্যান করছে। কারও পাসওয়ার্ড রিসেট করার আগে ডিভাইস প্রোফাইল এবং কন্ট্রোলার EAP সেট্যাংস পরীক্ষা করুন।
একবারে একটি লেয়ারে কাজ করুন। এজেন্ট সার্ভিস চালু আছে কিনা তা নিশ্চিত করুন, কন্ট্রোলার রিজেক্ট রিজন পড়ুন, তারপর একটি সেটিং পরিবর্তন করুন এবং একই ডিভাইস ও অ্যাকাউন্ট দিয়ে পুনরায় পরীক্ষা করুন। আপনি যদি সিক্রেট, প্রোফাইল, গ্রুপ এবং সার্টিফিকেট একসাথে এডিট করেন, তবে আপনি পরবর্তী সাইটে কোন ত্রুটিটি ফেরত আসবে তা না জেনেই লগইন ঠিক করে ফেলবেন।
প্রথম সমাধানের সাথে লক্ষণ মেলান
| উপসর্গ | সম্ভাব্য কারণ | প্রথম সমাধান |
|---|---|---|
| ক্লায়েন্ট কখনও শংসাপত্রের প্রম্পট দেখায় না | 802.1X প্রোফাইল অনুপস্থিত বা EAP ধরনের অমিল রয়েছে | প্রোফাইলটি পুনরায় স্থাপন করুন এবং কন্ট্রোলারের সাথে EAP মেথড মিলান |
| অনুমোদন টাইম আউট হয়েছে | UDP 1812 ব্লক করা হয়েছে বা এজেন্ট সার্ভিস ডাউন আছে | ফায়ারওয়াল পাথ এবং কন্ট্রোলার নেটওয়ার্ক থেকে এজেন্ট সার্ভিসের স্ট্যাটাস পরীক্ষা করুন |
| সঠিক পাসওয়ার্ড দেওয়া সত্ত্বেও Access-Reject দেখাচ্ছে | শেয়ার্ড সিক্রেট অমিল বা ব্যবহারকারী নির্ধারিত গ্রুপের বাইরে আছেন | উভয় প্রান্তে সিক্রেট পুনরায় লিখুন এবং গ্রুপ অ্যাসাইনমেন্ট নিশ্চিত করুন |
| কেবল একটি কন্ট্রোলার থেকে রিজেক্ট হচ্ছে | সোর্স IP বা নেটওয়ার্ক জোন সেই কন্ট্রোলারকে বাদ দেয় | অনুমোদিত জোনের সাথে কন্ট্রোলার অ্যাড্রেস তুলনা করুন |
| MFA প্রম্পট কখনও দেখা যাচ্ছে না | ক্লায়েন্ট বা কন্ট্রোলার চ্যালেঞ্জ প্রদর্শন করতে পারছে না | অন্য একটি ক্লায়েন্ট টেস্ট করুন এবং ল্যাবে চ্যালেঞ্জ পাথ নিশ্চিত করুন |
| Windows এ কাজ করে, কিন্তু iOS এ ব্যর্থ হয় | সার্টিফিকেট ট্রাস্ট বা প্রোফাইল অমিল | ব্যর্থ হওয়া OS-এ সার্ভার সার্টিফিকেট চেইন এবং প্রোফাইল ট্রাস্ট সেটিংস পরীক্ষা করুন |
| একটি নির্দিষ্ট তারিখের পর কার্যকরী সাইটটি ব্যর্থ হয় | সার্ভার সার্টিফিকেটের মেয়াদ শেষ হয়ে গেছে | সার্টিফিকেট রিনিউ করুন এবং আপডেট করা ট্রাস্ট প্রোফাইল পুশ করুন |
মিনিটের মধ্যে হওয়া সমাধানগুলিকে পুরো বহরের সমাধানগুলি থেকে আলাদা করুন। একটি শেয়ার্ড সিক্রেট পুনরায় প্রবেশ করানো, একটি গ্রুপ সংশোধন করা, একটি কন্ট্রোলার সোর্স অ্যাড্রেস যোগ করা, বা এজেন্ট পুনরায় চালু করা দ্রুত একটি ল্যাব ত্রুটি দূর করতে পারে। একটি সার্ভার সার্টিফিকেট নবায়ন করা, একটি ট্রাস্ট প্রোফাইল পুনরায় তৈরি করা এবং হাজার হাজার ডিভাইসের MDM-এ চেক ইন করার জন্য অপেক্ষা করা কয়েক দিন সময় নিতে পারে। একটি ট্রাস্ট চেইন সমস্যার জন্য একই দিনে সাইট রিকভারির প্রতিশ্রুতি দেবেন না।
ধরুন একটি নির্দিষ্ট বিল্ডিংয়ে সার্টিফিকেট পরিবর্তনের পর Windows ল্যাপটপগুলি পুনরায় কানেক্ট করতে পারছে কিন্তু iPhone গুলি ব্যর্থ হচ্ছে। এই প্যাটার্নটি Okta পলিসির সমস্যা নয় বলে নির্দেশ করে, কারণ একই অ্যাকাউন্ট দিয়ে অন্যত্র সফলভাবে লগইন করা যাচ্ছে। একটি সচল Windows ডিভাইসের সাথে iOS প্রোফাইলের বিশ্বস্ত CA, প্রত্যাশিত সার্ভারের নাম এবং সার্টিফিকেট চেইন তুলনা করুন। হতে পারে একটি OS নতুন ট্রাস্ট ক্যাশ করেছে বা গ্রহণ করেছে যেখানে অন্যটি তা করেনি।
প্রমাণ সহ বিষয়টিকে উর্ধ্বতন কর্তৃপক্ষের কাছে পাঠান। একটি টেস্ট সাইকেল যদি প্রত্যাখ্যানের কারণ পরিবর্তন না করে, তবে প্রোডাকশন সেটিংস এডিট করা বন্ধ করুন, ব্যর্থ ডিভাইসটিকে ল্যাব SSID-তে ফেরত আনুন এবং একটি সচল ডিভাইসের সাথে এর অ্যাসোসিয়েশন, EAP এক্সচেঞ্জ, RADIUS ফলাফল এবং অ্যাসাইন করা VLAN তুলনা করুন। আপনার সাথে টাইমস্ট্যাম্পগুলি রাখুন। চারটি সিস্টেম জুড়ে অনুমানের ওপর কাজ করলে চেঞ্জ উইন্ডো নষ্ট হবে।
সাইটগুলি সম্প্রসারণ করার আগে পাইলট নিশ্চিত করুন
একটি সফল Okta লগইন মানেই একটি কার্যকর WiFi সেশন নয়। পাইলটকে অ্যাসোসিয়েশন থেকে শুরু করে ব্যবহারের যোগ্য নেটওয়ার্ক অ্যাক্সেস পর্যন্ত সম্পূর্ণ ট্রানজ্যাকশন পরিমাপ করতে হবে, কারণ কোন হপ ত্রুটি ফেরত দিয়েছে তা ব্যবহারকারীরা বিবেচনা করেন না। Okta RADIUS বেস্ট প্র্যাকটিস ফ্লো সর্বোচ্চ এগারোটি লজিক্যাল ধাপ সম্বলিত একটি চ্যালেঞ্জ ফ্লো বর্ণনা করে, যার মধ্যে রয়েছে শংসাপত্র ফরোয়ার্ডিং, API ভ্যালিডেশন, MFA চ্যালেঞ্জ প্রেজেন্টেশন, চ্যালেঞ্জ রেসপন্স, দ্বিতীয় ভ্যালিডেশন এবং চূড়ান্ত RADIUS সিদ্ধান্ত। সেই অনুযায়ী চেইনটিকে ইন্সট্রুমেন্ট করুন।
প্রতিটি পাইলট ডিভাইসের জন্য চারটি চেকপয়েন্ট ব্যবহার করুন। প্রথমত, অ্যাসেস পয়েন্টে অ্যাসোসিয়েশন এবং 802.1X/EAP নেগোশিয়েশন। দ্বিতীয়ত, এজেন্টে RADIUS রিকোয়েস্ট রিসিভ। তৃতীয়ত, Okta পলিসি এবং ফ্যাক্টর রেসপন্স। চতুর্থত, কন্ট্রোলারে চূড়ান্ত Access-Accept বা Access-Reject, এবং তার পরে সঠিক VLAN। প্রথম প্রচেষ্টার সাফল্য, মধ্যমা এবং ৯৫তম পার্সেন্টাইল অথেন্টিকেশন ল্যাটেন্সি, টাইমআউট রেট, বারবার প্রম্পট আসা এবং প্রত্যাখ্যানের কারণগুলি ডিভাইস OS, সাইট, SSID, কন্ট্রোলার মডেল এবং ফ্যাক্টরের ধরন অনুযায়ী আলাদা করুন।
Okta সার্বজনীন WiFi অথেন্টিকেশন সাফল্যের কোনো বেঞ্চমার্ক প্রকাশ করে না, তাই একটি স্থানীয় গ্রহণের নিয়ম সেট করুন এবং তা রক্ষা করুন। উদাহরণস্বরূপ, নিয়ন্ত্রিত পাইলটে অন্তত ৯৯% প্রথম-প্রচেষ্টায় সমাপ্তি, কোনো ব্যাখ্যাতীত প্রত্যাখ্যান না থাকা, এবং আপনার রোমিং বাজেটের বাইরে কোনো অথেন্টিকেশন টাইমআউট না থাকা প্রয়োজন। এগুলিকে আপনার নিজস্ব পাইলট থ্রেশহোল্ড হিসাবে বিবেচনা করুন, তারপর পিক কানকারেন্সি এবং একটি WAN ব্যর্থতা পরীক্ষার অধীনে সেগুলি যাচাই করুন। একটি লগইন যা দুপুরে পাঁচটি ল্যাব ইউজারের জন্য কাজ করে তা শিফট শুরু হওয়ার সময় এবং শত শত ডিভাইস একসাথে পুনরায় কানেক্ট হলে ব্যর্থ হতে পারে।
আপনার প্রমাণের সমস্ত এস্টেট জুড়ে কোয়েরি করার যোগ্য হওয়া প্রয়োজন। Purple Access একটি অথেন্টিকেশন লগ প্রদান করে যা প্রতিটি গ্রহণ এবং প্রত্যাখ্যান প্রদর্শন করে, যেখানে পরিচয়, ডিভাইস, MDM এনরোলমেন্ট স্ট্যাটাস, পদ্ধতি, অ্যাক্সেস পয়েন্ট, SSID, সাইট, VLAN, ভূমিকা, কারণ এবং টাইমস্ট্যাম্প অন্তর্ভুক্ত থাকে, একটি একক এস্টেট-ব্যাপী কোয়েরিতে। এই স্তরের বিশদ বিভাজন প্রমাণের জন্যও গুরুত্বপূর্ণ, বিশেষ করে কারণ PCI-DSS v4.0.1 Req 2.3.2-এর জন্য ওয়্যারলেস কীগুলি পরিবর্তন করা প্রয়োজন যখন সেগুলি জানা যে কেউ চলে যায়, যা একটি শেয়ার্ড কী এর মাধ্যমে করা অবাস্তব। অন্তর্নিহিত WiFi নেটওয়ার্ক ডিজাইন নজরে রাখুন, কারণ অথেন্টিকেশন দুর্বল VLAN সীমানাকে রক্ষা করতে পারে না।
কেবল একটি স্পষ্ট অগ্রসর হওয়ার সিদ্ধান্তের ওপর নির্ভর করে বিস্তার করুন। স্কোপের মধ্যে থাকা প্রতিটি OS এবং ফ্যাক্টরের ধরন তিনটি গ্রহণযোগ্যতার শর্তই পূরণ করে, প্রত্যাখ্যানের নির্দিষ্ট কারণ উল্লেখ রয়েছে, এবং এজেন্ট বন্ধ রেখে জরুরি অ্যাডমিনিস্ট্রেটর পাথ পরীক্ষা করা হয়েছে। যেকোনো শর্ত ব্যর্থ হলে, পাইলট পর্যায়ে থাকুন এবং সেই স্তরটি ঠিক করুন। নতুন সাইট যুক্ত করলে একটি সমাধান না হওয়া ত্রুটি আরও বেড়ে যায়।
আপনার Okta WiFi প্রামাণীকরণ ডিজাইন যদি শেয়ার করা পাসওয়ার্ড, দুর্বল এজেন্ট সার্ভার, বা ম্যানুয়াল সার্টিফিকেটের কাজকে পেছনে ফেলে এগিয়ে যেতে চায়, তবে Purple Access আপনার ইতিপূর্বে থাকা অ্যাক্সেস পয়েন্টগুলো ব্যবহার করেই গেস্ট, স্টাফ এবং ডিভাইসগুলোকে পৃথক আইডেন্টিটি-ড্রিভেন নেটওয়ার্কে যুক্ত করতে পারে। আপনার কন্ট্রোলার মডেল, MDM, এবং গ্রুপ থেকে VLAN প্ল্যান নিয়ে আসুন, এবং আমরা এটি একটি প্রোডাকশন সাইটে পৌঁছানোর আগে ল্যাব-ফার্স্ট রোলআউট যাচাই করতে সাহায্য করব।
