WiFi-এর জন্য Microsoft Cloud PKI: Intune এবং Entra ID সহ EAP-TLS সার্টিফিকেট ডিপ্লয়মেন্ট

হ্যাঁ। Microsoft Cloud PKI, Intune Suite-এর হোস্ট করা সার্টিফিকেট অথরিটি, Intune-দ্বারা পরিচালিত ডিভাইসগুলোতে EAP-TLS WiFi সার্টিফিকেট ইস্যু করে। একটি SCEP সার্টিফিকেট প্রোফাইল সরাসরি সেগুলোর অনুরোধ জানায়, তাই আপনার কোনো NDES সার্ভার, সার্টিফিকেট কানেক্টর বা অন-প্রেমিসেস CA-এর প্রয়োজন নেই। আপনার RADIUS সার্ভার ইম্পোর্ট করা Cloud PKI রুটকে ট্রাস্ট করে এবং পরিষেবাটির প্রকাশ করা CRL-এর বিরুদ্ধে প্রতিটি সার্টিফিকেট পরীক্ষা করে।

WiFi অথেন্টিকেশনের জন্য Microsoft Cloud PKI কী কাজ করে?

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) হলো এমন একটি 802.1X পদ্ধতি যেখানে উভয় পক্ষই সার্টিফিকেটের মাধ্যমে তাদের পরিচয় প্রমাণ করে। IEEE 802.1X হলো পোর্ট-ভিত্তিক অ্যাক্সেস কন্ট্রোল স্ট্যান্ডার্ড যা WPA2-Enterprise এবং WPA3-Enterprise-এর পেছনে কাজ করে। অ্যাক্সেস পয়েন্ট প্রতিটি সংযোগের চেষ্টা একটি RADIUS সার্ভারে পাঠিয়ে দেয়, যা ডিভাইসটিকে গ্রহণ বা প্রত্যাখ্যান করার অথেন্টিকেশন সার্ভার হিসেবে কাজ করে। EAP-TLS-এর ক্ষেত্রে ফিশিং করার মতো কোনো পাসওয়ার্ড নেই এবং লিক হওয়ার মতো কোনো শেয়ার্ড কি নেই। প্রতিটি ডিভাইসের নিজস্ব প্রাইভেট কি এবং সার্টিফিকেট থাকে।

এর পেছনের সবচেয়ে কঠিন অংশটি সব সময় ছিল PKI (পাবলিক কি ইনফ্রাস্ট্রাকচার)। Intune-দ্বারা পরিচালিত ডিভাইসে সার্টিফিকেট পেতে ঐতিহ্যগতভাবে চারটি জিনিসের প্রয়োজন হতো:

• একটি Active Directory Certificate Services (AD CS) ইস্যুয়িং CA
• একটি NDES (Network Device Enrollment Service) সার্ভার
• Intune Certificate Connector
• ইন্টারনেটে NDES প্রকাশ করার জন্য একটি রিভার্স প্রক্সি বা Microsoft Entra অ্যাপ্লিকেশন প্রক্সি

প্রতিটি উপাদানের জন্য প্যাচিং, ব্যাকআপ এবং মনিটরিংয়ের প্রয়োজন হয়।

Microsoft Cloud PKI আপনার Intune টেন্যান্টে হোস্ট করা একটি সার্টিফিকেট অথরিটি দিয়ে সেই স্ট্যাকটিকে প্রতিস্থাপিত করে। ডিভাইসগুলো SCEP (Simple Certificate Enrollment Protocol)-এর মাধ্যমে সার্টিফিকেটের জন্য অনুরোধ করে এবং Cloud PKI নিজেই সেই অনুরোধগুলোর জবাব দেয়। এটি Intune-এর বিপরীতে প্রতিটি অনুরোধ যাচাই করে, সার্টিফিকেটে স্বাক্ষর করে এবং তা ফেরত পাঠায়। ডিভাইসটি স্থানীয়ভাবে তার প্রাইভেট কি তৈরি করে এবং সেই কি কখনই এটি ছেড়ে যায় না।

Entra ID-যুক্ত ডিভাইসের জন্য, এটি সার্টিফিকেট চেইনের শেষ অন-প্রেমিসেস নির্ভরতা দূর করে। যে ডিভাইসগুলো কখনোই ডোমেইন কন্ট্রোলার দেখেনি, সেগুলোও একটি WiFi সার্টিফিকেট পেতে পারে।

Cloud PKI CA হায়ারার্কি কীভাবে কাজ করে

Cloud PKI একটি দুই-স্তরের হায়ারার্কি ব্যবহার করে। একটি রুট CA এক বা একাধিক ইস্যুয়িং CA-তে স্বাক্ষর করে এবং ইস্যুয়িং CA ডিভাইসের সার্টিফিকেটে স্বাক্ষর করে। Microsoft তাদের হার্ডওয়্যার সিকিউরিটি মডিউল (HSM)-এ CA সাইনিং কিগুলো সংরক্ষণ করে, তাই আপনাকে কখনোই কি মেটেরিয়াল পরিচালনা করতে হয় না।

আপনি দুটি অ্যাঙ্কারের যেকোনো একটি বেছে নিতে পারেন:

• Cloud PKI রুট। Microsoft আপনার টেন্যান্টে রুট এবং ইস্যুয়িং CA উভয়ই হোস্ট করে। এটি একটি নতুন Entra ID পরিবেশের জন্য সবচেয়ে সহজ বিকল্প।
• Bring your own CA (BYOCA)। আপনি একটি Cloud PKI ইস্যুয়িং CA তৈরি করেন, এর সার্টিফিকেট সাইনিং রিকোয়েস্ট ডাউনলোড করেন এবং আপনার বিদ্যমান প্রাইভেট রুট (যেমন একটি AD CS রুট) দিয়ে এতে স্বাক্ষর করেন। যা কিছু ইতিমধ্যেই সেই রুটকে ট্রাস্ট করে, তা নতুন ইস্যুয়িং CA-এর চেইনকেও ট্রাস্ট করে।

