Skip to main content

SCEP এবং PKCS-এর মাধ্যমে Microsoft Intune WiFi সার্টিফিকেট ডেপ্লয়মেন্ট

এই নির্দেশিকাটি SCEP এবং PKCS ব্যবহার করে Microsoft Intune-এর মাধ্যমে WiFi অথেন্টিকেশন সার্টিফিকেট ডেপ্লয় করার জন্য একটি ধাপে ধাপে প্রযুক্তিগত রেফারেন্স প্রদান করে। এটি এন্টারপ্রাইজ এনভায়রনমেন্ট জুড়ে নিরবচ্ছিন্ন, সুরক্ষিত কানেক্টিভিটি নিশ্চিত করতে পাসওয়ার্ডহীন 802.1X WiFi বাস্তবায়নকারী IT ম্যানেজার এবং নেটওয়ার্ক আর্কিটেক্টদের জন্য ডিজাইন করা হয়েছে।

📖 6 মিনিট পাঠ📝 1,299 শব্দ🔧 2 উদাহরণ3 প্রশ্ন📚 8 মূল শব্দসমূহ

header_image.png

এক্সিকিউটিভ সামারি

এন্টারপ্রাইজ ভেন্যুগুলোর জন্য—সেটি একটি ব্যস্ত Hospitality এনভায়রনমেন্ট হোক, একটি মাল্টি-সাইট Retail অপারেশন হোক বা একটি আধুনিক কর্পোরেট ক্যাম্পাস হোক—স্টাফ WiFi-এর জন্য প্রি-শেয়ারড কি (keys) বা বেসিক Captive Portal-এর ওপর নির্ভর করা একটি সিকিউরিটি ঝুঁকি এবং অপারেশনাল বাধা। আধুনিক নেটওয়ার্ক আর্কিটেকচারে EAP-TLS ব্যবহার করে 802.1X অথেন্টিকেশন প্রয়োজন, যা নেটওয়ার্ক অ্যাক্সেস করার আগে প্রতিটি ডিভাইস ক্রিপ্টোগ্রাফিকভাবে যাচাই করা নিশ্চিত করে।

তবে চ্যালেঞ্জটি হলো ডিস্ট্রিবিউশনে: হাজার হাজার Windows, iOS, এবং Android ডিভাইসে কীভাবে ইউনিক ক্লায়েন্ট সার্টিফিকেট ডেপ্লয় করবেন যাতে হেল্পডেস্ক সাপোর্ট টিকিটে ডুবে না যায়? Microsoft Intune স্বয়ংক্রিয় সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্টের মাধ্যমে এটি সমাধান করে। SCEP (Simple Certificate Enrollment Protocol) বা PKCS (Public Key Cryptography Standards) সার্টিফিকেট প্রোফাইল ব্যবহার করে, IT টিমগুলো ম্যানেজড এন্ডপয়েন্টগুলোতে ট্রাস্টেড রুট এবং ক্লায়েন্ট সার্টিফিকেট সাইলেন্টলি পুশ করতে পারে।

এই নির্দেশিকাটি Intune WiFi সার্টিফিকেট ডেপ্লয়মেন্টের জন্য একটি চূড়ান্ত আর্কিটেকচারাল ব্লুপ্রিন্ট এবং ধাপে ধাপে ইমপ্লিমেন্টেশন স্ট্র্যাটেজি প্রদান করে। আমরা SCEP এবং PKCS-এর মধ্যে গুরুত্বপূর্ণ পার্থক্যগুলো অন্বেষণ করব, সফলতার জন্য প্রয়োজনীয় সঠিক ডেপ্লয়মেন্ট সিকোয়েন্স বিস্তারিত আলোচনা করব এবং আপনার Guest WiFi এবং কর্পোরেট নেটওয়ার্কগুলো সুরক্ষিত ও পারফরম্যান্ট রাখা নিশ্চিত করতে বাস্তব-বিশ্বের ঝুঁকি প্রশমন কৌশলগুলো তুলে ধরব।

সহযোগী পডকাস্ট ব্রিফিংটি শুনুন: microsoft_intune_wifi_certificate_deployment_via_scep_and_pkcs_podcast.wav

টেকনিক্যাল ডিপ-ডাইভ: SCEP বনাম PKCS