আপনি প্রতিটি CA তৈরি করার সময় এক্সটেন্ডেড কী ইউসেজ (EKUs) সেট করেন। WiFi ক্লায়েন্ট সার্টিফিকেটের জন্য Client Authentication EKU প্রয়োজন, তাই উভয় স্তরেই এটি অন্তর্ভুক্ত করুন। এটি সাবধানে পরিকল্পনা করুন, কারণ CA তৈরি হয়ে গেলে EKUs স্থির হয়ে যায়।

ডিজাইনের জন্য একটি সীমানা গুরুত্বপূর্ণ। Cloud PKI SCEP-এর মাধ্যমে Intune-পরিচালিত ডিভাইসগুলিতে সার্টিফিকেট ইস্যু করে। এটি আপনার RADIUS সার্ভারের নিজস্ব সার্টিফিকেট ইস্যু করার জন্য তৈরি করা হয়নি, তাই সেই সার্টিফিকেটটি সাধারণত একটি পাবলিক CA বা আপনার বিদ্যমান PKI থেকে আসে।

NDES এবং PKCS সহ SCEP-এর সাথে Cloud PKI-এর তুলনা

	Cloud PKI (SCEP)	NDES সহ SCEP	PKCS
CA হোস্টিং	আপনার Intune টেন্যান্টে Microsoft-হোস্টেড	আপনার AD CS বা তৃতীয় পক্ষের CA	আপনার AD CS বা তৃতীয় পক্ষের CA
অন-প্রিমিসেস সার্ভার	নেই	ইস্যুয়িং CA, NDES সার্ভার, কানেক্টর হোস্ট	ইস্যুয়িং CA, কানেক্টর হোস্ট
ইন্টারনেটে প্রকাশিত উপাদান	নেই	রিভার্স প্রক্সি বা অ্যাপ্লিকেশন প্রক্সির মাধ্যমে NDES	নেই
প্রাইভেট কী কোথায় তৈরি হয়	ডিভাইসে	ডিভাইসে	CA এর দিকে, PFX হিসেবে ডিভাইসে পৌঁছে দেওয়া হয়
শুধুমাত্র Entra ID ফ্লিটের জন্য উপযুক্ততা	নেটিভ	কাজ করে, কিন্তু অন-প্রিমিসেস নির্ভরতা বজায় রাখে	কাজ করে, কিন্তু অন-প্রিমিসেস নির্ভরতা বজায় রাখে
রিভোকেশন	Intune অ্যাডমিন সেন্টারে রিভোক করুন, CRL দ্বারা প্রকাশিত	কানেক্টর এবং আপনার CA-এর CRL-এর মাধ্যমে	কানেক্টর এবং আপনার CA-এর CRL-এর মাধ্যমে
লাইসেন্স মডেল	Intune Suite বা Cloud PKI অ্যাড-অন, আসন প্রতি	Windows Server লাইসেন্স এবং Intune	Windows Server লাইসেন্স এবং Intune
যাদের জন্য উপযুক্ত	ক্লাউড-ফার্স্ট এস্টেট যা অন-প্রিমিসেস PKI অবসর দিচ্ছে	একটি পরিপক্ক AD CS দল এবং দীর্ঘ CA রোডম্যাপ সহ এস্টেট	যেসব ক্ষেত্রে একাধিক প্ল্যাটফর্মে একই কী প্রয়োজন, যেমন S/MIME

SCEP এবং PKCS-এর সাথে Intune সার্টিফিকেট ডিপ্লয়মেন্ট সম্পর্কিত আমাদের পৃথক গাইডটিতে অন-প্রিমিসেস পথ দুটি বিস্তারিতভাবে তুলে ধরা হয়েছে।

EAP-TLS-এর জন্য Cloud PKI ডিপ্লয় করার আগে আপনার কী প্রয়োজন?

যেকোনো কিছু তৈরি করার আগে এই ছয়টি বিষয় পরীক্ষা করে নিন। এর প্রতিটি নিচের ট্রাবলশুটিং সেকশনের একটি ব্যর্থতার সাথে সম্পর্কিত।

• লাইসেন্সিং। একটি Intune Plan 1 সাবস্ক্রিপশনের সাথে Microsoft Intune Suite অথবা স্ট্যান্ডঅ্যালোন Cloud PKI অ্যাড-অন।
• পারমিশন। Intune Administrator রোল, অথবা Cloud PKI পারমিশন সহ একটি কাস্টম রোল।
• এনরোল করা ডিভাইস। Intune-এ এনরোল করা Windows, macOS, iOS/iPadOS বা Android ডিভাইস, যা Microsoft Entra ID সিকিউরিটি গ্রুপে গ্রুপ করা হয়েছে।
• একটি EAP-TLS-সক্ষম RADIUS সার্ভার। এটি আপনাকে CA সার্টিফিকেট ইমপোর্ট করতে, HTTP-এর মাধ্যমে Cloud PKI CRL-এ পৌঁছাতে এবং Entra ID অবজেক্টে সার্টিফিকেট আইডেন্টিটি ম্যাপ করতে দেবে। Microsoft NPS (Network Policy Server) অন-প্রিমিসেস Active Directory-তে অ্যাকাউন্ট খোঁজে, তাই শুধুমাত্র ক্লাউড ভিত্তিক ডিভাইসগুলো সেখানে ব্যর্থ হয়।
• একটি RADIUS সার্ভার সার্টিফিকেট। এটি ইস্যু করা রুট এবং যেকোনো ইন্টারমিডিয়েট সার্টিফিকেটেরও আপনার প্রয়োজন হবে, কারণ ডিভাইসগুলোকে সার্ভারটি ভ্যালিডেট করতে হবে।
• 802.1X-সক্ষম অ্যাক্সেস পয়েন্ট। এগুলিকে অবশ্যই আপনার RADIUS সার্ভারের দিকে নির্দেশিত একটি WPA2-Enterprise বা WPA3-Enterprise SSID ব্রডকাস্ট করতে হবে।

অ্যাক্সেস পয়েন্টের দিক থেকে, প্রতিটি প্রধান প্ল্যাটফর্ম 802.1X সমর্থন করে। এর মধ্যে রয়েছে Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet। বিক্রেতা-নির্দিষ্ট বিস্তারিত নির্দেশিকার জন্য, Configuring 802.1X on Juniper Mist with cloud RADIUS দেখুন।

কীভাবে আপনি WiFi এর জন্য Cloud PKI সার্টিফিকেট সেট আপ করবেন?

নিচের ধাপগুলো মূল প্রক্রিয়াটিকে সংক্ষেপে প্রকাশ করে। বর্তমান স্ক্রীন এবং ক্ষেত্র-ভিত্তিক ধাপগুলোর জন্য Microsoft Learn-এ থাকা Microsoft এর Cloud PKI ডকুমেন্টেশন ব্যবহার করুন, কারণ সংস্করণভেদে অ্যাডমিন সেন্টারের লেআউট পরিবর্তিত হয়।

ধাপ ১: root CA তৈরি করুন, অথবা আপনার নিজস্ব আনুন

Intune অ্যাডমিন সেন্টারে, টেন্যান্ট অ্যাডমিনিস্ট্রেশনের অধীনে একটি root CA তৈরি করুন। Client Authentication সহ কী (key) এর আকার, বৈধতার মেয়াদ এবং EKU নির্বাচন করুন।

BYOCA এর জন্য, root ধাপটি এড়িয়ে যান। একটি BYOCA টাইপ হিসেবে issuing CA তৈরি করুন এবং এর সার্টিফিকেট সাইনিং রিকোয়েস্ট এক্সপোর্ট করুন। Client Authentication অন্তর্ভুক্ত রয়েছে এমন একটি টেমপ্লেট ব্যবহার করে আপনার প্রাইভেট CA-তে রিকোয়েস্টটি সই করুন, তারপর সাইন করা সার্টিফিকেট এবং এর চেইন আপলোড করুন।

ধাপ ২: issuing CA তৈরি করুন

ধাপ ১ এর root-এর সাথে সংযুক্ত একটি issuing CA তৈরি করুন। এর EKU-তে অবশ্যই Client Authentication অন্তর্ভুক্ত থাকতে হবে। তৈরি হয়ে গেলে, এর প্রোপার্টি পেজ তিনটি জিনিস দেখাবে যা আপনার পরবর্তীতে প্রয়োজন হবে:

• SCEP URI
• CA সার্টিফিকেট ডাউনলোড
• CRL ডিস্ট্রিবিউশন পয়েন্ট

ধাপ ৩: ট্রাস্টেড সার্টিফিকেট প্রোফাইল ডেপ্লয় করুন

root এবং issuing CA সার্টিফিকেট ডাউনলোড করুন। প্রতিটি প্ল্যাটফর্মের জন্য একটি করে ট্রাস্টেড সার্টিফিকেট প্রোফাইল তৈরি করুন। যে গ্রুপগুলো SCEP এবং WiFi প্রোফাইল পাবে, এগুলোকেও সেই একই গ্রুপে অ্যাসাইন করুন।

SCEP প্রোফাইল সফল হওয়ার আগে ডিভাইসগুলোর এই চেইন প্রয়োজন। আপনার RADIUS সার্ভার সার্টিফিকেট ইস্যুকারী CA-এর জন্য আরও একটি ট্রাস্টেড সার্টিফিকেট প্রোফাইল তৈরি করুন, যদি ডিভাইসগুলো ইতোমধ্যে এটিকে ট্রাস্ট না করে থাকে।

ধাপ ৪: SCEP সার্টিফিকেট প্রোফাইল তৈরি করুন

প্রতিটি প্ল্যাটফর্মের জন্য একটি SCEP সার্টিফিকেট প্রোফাইল তৈরি করুন এবং এটি Cloud PKI-এর দিকে পয়েন্ট করুন। মূল সিদ্ধান্তগুলো হলো:

• SCEP server URL. issuing CA থেকে পাওয়া SCEP URI যেভাবে দেখানো হয়েছে ঠিক সেভাবে পেস্ট করুন। এর প্লেসহোল্ডার টেক্সট সম্পাদনা না করে রেখে দিন, কারণ Intune ইস্যু করার সময় এটি সমাধান করে।
• Root certificate. issuing CA নয়, বরং Cloud PKI root-এর জন্য ট্রাস্টেড সার্টিফিকেট প্রোফাইলটি নির্বাচন করুন।
• Certificate type. ফ্রন্ট-ডেস্ক ট্যাবলেট বা স্টোর হ্যান্ডহেল্ডের মতো শেয়ার করা ডিভাইসগুলোর জন্য ডিভাইস সার্টিফিকেট বেছে নিন। যেখানে কর্মীরা তাদের নিজস্ব ল্যাপটপ বহন করে এবং আপনি নীতিটিকে ব্যক্তির সাথে সংযুক্ত করতে চান, সেখানে ব্যক্তি-ভিত্তিক সার্টিফিকেট বেছে নিন।
• Subject and subject alternative name (SAN). আপনার RADIUS সার্ভার Entra ID-তে ম্যাপ করতে পারে এমন একটি আইডেন্টিফায়ার অন্তর্ভুক্ত করুন। উদাহরণস্বরূপ Entra ডিভাইস আইডি ভেরিয়েবল {{AAD_Device_ID}} বা UPN ভেরিয়েবল {{UserPrincipalName}}।
• Key usage and EKU. Client Authentication সহ ডিজিটাল সিগনেচার এবং কী এনসাইফারমেন্ট সেট করুন।
• Windows-এ Key storage. TPM (Trusted Platform Module) কী স্টোরেজ প্রোভাইডারে এনরোল করুন, যাতে প্রাইভেট কী-টি হার্ডওয়্যার-বাউন্ড হয় এবং এক্সপোর্ট করা না যায়।
• নবায়নের থ্রেশহোল্ড। অবশিষ্ট জীবনকালের শতাংশ সেট করুন যেখানে Intune নবায়ন করে, যাতে শংসাপত্রগুলি অলক্ষে শেষ না হয়ে যায়।

ধাপ 5: RADIUS সার্ভারকে Cloud PKI ট্রাস্ট করান