আপনার Intune WiFi সার্টিফিকেট ডেপ্লয়মেন্ট স্ট্র্যাটেজি ডিজাইন করার সময়, প্রথম আর্কিটেকচারাল সিদ্ধান্ত হলো সার্টিফিকেট ডেলিভারি মেকানিজম নির্বাচন করা। Intune SCEP এবং PKCS উভয়ই সাপোর্ট করে, তবে তারা মৌলিকভাবে ভিন্নভাবে কাজ করে।

SCEP (Simple Certificate Enrollment Protocol)

এন্টারপ্রাইজ ডিভাইস এনরোলমেন্টের জন্য SCEP হলো ইন্ডাস্ট্রি স্ট্যান্ডার্ড। একটি SCEP ওয়ার্কফ্লোতে, Intune সার্ভিস এন্ডপয়েন্টকে নিজস্ব প্রাইভেট/পাবলিক কি (key) পেয়ার তৈরি করার নির্দেশ দেয়। ডিভাইসটি তখন একটি Certificate Signing Request (CSR) তৈরি করে এবং একটি Network Device Enrollment Service (NDES) সার্ভারের মাধ্যমে আপনার Certificate Authority (CA)-তে পাঠায়। CA অনুরোধটি সাইন করে এবং ডিভাইসে পাবলিক সার্টিফিকেট ফেরত দেয়।

SCEP-এর গুরুত্বপূর্ণ সিকিউরিটি সুবিধা হলো প্রাইভেট কি (private key) কখনোই ডিভাইস থেকে বের হয় না। এটি লোকালি জেনারেট হয়, ডিভাইসের সিকিউর এনক্লেভে (যেমন Windows-এ TPM বা iOS-এ Secure Enclave) সংরক্ষিত থাকে এবং কখনোই নেটওয়ার্কের মাধ্যমে ট্রান্সমিট হয় না। এটি 802.1X অথেন্টিকেশনের জন্য SCEP-কে একটি জোরালোভাবে সুপারিশকৃত পদ্ধতি করে তোলে।

PKCS (Public Key Cryptography Standards)

বিপরীতভাবে, PKCS-এর ক্ষেত্রে, Certificate Authority পাবলিক এবং প্রাইভেট উভয় কি (keys) সেন্ট্রালি জেনারেট করে। Microsoft Intune Certificate Connector তখন এই কি পেয়ারটি সুরক্ষিতভাবে এক্সপোর্ট করে এবং টার্গেট ডিভাইসে পুশ করে।

যদিও PKCS একটি NDES সার্ভার ডেপ্লয় এবং মেইনটেইন করার প্রয়োজনীয়তা দূর করে—ইনফ্রাস্ট্রাকচার ফুটপ্রিন্ট সহজ করে—এটি একটি তাত্ত্বিক সিকিউরিটি ঝুঁকি তৈরি করে কারণ প্রাইভেট কি নেটওয়ার্কের মাধ্যমে ট্রান্সমিট হয়। PKCS সাধারণত নেটওয়ার্ক অথেন্টিকেশনের চেয়ে S/MIME ইমেল এনক্রিপশনের মতো ব্যবহারের ক্ষেত্রে বেশি উপযোগী যেখানে কি এসক্রো (key escrow) প্রয়োজন।

scep_vs_pkcs_comparison.png

ইমপ্লিমেন্টেশন গাইড: ডেপ্লয়মেন্ট সিকোয়েন্স

802.1X-এর জন্য একটি Intune WiFi প্রোফাইল সফলভাবে কনফিগার করার জন্য একটি নির্দিষ্ট ডেপ্লয়মেন্ট সিকোয়েন্স কঠোরভাবে অনুসরণ করা প্রয়োজন। Intune প্রোফাইল ডিপেন্ডেন্সি নির্দেশ করে যে অথেন্টিকেশন কনফিগার করার আগে ট্রাস্ট (trust) স্থাপন করতে হবে।

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

কোনো ডিভাইস ক্লায়েন্ট সার্টিফিকেটের জন্য অনুরোধ করার আগে বা আপনার RADIUS সার্ভারকে বিশ্বাস করার আগে, তাকে অবশ্যই ইস্যুকারী Certificate Authority-কে বিশ্বাস করতে হবে।

  1. আপনার Root CA সার্টিফিকেট (এবং যেকোনো Intermediate CA সার্টিফিকেট) .cer ফাইল হিসেবে এক্সপোর্ট করুন।
  2. Microsoft Endpoint Manager অ্যাডমিন সেন্টারে, Devices > Configuration profiles > Create profile-এ যান।
  3. টার্গেট প্ল্যাটফর্ম (যেমন, Windows 10 এবং পরবর্তী সংস্করণ) নির্বাচন করুন এবং Trusted certificate প্রোফাইল টাইপ বেছে নিন।
  4. .cer ফাইলটি আপলোড করুন এবং আপনার টার্গেট ডিভাইস গ্রুপগুলোতে এই প্রোফাইলটি ডেপ্লয় করুন।