Cloud PKI রুট এবং ইস্যুকারী CA শংসাপত্র উভয়ই আপনার RADIUS সার্ভারের ট্রাস্টেড CA স্টোরে ইম্পোর্ট করুন। শুধুমাত্র রুট ইম্পোর্ট করা হল "অজানা CA" প্রত্যাখ্যানের সবচেয়ে সাধারণ কারণ।

CRL চেকিং সক্ষম করুন, এবং RADIUS সার্ভারকে প্রতিটি শংসাপত্রে তালিকাভুক্ত CRL ডিস্ট্রিবিউশন পয়েন্টে আউটবাউন্ড HTTP অ্যাক্সেসের অনুমতি দিন। BYOCA-এর সাথে, RADIUS সার্ভার ইতিমধ্যেই আপনার রুটকে ট্রাস্ট করতে পারে, তাই আপনি কেবল নতুন ইস্যুকারী CA শংসাপত্র যোগ করবেন।

যদি Purple-এর ক্লাউড RADIUS আপনার কর্মীদের WiFi প্রমাণীকরণ করে, তবে আপনার Purple অ্যাকাউন্ট টিম নিশ্চিত করবে যে কীভাবে আপনার টেন্যান্টের জন্য Cloud PKI চেইন লোড করা হয়েছে।

ধাপ 6: WiFi প্রোফাইল তৈরি করুন

Enterprise সিকিউরিটি এবং EAP টাইপ হিসাবে EAP-TLS সহ একটি Intune WiFi প্রোফাইল তৈরি করুন। তিনটি ফিল্ড সেট করুন:

• ক্লায়েন্ট প্রমানীকরণ শংসাপত্র। ধাপ 4 থেকে SCEP প্রোফাইলটি নির্বাচন করুন।
• সার্ভার ভ্যালিডেশনের জন্য রুট শংসাপত্র। আপনার RADIUS সার্ভারের ইস্যুইং রুটের জন্য ট্রাস্টেড শংসাপত্র প্রোফাইলটি নির্বাচন করুন।
• সার্টিফিকেট সার্ভারের নাম। RADIUS সার্ভার শংসাপত্রের সাথে হুবহু মেলে এমন নামগুলি লিখুন।

SCEP এবং ট্রাস্টেড শংসাপত্র প্রোফাইলের মতো একই গ্রুপে প্রোফাইলটি অ্যাসাইন করুন।

Cloud PKI এর মাধ্যমে কীভাবে রেভোকেশন কাজ করে?

আপনি Intune অ্যাডমিন সেন্টারের ইস্যুকারী CA থেকে Cloud PKI শংসাপত্র বাতিল (revoke) করেন। ইস্যু করা শংসাপত্রের তালিকাটি খুলুন, ডিভাইসের শংসাপত্রটি নির্বাচন করুন এবং এটি বাতিল করুন। Cloud PKI তখন তার CRL (সার্টিফিকেট রেভোকেশন লিস্ট)-এ পরিবর্তনটি প্রকাশ করে, যা এটি দ্বারা ইস্যু করা প্রতিটি শংসাপত্রে এমবেড করা HTTP ডিস্ট্রিবিউশন পয়েন্টে থাকে।

আপনার RADIUS সার্ভার রেভোকেশন প্রয়োগ করে, Intune নয়। এটি CRL ডাউনলোড করে এবং এমন যেকোনো শংসাপত্র প্রত্যাখ্যান করে যার সিরিয়াল নম্বর এতে দেখা যায়।

বেশিরভাগ RADIUS সার্ভার পরবর্তী আপডেটের সময় না হওয়া পর্যন্ত একটি CRL ক্যাশে রাখে। তাই একটি বাতিল করা ডিভাইস RADIUS সার্ভার একটি নতুন তালিকা না আনা পর্যন্ত সংযোগ বজায় রাখতে পারে। তিনটি উপায়ে সেই উইন্ডোটি বন্ধ করুন:

1. স্পষ্টভাবে বাতিল করুন। প্রোফাইল অ্যাসাইনমেন্ট সরানো বা ডিভাইস রেকর্ড মুছে ফেলার ওপর নির্ভর করবেন না। আপনার জয়েনার, মুভার, লিভার (JML) প্রক্রিয়ার অংশ হিসাবে শংসাপত্রটি নিজেই বাতিল করুন।
2. আইডেন্টিটি চেকের সাথে পেয়ার রেভোকেশন। যদি আপনার RADIUS সার্ভিস প্রতিটি প্রমানীকরণে Entra ID অ্যাকাউন্ট বা ডিভাইসের স্ট্যাটাস চেক করে, তবে অ্যাকাউন্টটি নিষ্ক্রিয় করা CRL রিফ্রেশ করার আগেই অ্যাক্সেস ব্লক করে দেয়।
3. CRL রিকভারি পর্যবেক্ষণ করুন। ব্যর্থ CRL ডাউনলোডে সতর্কতা পাঠাক। একটি বাসি CRL ধরে রাখা RADIUS সার্ভার তার ব্যর্থতার নীতির ওপর নির্ভর করে বাতিল করা ডিভাইসগুলিকে স্বীকার করতে থাকে অথবা প্রতিটি ডিভাইসকে প্রত্যাখ্যান করে।

Cloud PKI WiFi প্রমাণীকরণ কাজ করছে তা আপনি কীভাবে পরীক্ষা করবেন?

আপনার সমর্থন করা প্রতিটি প্ল্যাটফর্মজুড়ে পাঁচ থেকে 10টি ডিভাইসের একটি টেস্ট গ্রুপের সাথে পাইলট করুন। পাঁচটি বিষয় নিশ্চিত করুন:

1. প্রোফাইল স্ট্যাটাস। ট্রাস্টেড শংসাপত্র, SCEP এবং WiFi প্রোফাইলগুলি সবই Intune ডিভাইস কনফিগারেশন রিপোর্টিংয়ে সফলতা প্রকাশ করে।
2. ডিভাইসে সার্টিফিকেট। Windows-এ, সার্টিফিকেটটি প্রত্যাশিত subject, SAN এবং Client Authentication EKU সহ ব্যক্তিগত স্টোরে দৃশ্যমান হয়। এর চেইনটি Cloud PKI রুট পর্যন্ত তৈরি হওয়া উচিত।
3. ইস্যু করার রেকর্ড। Intune অ্যাডমিন সেন্টারে ইস্যুকারী CA-এর ইস্যুকৃত সার্টিফিকেটের তালিকায় সার্টিফিকেটটি দেখা যায়।
4. RADIUS লগ। অ্যাথেনটিকেশন লগ EAP-TLS সফলতা, প্রত্যাশিত পরিচয় এবং একটি বৈধ চেইন প্রদর্শন করে।
5. বাতিলকরণ পরীক্ষা (Revocation test)। একটি টেস্ট সার্টিফিকেট বাতিল করুন। RADIUS সার্ভার নতুন CRL গ্রহণ করার পর, নিশ্চিত করুন যে ডিভাইসটি প্রত্যাখ্যাত হয়েছে।

লাইভ হওয়ার আগে বাতিলকরণ পরীক্ষাটি চালান। আপনার RADIUS সার্ভার CRL-এ পৌঁছাতে পারে কিনা তা প্রমাণ করার এটিই একমাত্র পরীক্ষা।

Cloud PKI EAP-TLS-এর সাথে কী কী সমস্যা হয় এবং কীভাবে সেগুলি সমাধান করবেন?

লক্ষণ	সম্ভাব্য কারণ	সমাধান
SCEP প্রোফাইল ত্রুটি বা পেন্ডিং অবস্থায় আটকে আছে	বিশ্বস্ত সার্টিফিকেট প্রোফাইলগুলি একই গ্রুপে অ্যাসাইন করা হয়নি, অথবা SCEP প্রোফাইলটি রুটের পরিবর্তে ইস্যুকারী CA-কে রেফারেন্স করছে	রুট এবং ইস্যুকারী ট্রাস্টেড প্রোফাইলগুলিকে একই গ্রুপে অ্যাসাইন করুন এবং SCEP প্রোফাইলে রুট নির্বাচন করুন
সার্টিফিকেট ইস্যু করা হয়েছে, RADIUS "unknown CA" সহ প্রত্যাখ্যান করেছে	কেবল রুট RADIUS-এ ইমপোর্ট করা হয়েছে	ইস্যুকারী CA সার্টিফিকেটটিও ইমপোর্ট করুন
লাইভ হওয়ার পর প্রতিটি ডিভাইস প্রত্যাখ্যাত হচ্ছে	RADIUS CRL ডিস্ট্রিবিউশন পয়েন্টে পৌঁছাতে পারছে না এবং বন্ধ হয়ে ব্যর্থ হচ্ছে	RADIUS থেকে CRL হোস্ট পর্যন্ত আউটবাউন্ড HTTP অনুমতি দিন
Android ডিভাইস সংযোগ করতে অস্বীকার করছে	কোনো সার্ভার ভ্যালিডেশন সেট করা নেই; Android 11 এবং তার পরবর্তী সংস্করণগুলির জন্য এটি প্রয়োজন	RADIUS সার্ভারের রুটকে একটি ট্রাস্টেড প্রোফাইল হিসেবে ডিপ্লয় করুন এবং সার্টিফিকেট সার্ভারের নাম সেট করুন
Windows কর্মীদের সার্ভারকে বিশ্বাস করার জন্য প্রম্পট করে	WiFi প্রোফাইলের সার্ভারের নাম RADIUS সার্টিফিকেটের সাথে মেলে না	সার্টিফিকেটের সাথে হুবহু মেলাতে সার্ভারের নামগুলি সংশোধন করুন
NPS Microsoft Entra ID-যুক্ত ডিভাইসগুলিকে প্রত্যাখ্যান করে	NPS একটি অন-প্রেমিস Active Directory অ্যাকাউন্টের সন্ধান করে যা বিদ্যমান নেই	এমন একটি RADIUS পরিষেবা ব্যবহার করুন যা সার্টিফিকেটগুলিকে Microsoft Entra ID অবজেক্টে ম্যাপ করে
বাতিল করা ডিভাইস তবুও সংযোগ করছে	RADIUS একটি ক্যাশ করা CRL ধরে রেখেছে	বাতিলকরণকে একটি Microsoft Entra ID অ্যাকাউন্ট বা ডিভাইস নিষ্ক্রিয় করার সাথে জোড়া দিন এবং CRL ক্যাশিং পর্যালোচনা করুন
সার্টিফিকেটে Client Authentication নেই	সেই EKU ছাড়া ইস্যুকারী CA তৈরি করা হয়েছে	Client Authentication সহ একটি নতুন ইস্যুকারী CA তৈরি করুন এবং SCEP প্রোফাইলটিকে পুনরায় নির্দেশ করুন

অন্যত্র একই ডিভাইস অ্যাথেনটিকেশন করার সময় ব্যর্থতাগুলি যদি নির্দিষ্ট কক্ষ বা ফ্লোরে সীমাবদ্ধ থাকে, তবে ত্রুটিটি রেডিও কভারেজের, PKI-এর নয়। EAP-TLS একটি প্রাক-শেয়ার করা কী হ্যান্ডশেকের চেয়ে বেশি প্যাকেট বিনিময় করে, তাই দুর্বল সংকেত টাইমআউট হিসেবে দেখা দেয়। WiFi Site Surveys: A Practical Planning Guide এই ফাঁকগুলি কীভাবে খুঁজে বের করবেন তা নির্দেশ করে।

Cloud PKI নাকি NDES সহ SCEP: আপনার কোনটি বেছে নেওয়া উচিত?

আপনি ইতিমধ্যে কী পরিচালনা করছেন এবং কী অবসর নেওয়ার পরিকল্পনা করছেন তার ওপর ভিত্তি করে সিদ্ধান্ত নিন।