Rule of Thumb: ডেপ্লয়মেন্ট মিসম্যাচ রোধ করতে সর্বদা সমস্ত সম্পর্কিত প্রোফাইল জুড়ে একই গ্রুপকে (ইউজার বা ডিভাইস) টার্গেট করুন।

ধাপ ২: SCEP সার্টিফিকেট প্রোফাইল কনফিগার করুন

ট্রাস্ট স্থাপিত হয়ে গেলে, ডিভাইসগুলো কীভাবে তাদের ক্লায়েন্ট সার্টিফিকেট পাবে তা নির্দেশ করতে SCEP প্রোফাইল কনফিগার করুন।

  1. একটি নতুন কনফিগারেশন প্রোফাইল তৈরি করুন এবং SCEP certificate নির্বাচন করুন।
  2. Subject name format কনফিগার করুন। ইউজার-চালিত অথেন্টিকেশনের জন্য, CN={{UserPrincipalName}} হলো স্ট্যান্ডার্ড। ডিভাইস অথেন্টিকেশনের জন্য, CN={{AAD_Device_ID}} ব্যবহার করুন।
  3. Key usage-কে Digital signature এবং Key encipherment হিসেবে সেট করুন।
  4. Extended key usage-এর অধীনে, Client Authentication (OID: 1.3.6.1.5.5.7.3.2) নির্দিষ্ট করুন।
  5. ধাপ ১-এ তৈরি করা ট্রাস্টেড রুট সার্টিফিকেট প্রোফাইলের সাথে এই প্রোফাইলটি লিঙ্ক করুন।
  6. আপনার NDES সার্ভারের এক্সটার্নাল URL প্রদান করুন।

ধাপ ৩: 802.1X WiFi প্রোফাইল ডেপ্লয় করুন

শেষ ধাপ হলো WiFi কনফিগারেশন পুশ করা যা নেটওয়ার্ক SSID-এর সাথে সার্টিফিকেটগুলোকে যুক্ত করে।

  1. একটি Wi-Fi কনফিগারেশন প্রোফাইল তৈরি করুন।
  2. আপনার Wireless Access Points দ্বারা ব্রডকাস্ট করা Network name (SSID) ঠিক সেভাবেই লিখুন।
  3. সিকিউরিটি টাইপ হিসেবে WPA2-Enterprise বা WPA3-Enterprise নির্বাচন করুন।
  4. EAP type-কে EAP-TLS হিসেবে সেট করুন।
  5. অথেন্টিকেশন সেটিংসে, ধাপ ২-এ তৈরি করা SCEP সার্টিফিকেট প্রোফাইলটিকে ক্লায়েন্ট অথেন্টিকেশন সার্টিফিকেট হিসেবে নির্বাচন করুন।
  6. সার্ভার ভ্যালিডেশনের জন্য ট্রাস্টেড রুট সার্টিফিকেট নির্দিষ্ট করুন যাতে ডিভাইসটি শুধুমাত্র আপনার বৈধ RADIUS সার্ভারের সাথে কানেক্ট হয়।

architecture_overview.png

বেস্ট প্র্যাকটিস এবং ইন্ডাস্ট্রি স্ট্যান্ডার্ড

Intune WiFi সার্টিফিকেট ডেপ্লয়মেন্ট বাস্তবায়নের সময়, কমপ্লায়েন্স এবং নির্ভরযোগ্যতা নিশ্চিত করতে নিম্নলিখিত ভেন্ডর-নিরপেক্ষ বেস্ট প্র্যাকটিসগুলো মেনে চলুন।

NDES সার্ভার প্লেসমেন্ট এবং সিকিউরিটি

রিমোট ডিভাইসগুলোকে সাইটে আসার আগে সার্টিফিকেট প্রোভিশন করার অনুমতি দিতে NDES সার্ভারটি ইন্টারনেট থেকে অ্যাক্সেসযোগ্য হতে হবে। তবে, একটি ইন্টারনাল সার্ভার সরাসরি ইন্টারনেটে এক্সপোজ করা একটি উল্লেখযোগ্য সিকিউরিটি ঝুঁকি।