আপনার পরিস্থিতি	সুপারিশ	কেন
Microsoft Entra ID-যুক্ত ফ্লিট, কোনো AD CS নেই	Cloud PKI রুট সহ Cloud PKI	তৈরি বা চালানোর জন্য কোনো অন-প্রেমিস PKI নেই
AD CS কার্যকর রয়েছে, NDES সার্ভারগুলির OS রিফ্রেশ বাকি আছে	BYOCA সহ Cloud PKI	আপনার বিদ্যমান root trust বজায় রাখে এবং NDES ও কানেক্টর অবসর দেয়
দীর্ঘমেয়াদী CA রোডম্যাপ এবং অন্যান্য সার্টিফিকেট টেমপ্লেট সহ AD CS টিম	NDES সহ SCEP, পরবর্তী সার্ভার রিফ্রেশে পর্যালোচনা করুন	বিদ্যমান বিনিয়োগ ইতিমধ্যেই non-WiFi ব্যবহারের ক্ষেত্রগুলিকে কভার করে
বেশ কয়েকটি ডিভাইসে একই কী পেয়ারের প্রয়োজন, যেমন S/MIME	সেই ব্যবহারের ক্ষেত্রের জন্য PKCS, WiFi এর জন্য Cloud PKI	PKCS এক্সপোর্টযোগ্য কী প্রদান করে; WiFi সার্টিফিকেটগুলি ডিভাইস-বাউন্ড থাকা উচিত
NPS-এ আজ Hybrid-joined ডিভাইস, Microsoft Entra ID-তে স্থানান্তরিত হচ্ছে	Cloud PKI এবং একটি ক্লাউড RADIUS সার্ভিস	ডিভাইসগুলি Active Directory ছেড়ে দিলে NPS লুকআপগুলি ভেঙে যায়

Healthcare-এর নিয়ন্ত্রিত ক্ষেত্রগুলি প্রায়শই অন্যান্য ওয়ার্কলোডের জন্য AD CS বজায় রাখে। তাদের জন্য, BYOCA সাধারণত সঠিক ফিট, কারণ এটি সংস্থা জুড়ে একটি root of trust বজায় রাখে। Trains-এ অনবোর্ড কর্মীদের ট্যাবলেটে সার্টিফিকেট ইস্যুকারী রেল অপারেটররা Cloud PKI রুট রুট ফিট করে। সেই ডিভাইসগুলি প্রথম দিন থেকেই ক্লাউড-পরিচালিত।

Cloud PKI-এর খরচ কত এবং আপনি বিনিময়ে কী পান?

Microsoft প্রতি সিট, প্রতি মাসে Cloud PKI লাইসেন্স প্রদান করে। এটি Intune Suite-এর মধ্যে বা Intune Plan 1-এর উপরে একটি স্ট্যান্ডঅ্যালোন অ্যাড-অন হিসাবে আসে। Microsoft-এর বর্তমান মূল্য তালিকা পরীক্ষা করুন, কারণ বান্ডিলিং পরিবর্তিত হয়।

অন-প্রেমিসেস রুটে আপনার কী খরচ হয় তার সাথে এটি তুলনা করুন:

• ইস্যুইং CA, NDES এবং কানেক্টর হোস্টগুলির জন্য Windows Server লাইসেন্স এবং ভার্চুয়াল মেশিন
• NDES প্রকাশকারী রিভার্স প্রক্সি বা অ্যাপ্লিকেশন প্রক্সি
• CA ডেটাবেস ব্যাকআপ
• প্যাচিং এবং সার্টিফিকেট টেমপ্লেট অ্যাডমিনিস্ট্রেশন

ফলাফল হলো কম সার্ভার, কোনো ইন্টারনেট-প্রকাশিত NDES এন্ডপয়েন্ট নেই এবং আপনার পরিচালিত প্রতিটি প্ল্যাটফর্মে ডিভাইস-বাউন্ড কী।

কাজের দৃশ্যপট: একটি ৩০-টি প্রপার্টির হোটেল গ্রুপ

পরিস্থিতি। ৩০টি hotels-এর একটি গ্রুপ একটি শেয়ার করা প্রাক-শেয়ার করা কী দিয়ে সুরক্ষিত কর্মীদের SSID-তে ৯০০টি Microsoft Entra ID-যুক্ত ল্যাপটপ এবং ফ্রন্ট-ডেস্ক ট্যাবলেট চালিয়েছে। প্রতিটি কোয়ার্টারে সেই কী ঘোরানোর অর্থ হলো প্রতিটি প্রপার্টির প্রতিটি ডিভাইস স্পর্শ করা। একটি হারিয়ে যাওয়া ট্যাবলেট পরবর্তী রোটেশন না হওয়া পর্যন্ত কীটিকে উন্মুক্ত রেখে দেয়।

কী করা হয়েছিল। IT একটি Cloud PKI রুট এবং ইস্যুইং CA তৈরি করেছে, তারপর SCEP-এর মাধ্যমে TPM-ব্যাকড ডিভাইস সার্টিফিকেট ইস্যু করেছে। একটি ক্লাউড RADIUS সার্ভিস চেইন যাচাই করেছে এবং CRL চেক করেছে। গ্রুপটি পাইলটের জন্য পুরনোটির পাশাপাশি একটি EAP-TLS SSID চালিয়েছে, তরঙ্গের মাধ্যমে প্রপার্টি স্থানান্তরিত করেছে, তারপর প্রাক-শেয়ার করা কী নেটওয়ার্ক বন্ধ করে দিয়েছে।

ফলাফল। দৃশ্যপটের হিসাব সোজা:

• কর্মীদের নেটওয়ার্কে শেয়ার করা গোপনীয়তা এক থেকে শূন্যে নেমে এসেছে।
• ৩০টি প্রপার্টি জুড়ে ত্রৈমাসিক কী রোটেশন সম্পূর্ণরূপে বন্ধ হয়ে গেছে।
• একটি হারিয়ে যাওয়া ট্যাবলেট ৯০০টি ডিভাইসের রি-কী-এর বদলে একটি সার্টিফিকেট বাতিলকরণে পরিণত হয়।
• কোনো অন-প্রেমিসেস CA, NDES সার্ভার বা কানেক্টরের প্রয়োজন নেই।

কাজের দৃশ্যপট: একটি ২৫০-টি স্টোরের খুচরা চেইন

পরিস্থিতি। একটি রিটেল চেইন AD CS এবং দুটি NDES সার্ভারের মাধ্যমে ৪,০০০ স্টোর হ্যান্ডহেল্ড এবং ল্যাপটপে WiFi সার্টিফিকেট ইস্যু করেছে। Intune Certificate Connector একটি তৃতীয় সার্ভারে চলছিল। তিনটি সার্ভারই অপারেটিং সিস্টেম প্রতিস্থাপনের জন্য নির্ধারিত ছিল, এবং NDES একটি অ্যাপ্লিকেশন প্রক্সির মাধ্যমে প্রকাশ করা হয়েছিল।

যা করা হয়েছিল। টিম BYOCA হিসেবে একটি Cloud PKI ইস্যুকারী CA তৈরি করেছে এবং বিদ্যমান AD CS রুট দিয়ে এটি স্বাক্ষর করেছে। RADIUS সার্ভার ইতিমধ্যেই সেই রুট বিশ্বাস করত, তাই কেবল নতুন ইস্যুকারী CA সার্টিফিকেট ইমপোর্ট করা হয়েছিল। SCEP প্রোফাইলগুলি একবারে একটি স্টোর গ্রুপে Cloud PKI-তে স্থানান্তরিত হয়েছে। বিদ্যমান সার্টিফিকেটগুলি নবায়ন পর্যন্ত বৈধ ছিল, যা রোলব্যাক বজায় রেখেছিল।

ফলাফল। চেইনটি তিনটি সার্ভার রিটায়ার করেছে: দুটি NDES এবং একটি কানেক্টর হোস্ট। এটি ইন্টারনেট-প্রকাশিত NDES এন্ডপয়েন্টও সরিয়ে দিয়েছে। RADIUS বা কোনও ডিভাইসে কোনও রুট পুনরায় বিশ্বাসের প্রয়োজন ছিল না। অন্যান্য ওয়ার্কলোডের জন্য AD CS রুটটি আগের মতোই রয়ে গেছে।

Purple কোথায় ফিট করে

Purple স্টাফ WiFi ক্লাউড RADIUS সহ আইডেন্টিটি-ভিত্তিক নেটওয়ার্ক ব্যবহার করে, যা Microsoft Entra ID, Okta বা Google Workspace-এর সাথে সংযুক্ত। Purple ব্র্যান্ডগুলি Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet-জুড়ে হার্ডওয়্যার-অজ্ঞেয়বাদী। কেন আপনার পরবর্তী WiFi আপগ্রেডে নতুন হার্ডওয়্যারের প্রয়োজন নেই ব্যাখ্যা করে কেন সার্টিফিকেট-ভিত্তিক স্টাফ এক্সেসে স্যুইচ করার অর্থ অ্যাক্সেস পয়েন্টগুলি প্রতিস্থাপন করা নয়।

Purple ৯৯.৯৯৯% আপটাইম সহ ৮০,০০০+ লাইভ ভেন্যুতে (Purple ডেটা) চালিত হয় এবং এটি ISO 27001 সার্টিফাইড। স্টাফ এবং ভিজিটরদের আলাদা নেটওয়ার্কে রাখুন: আপনি যে ডিভাইসগুলি পরিচালনা করেন তার জন্য সার্টিফিকেট-ভিত্তিক স্টাফ WiFi এবং বাকি সবার জন্য গেস্ট WiFi।

প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

Microsoft Cloud PKI কি WiFi সার্টিফিকেট ইস্যু করতে পারে?

হ্যাঁ। Cloud PKI একটি SCEP সার্টিফিকেট প্রোফাইলের মাধ্যমে Intune-পরিচালিত Windows, macOS, iOS/iPadOS এবং Android ডিভাইসগুলিতে ক্লায়েন্ট প্রমাণীকরণ সার্টিফিকেট ইস্যু করে। সেই সার্টিফিকেটগুলি EAP-TLS ব্যবহার করে WPA2-Enterprise বা WPA3-Enterprise নেটওয়ার্কে ডিভাইসগুলিকে প্রমাণিত করে। আপনার ইস্যুকারী CA-তে অবশ্যই Client Authentication EKU অন্তর্ভুক্ত থাকতে হবে এবং আপনার RADIUS সার্ভারকে অবশ্যই Cloud PKI রুট এবং ইস্যুকারী CA-কে বিশ্বাস করতে হবে। Cloud PKI সাধারণত RADIUS সার্ভারের নিজস্ব সার্টিফিকেট ইস্যু করে না। সেই সার্টিফিকেট একটি পাবলিক CA বা আপনার বিদ্যমান PKI থেকে আসে।

Cloud PKI-এর সাথে কি এখনও NDES-এর প্রয়োজন আছে?

না। Cloud PKI নিজেই SCEP অনুরোধের উত্তর দেয়, তাই আপনার কোনও NDES সার্ভার, Intune Certificate Connector এবং ইন্টারনেটে NDES প্রকাশ করার জন্য কোনও রিভার্স প্রক্সির প্রয়োজন নেই। Intune-এর SCEP প্রোফাইলটি আপনার Cloud PKI ইস্যুকারী CA-তে দেখানো SCEP URI-এর দিকে সরাসরি নির্দেশ করে। আপনি যদি ব্রিং-ইউর-ওন-CA অপশন ব্যবহার করেন, তবে আপনার প্রাইভেট রুট Cloud PKI ইস্যুকারী CA-কে একবার স্বাক্ষর করে। তার পর, ডিভাইস এনরোলমেন্ট কখনও আপনার অন-প্রিমাইস সার্ভারগুলিকে স্পর্শ করে না।

RADIUS সার্ভার কীভাবে Cloud PKI সার্টিফিকেট বিশ্বাস করে?