সুপারিশ: Azure AD Application Proxy ব্যবহার করে NDES URL পাবলিশ করুন। এটি ইনবাউন্ড ফায়ারওয়াল পোর্ট না খুলেই সুরক্ষিত রিমোট অ্যাক্সেস প্রদান করে এবং আপনাকে এনরোলমেন্ট ফ্লোতে Conditional Access পলিসি প্রয়োগ করার অনুমতি দেয়।

RADIUS এবং CRL চেকিং

সার্টিফিকেট ডেপ্লয়মেন্ট হলো সিকিউরিটি সমীকরণের অর্ধেক মাত্র; রিভোকেশন (revocation) সমানভাবে গুরুত্বপূর্ণ। যদি কোনো এমপ্লয়ির চাকরি শেষ হয়ে যায়, তবে তাদের Active Directory অ্যাকাউন্ট ডিজেবল করা হলেও তাদের WiFi অ্যাক্সেস অবিলম্বে বাতিল নাও হতে পারে যদি তাদের ক্লায়েন্ট সার্টিফিকেট বৈধ থাকে এবং RADIUS সার্ভার কঠোরভাবে Certificate Revocation List (CRL) চেক না করে।

সুপারিশ: কঠোর CRL চেকিং কার্যকর করতে আপনার Network Policy Server (NPS) বা RADIUS সার্ভার কনফিগার করুন। নিশ্চিত করুন যে আপনার CRL Distribution Points (CDPs) উচ্চমাত্রায় অ্যাভেইলেবল থাকে; যদি RADIUS সার্ভার CRL-এ পৌঁছাতে না পারে, তবে অথেন্টিকেশন ব্যর্থ হবে, যার ফলে ব্যাপক বিভ্রাট ঘটবে।

সুরক্ষিত নেটওয়ার্ক ডিজাইনের আরও তথ্যের জন্য, The Core SD WAN Benefits for Modern Businesses পর্যালোচনা করার কথা বিবেচনা করুন।

ট্রাবলশুটিং এবং ঝুঁকি প্রশমন

নিখুঁত পরিকল্পনা সত্ত্বেও, সার্টিফিকেট ডেপ্লয়মেন্টে সমস্যা হতে পারে। এখানে সাধারণ কিছু ব্যর্থতার ধরন এবং প্রশমন কৌশল দেওয়া হলো।

সমস্যা: WiFi প্রোফাইল প্রয়োগ করতে ব্যর্থ হচ্ছে

লক্ষণ: ডিভাইসটি ট্রাস্টেড রুট এবং SCEP সার্টিফিকেট গ্রহণ করে, কিন্তু Intune-এ WiFi প্রোফাইল 'Error' বা 'Not Applicable' হিসেবে দেখায়।

মূল কারণ: এটি প্রায় সবসময় গ্রুপ টার্গেটিং-এর অমিলের কারণে ঘটে। যদি SCEP প্রোফাইল একটি ইউজার গ্রুপে অ্যাসাইন করা হয়, কিন্তু WiFi প্রোফাইল একটি ডিভাইস গ্রুপে অ্যাসাইন করা হয়, তবে Intune ডিপেন্ডেন্সি রেজলভ করতে পারে না।

প্রশমন: আপনার অ্যাসাইনমেন্টগুলো অডিট করুন। নিশ্চিত করুন যে ট্রাস্টেড রুট, SCEP এবং WiFi প্রোফাইলগুলো সবই ঠিক একই Azure AD গ্রুপে ডেপ্লয় করা হয়েছে।

সমস্যা: NDES 403 Forbidden এরর

লক্ষণ: ডিভাইসগুলো SCEP সার্টিফিকেট সংগ্রহ করতে ব্যর্থ হয় এবং NDES IIS লগগুলোতে HTTP 403 এরর দেখায়।

মূল কারণ: Intune Certificate Connector সার্ভিস অ্যাকাউন্টের সার্টিফিকেট টেমপ্লেটে প্রয়োজনীয় পারমিশন নেই, অথবা আপনার ফায়ারওয়ালের URL ফিল্টারিং SCEP দ্বারা ব্যবহৃত নির্দিষ্ট কোয়েরি স্ট্রিং প্যারামিটারগুলোকে ব্লক করছে।

প্রশমন: যাচাই করুন যে কানেক্টর অ্যাকাউন্টের CA টেমপ্লেটে 'Read' এবং 'Enroll' পারমিশন আছে। ফায়ারওয়াল লগ চেক করে নিশ্চিত করুন যে ?operation=GetCACaps সম্বলিত URL-গুলো ব্লক করা হচ্ছে না।

ROI এবং ব্যবসায়িক প্রভাব

Microsoft Intune 802.1X সার্টিফিকেট ডেপ্লয়মেন্টে স্থানান্তরিত হওয়া সিকিউরিটি এবং অপারেশন জুড়ে পরিমাপযোগ্য রিটার্ন প্রদান করে।

  1. হেল্পডেস্ক টিকিট হ্রাস: পাসওয়ার্ড-ভিত্তিক WiFi প্রচুর পরিমাণে সাপোর্ট টিকিট তৈরি করে (পাসওয়ার্ডের মেয়াদ শেষ হওয়া, লকআউট, টাইপো)। সার্টিফিকেট-ভিত্তিক অথেন্টিকেশন ইউজারের কাছে অদৃশ্য, যা সাধারণত WiFi সংক্রান্ত হেল্পডেস্ক ভলিউম ৭০-৮০% কমিয়ে দেয়।
  2. উন্নত সিকিউরিটি পজিশন: EAP-TLS ক্রেডেনশিয়াল হার্ভেস্টিং এবং Man-in-the-Middle (MitM) অ্যাটাকের ঝুঁকি দূর করে। এটি PCI DSS এবং GDPR-এর মতো ফ্রেমওয়ার্কগুলোর কমপ্লায়েন্সের জন্য অত্যন্ত গুরুত্বপূর্ণ, বিশেষ করে Healthcare এবং রিটেইল এনভায়রনমেন্টে।
  3. নিরবচ্ছিন্ন অনবোর্ডিং: Windows-এর পাশাপাশি Apple ডিভাইসের বিশাল ফ্লিট ম্যানেজ করা সংস্থাগুলোর জন্য, বিদ্যমান MDM ওয়ার্কফ্লোর সাথে Intune ইন্টিগ্রেট করা (আমাদের গাইড দেখুন: Jamf and RADIUS: Certificate-Based WiFi Authentication for Apple Device Fleets ) প্রথম দিন থেকেই একটি ইউনিফাইড, জিরো-টাচ প্রোভিশনিং অভিজ্ঞতা নিশ্চিত করে।

মূল শব্দ ও সংজ্ঞা

SCEP (Simple Certificate Enrollment Protocol)

A protocol that allows devices to request digital certificates from a Certificate Authority, where the private key is generated and stored securely on the device itself.

The recommended method for deploying WiFi authentication certificates due to its high security and scalability.

PKCS (Public Key Cryptography Standards)

A set of standards where both the public and private keys are generated by the Certificate Authority and then securely delivered to the endpoint.

Often used for S/MIME email encryption, but less ideal for WiFi due to the network transmission of the private key.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as a bridge, allowing devices without domain credentials to obtain certificates via SCEP.

A required infrastructure component when implementing SCEP certificate deployment with Microsoft Intune.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

The most secure 802.1X authentication method, requiring both the server and the client to present valid digital certificates.

The target authentication protocol that the Intune WiFi and certificate profiles are designed to enable.

CRL (Certificate Revocation List)

A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their expiration date.

Critical for security; RADIUS servers must check the CRL to ensure terminated employees cannot access the WiFi using an otherwise valid certificate.

Intune Certificate Connector

A software agent installed on an on-premises Windows Server that brokers requests between Microsoft Intune and the internal Certificate Authority.

Required for both SCEP (to validate requests) and PKCS (to export keys) deployments.

Subject Alternative Name (SAN)

An extension to a digital certificate that allows multiple values (like UPN, email, or MAC address) to be associated with the certificate.

Configured in the Intune SCEP profile to ensure the RADIUS server can accurately identify the user or device.

Azure AD Application Proxy

A feature that provides secure remote access to on-premises web applications without requiring a VPN or opening inbound firewall ports.

The best practice method for securely publishing the internal NDES server URL to the internet for remote device enrollment.

কেস স্টাডিজ