আপনি Cloud PKI রুট এবং ইস্যুয়িং CA সার্টিফিকেটগুলো RADIUS সার্ভারের ট্রাস্টেড CA স্টোরে ইম্পোর্ট করবেন। Intune অ্যাডমিন সেন্টার থেকে উভয়ই ডাউনলোড করুন। উভয়ই ইম্পোর্ট করুন, কারণ কেবল রুট ইম্পোর্ট করলে "অজানা CA" প্রত্যাখ্যান হতে পারে। RADIUS সার্ভারের প্রতিটি সার্টিফিকেটে থাকা CRL ডিস্ট্রিবিউশন পয়েন্টে আউটবাউন্ড HTTP অ্যাক্সেস থাকা প্রয়োজন, যাতে এটি বাতিলকরণ পরীক্ষা করতে পারে। Entra ID-যুক্ত ডিভাইসগুলোর জন্য, এটি অন-প্রেমিস Active Directory-এর বদলে Entra ID-তে সার্টিফিকেট আইডেন্টিটিগুলো ম্যাপ করবে।

Cloud PKI-এর মাধ্যমে কীভাবে বাতিলকরণ (revocation) কাজ করে?

আপনি Intune অ্যাডমিন সেন্টারে থাকা ইস্যুয়িং CA থেকে একটি সার্টিফিকেট বাতিল করেন এবং Cloud PKI এই পরিবর্তনটি তার CRL-এ প্রকাশ করে। আপনার RADIUS সার্ভার সেই CRL ডাউনলোড করে এবং বাতিল করা সার্টিফিকেটগুলো প্রত্যাখ্যান করে। যেহেতু RADIUS সার্ভারগুলো CRL ক্যাশে করে রাখে, তাই একটি বাতিল করা ডিভাইস পরবর্তী রিফ্রেশ না হওয়া পর্যন্ত কানেক্ট হতে পারে। আপনার RADIUS সার্ভিস যদি প্রতিটি অথেন্টিকেশনে আইডেন্টিটি স্ট্যাটাস পরীক্ষা করে, তবে Entra ID অ্যাকাউন্ট বা ডিভাইসটিও ডিজেবল করে সেই ব্যবধান বন্ধ করুন।

আমার কি Cloud PKI নাকি NDES সহ SCEP বেছে নেওয়া উচিত?

আপনি যদি Entra ID-যুক্ত ফ্লিট চালান বা অন-প্রেমিস PKI সার্ভারগুলো অবসর দেওয়ার পরিকল্পনা করেন তবে Cloud PKI বেছে নিন। এটি ইস্যুয়িং CA, NDES এবং কানেক্টর হোস্টগুলোকে সরিয়ে দেয়। আপনার যদি একটি পরিপক্ক AD CS টিম, দীর্ঘমেয়াদী CA রোডম্যাপ এবং অন্যান্য সার্টিফিকেট টেমপ্লেট থাকে তবে NDES সহ SCEP রাখুন। আপনার NDES সার্ভারগুলো যদি রিফ্রেশ করার সময় হয়ে থাকে, তবে BYOCA সহ Cloud PKI আপনার বিদ্যমান রুট ট্রাস্ট বজায় রাখে এবং তাও NDES অবসর দেয়।

Microsoft Cloud PKI কীভাবে লাইসেন্সপ্রাপ্ত হয়?

Cloud PKI প্রতি সিট, প্রতি মাসে, Intune Plan 1-এর উপরে লাইসেন্সপ্রাপ্ত হয়। এটি Microsoft Intune Suite-এর অংশ হিসাবে অথবা একটি স্ট্যান্ডঅ্যালোন Cloud PKI অ্যাড-অন হিসাবে আসে। বাজেট করার আগে Microsoft-এর বর্তমান মূল্যের তালিকা পরীক্ষা করুন, কারণ বান্ডেলগুলো পরিবর্তিত হয়। একটি AD CS, NDES এবং কানেক্টর স্ট্যাকের জন্য প্রয়োজনীয় Windows Server লাইসেন্স, ভার্চুয়াল মেশিন, প্রক্সি পাবলিশিং এবং প্যাচিং প্রচেষ্টার বিপরীতে লাইসেন্স খরচ সেট করুন।

আমি কি Cloud PKI-এর সাথে আমার বিদ্যমান অন-প্রেমিস রুট CA রাখতে পারি?

হ্যাঁ, ব্রিং-ইউর-ওন-CA অপশনের মাধ্যমে। আপনি একটি Cloud PKI ইস্যুয়িং CA তৈরি করেন, এর সার্টিফিকেট সাইনিং রিকোয়েস্ট এক্সপোর্ট করেন এবং আপনার বিদ্যমান প্রাইভেট রুট, যেমন AD CS দিয়ে এটি সাইন করেন। যা কিছু ইতিমধ্যেই সেই রুটকে বিশ্বাস করে, আপনার RADIUS সার্ভার এবং ডিভাইসগুলোসহ, তা নতুন চেইনকেও বিশ্বাস করবে। আপনি কেবল ইস্যুয়িং CA সার্টিফিকেটটি যোগ করবেন। আপনি গ্রুপ বাই গ্রুপ SCEP প্রোফাইল মাইগ্রেট করতে পারেন এবং বিদ্যমান সার্টিফিকেটগুলো রিনিউয়াল না হওয়া পর্যন্ত বৈধ থাকবে।

Cloud PKI কি আমার বিদ্যমান অ্যাক্সেস পয়েন্টগুলোর সাথে কাজ করে?

হ্যাঁ, যতক্ষণ না আপনার অ্যাক্সেস পয়েন্টগুলো WPA2-Enterprise বা WPA3-Enterprise-এর সাথে 802.1X সাপোর্ট করে। Cloud PKI কেবল ডিভাইসগুলোর সার্টিফিকেট এবং আপনার RADIUS সার্ভারের ট্রাস্টকে প্রভাবিত করে। অ্যাক্সেস পয়েন্টগুলো কেবল RADIUS-এ অথেন্টিকেশন ফরোয়ার্ড করে। Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme এবং Fortinet সবই এটি সাপোর্ট করে। Purple-এর Staff WiFi হার্ডওয়্যার-নিরপেক্ষ ক্লাউড ওভারলে হিসাবে এই আটটির মাধ্যমেই পরিচালিত হয়।