A national retail chain with 500 locations is migrating from WPA2-Personal (Pre-Shared Key) to WPA3-Enterprise for their store associate tablets (Android Enterprise Dedicated Devices). They use Intune for MDM. How should they architect the certificate deployment?

  1. Deploy an NDES server published via Azure AD App Proxy.
  2. Create a Device-based SCEP certificate profile in Intune, as these are dedicated (kiosk) devices not tied to a specific user. Use CN={{AAD_Device_ID}} for the Subject Name.
  3. Deploy the Root CA profile to the 'All Store Tablets' Azure AD Device Group.
  4. Deploy the SCEP profile to the same 'All Store Tablets' group.
  5. Create a Wi-Fi profile configured for WPA3-Enterprise, EAP-TLS, referencing the SCEP profile, and deploy it to the same group.
  6. Configure the central RADIUS servers to authenticate the device certificates against the Active Directory computer objects.
বাস্তবায়ন সংক্রান্ত নোট: This approach correctly identifies that dedicated devices require device-based (not user-based) certificates. By targeting Device Groups consistently across all three profiles, the architect avoids the most common Intune deployment failure. Using Azure AD App Proxy for NDES ensures the tablets can renew certificates securely without VPNs.

A large conference centre uses Purple for their [WiFi Analytics](/products/wifi-analytics) and Guest WiFi, but needs to secure their internal staff network. Staff use a mix of corporate-owned Windows laptops and BYOD iOS devices. How do they handle the Intune deployment for the BYOD devices?

  1. Require BYOD users to enroll their iOS devices via Intune User Enrollment (creating a secure work partition).
  2. Create a User-based SCEP certificate profile using CN={{UserPrincipalName}}.
  3. Deploy the Root CA, SCEP, and Wi-Fi profiles to an Azure AD User Group (e.g., 'All Staff').
  4. When the user enrolls their personal device, Intune pushes the profiles specifically to the managed work partition.
  5. The device connects to the staff SSID using the user's identity, allowing the RADIUS server to apply role-based access control (VLAN assignment) based on their AD group membership.
বাস্তবায়ন সংক্রান্ত নোট: This solution correctly applies User Enrollment for privacy-preserving BYOD management. By targeting User Groups, the certificates follow the employee regardless of which device they enroll. The integration of role-based access control via RADIUS demonstrates advanced network design.

দৃশ্যপট বিশ্লেষণ

Q1. You have deployed the Root CA, SCEP, and Wi-Fi profiles to your Windows 10 devices. The certificates install successfully, but the Wi-Fi profile fails to apply, showing 'Error' in the Intune console. What is the most likely cause?

💡 ইঙ্গিত:Check how the profiles are assigned to Azure AD groups.

প্রস্তাবিত পদ্ধতি দেখুন

The most likely cause is a mismatch in group targeting. If the SCEP profile was assigned to a User Group, but the Wi-Fi profile was assigned to a Device Group, Intune cannot resolve the dependency between them. All three profiles (Root, SCEP, Wi-Fi) must be targeted to the exact same group type.

Q2. Your security team mandates that private keys must never be transmitted across the network, even if encrypted. Which certificate deployment method must you use in Intune, and what additional infrastructure server is required?

💡 ইঙ্গিত:Think about where the key pair is generated.

প্রস্তাবিত পদ্ধতি দেখুন

You must use SCEP (Simple Certificate Enrollment Protocol). Because SCEP instructs the endpoint device to generate the private key locally, it never traverses the network. This deployment requires a Network Device Enrollment Service (NDES) server to act as a bridge to the Certificate Authority.

Q3. A remote employee provisions a new laptop at home via Windows Autopilot. The Intune profiles deploy successfully, but the device fails to obtain the SCEP certificate. What infrastructure configuration is likely missing?

💡 ইঙ্গিত:How does the device reach the internal CA from the internet?

প্রস্তাবিত পদ্ধতি দেখুন

The NDES server has likely not been published to the internet. For remote devices to request certificates before arriving at the corporate office, the NDES URL must be externally accessible, ideally published securely via Azure AD Application Proxy.

মূল বিষয়সমূহ

  • 802.1X EAP-TLS is the standard for secure enterprise WiFi, requiring client certificates on all devices.
  • Microsoft Intune automates certificate deployment at scale using SCEP or PKCS profiles.
  • SCEP is highly recommended for WiFi as the private key is generated locally and never leaves the device.
  • Deployment requires a strict sequence: 1) Trusted Root, 2) SCEP Profile, 3) Wi-Fi Profile.
  • Group targeting (User vs. Device) must be identical across all three profiles to prevent dependency failures.
  • NDES servers should be published via Azure AD App Proxy to allow secure, remote certificate provisioning.
  • Strict CRL checking on the RADIUS server is mandatory to ensure revoked certificates cannot access the network.