Microsoft Entra ID में एंटरप्राइज़ पासकी डिप्लॉयमेंट: चुनौतियाँ और समाधान

1. परिचय: कर्मचारियों के लिए एंटरप्राइज़ पासकीज़ की परिचालन वास्तविकता#

पासकीज़ कार्यबल (workforce) में आ चुकी हैं। अब सवाल यह नहीं है कि "क्या यह तकनीक काम करती है?"। अब सवाल यह है कि "हम इसे बड़े पैमाने पर कैसे संचालित करें?"। घर्षण बिंदु (friction points) परिचालन स्तर (operational layer) पर स्थानांतरित हो गए हैं: प्रारंभिक एनरोलमेंट (बूटस्ट्रैपिंग) की "मुर्गी-और-अंडे" की समस्या, डिवाइस-बाउंड और सिंक की गई पासकीज़ के बीच का अंतर, क्रॉस-प्लेटफ़ॉर्म इंटरऑपरेबिलिटी और रिकवरी तंत्र जो पासवर्ड की असुरक्षा पर वापस नहीं लौटते हैं।

यह मार्गदर्शिका Microsoft Entra ID वातावरण में पासकीज़ डिप्लॉय करने की वास्तविक दुनिया की चुनौतियों को संबोधित करती है, जिसमें कॉन्फ़िगरेशन के नुकसान, परिचालन वर्कफ़्लो और रिकवरी रणनीतियाँ शामिल हैं। विशेष रूप से, हम निम्नलिखित प्रश्नों को संबोधित करने जा रहे हैं:

1. Entra ID में डिवाइस-बाउंड और सिंक की गई पासकीज़ में क्या अंतर है?
2. मैं बिना पासवर्ड वाले नए कर्मचारियों के लिए पासकीज़ को कैसे बूटस्ट्रैप करूँ?
3. जब उपयोगकर्ताओं को नया फोन मिलता है और वे अपने ऑथेंटिकेटर (authenticator) तक पहुंच खो देते हैं, तो वे कैसे रिकवर करते हैं?
4. कौन सी कॉन्फ़िगरेशन गलतियाँ पासकी एनरोलमेंट विफलताओं का कारण बनती हैं?
5. फ़िशिंग-प्रतिरोधी MFA की आवश्यकता होने पर मैं B2B मेहमानों (guests) को कैसे संभालूँ?
6. क्या मुझे हार्डवेयर सुरक्षा कुंजियों (YubiKeys) या मोबाइल पासकीज़ का उपयोग करना चाहिए?
7. पासकी डिप्लॉयमेंट में Windows के साथ-साथ macOS डिवाइस को कैसे संभालें?
8. फोन रिप्लेसमेंट से हेल्पडेस्क के ओवरलोड को रोकने के लिए कौन से सक्रिय उपाय हैं?

2. Microsoft Entra में पासकीज़ को समझना#

Entra में, "पासकीज़" = FIDO2/WebAuthn क्रेडेंशियल। पासवर्ड के बजाय, उपयोगकर्ता ऑथेंटिकेटर में संग्रहीत प्राइवेट कुंजी के अधिकार को साबित करता है। यह फ़िशिंग-प्रतिरोधी है क्योंकि WebAuthn क्रेडेंशियल को वास्तविक साइन-इन ओरिजिन से बांधता है (ताकि एक समान दिखने वाली फ़िशिंग साइट इसे रीप्ले न कर सके)। Microsoft का अवलोकन Passkeys (FIDO2) concepts documentation में देखें।

Entra प्रभावी रूप से पासकीज़ के दो "मोड" का समर्थन करता है जो अलग तरह से व्यवहार करते हैं।

2.1 Entra में डिवाइस-बाउंड पासकीज़#

ये पासकीज़ एक भौतिक डिवाइस से बंधी होती हैं (नॉन-सिंक करने योग्य)। प्राइवेट कुंजी एक विशिष्ट हार्डवेयर एलिमेंट (लैपटॉप पर TPM, YubiKey पर Secure Element) पर मौजूद होती है। यह निर्यात करने योग्य (non-exportable) नहीं है।

Entra में, डिवाइस-बाउंड की कहानी आमतौर पर इसमें अनुवादित होती है:

• Microsoft Authenticator पासकीज़
• Windows Hello या Windows Hello for Business (WHfB) पासकीज़ (जनवरी 2026 तक नॉन-सिंक)
• FIDO2 सुरक्षा कुंजियाँ (security keys) (YubiKeys जैसी हार्डवेयर कुंजियाँ)
• स्मार्टकार्ड (Smartcards)

डिवाइस-बाउंड पासकीज़ के लिए Microsoft का बेसलाइन सेटअप मार्गदर्शन यहाँ पाया जा सकता है: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

उपयोग के मामले (Use cases): उच्च-विशेषाधिकार प्राप्त एक्सेस, "ब्रेक-ग्लास" अकाउंट, साझा वर्कस्टेशन वातावरण। नुकसान: उच्च घर्षण (High friction)। डिवाइस खोने का मतलब क्रेडेंशियल खोना है। उच्च परिचालन लागत (उदा. YubiKeys भेजना)।

2.2 Entra में सिंक की गई पासकीज़#

ये वे पासकीज़ हैं जो प्रदाता इकोसिस्टम में संग्रहीत होती हैं और उपयोगकर्ता के डिवाइस (उदा. iCloud Keychain, Google Password Manager या थर्ड-पार्टी प्रदाताओं) में सिंक होती हैं। प्राइवेट कुंजी एन्क्रिप्टेड होती है और क्लाउड प्रदाता के सिंक फ़ैब्रिक में संग्रहीत होती है।

जनवरी 2026 तक, Entra में, सिंक की गई पासकीज़ को पूर्वावलोकन सुविधा (preview feature) के माध्यम से नियंत्रित किया जाता है: Synced passkeys (preview)। सिंक की गई पासकीज़ को सक्षम और नियंत्रित करने के लिए, Entra Passkey Profiles (preview) का उपयोग करता है।

विनियामक फिट (Regulatory fit): हाल ही में NIST SP 800-63B Supplement 1 द्वारा AAL2 आवश्यकताओं को पूरा करने के रूप में मान्य किया गया। यह एक बड़ी विनियामक जीत है जो प्रमाणित करती है कि सिंक की गई पासकीज़ सामान्य कार्यबल के उपयोग के लिए पर्याप्त "फ़िशिंग-प्रतिरोधी" हैं।

उपयोग के मामले: नॉलेज वर्कर्स, BYOD उपयोगकर्ता, कार्यकारी सुविधा। नुकसान: हार्डवेयर की तुलना में "कम" आश्वासन (assurance)। क्लाउड प्रदाता के अकाउंट रिकवरी फ़्लो की सुरक्षा पर निर्भरता।

यहाँ आपको Entra के समर्थित सिंक किए गए पासकी प्रदाताओं का अवलोकन मिलेगा:

उपयोगकर्ता के Security Info पेज में, सिंक की गई और डिवाइस-बाउंड पासकीज़ को स्पष्ट रूप से अलग किया जाता है। नीचे आप देख सकते हैं कि एक सिंक की गई पासकी (1Password से) और एक डिवाइस-बाउंड पासकी (YubiKey 5C NFC) कैसे दिखाई देती है:

2.3 विनियामक संरेखण: NIST AAL स्तर#

• AAL3 के लिए ऐतिहासिक रूप से हार्डवेयर-आधारित, डिवाइस-बाउंड ऑथेंटिकेटर (जैसे YubiKeys या Smart Cards) की आवश्यकता होती थी जो नॉन-एक्सपोर्टेबल प्राइवेट कुंजी का उपयोग करते हैं।
• AAL2 अब NIST मार्गदर्शन के अनुसार सिंक की गई पासकीज़ के साथ प्राप्त किया जा सकता है।
• बारीकी (Nuance): हालांकि सिंक की गई पासकीज़ (जैसे कि iCloud में) मानक उपयोगकर्ताओं के लिए उत्कृष्ट हैं, वे उच्च विशेषाधिकार स्तरों के लिए AAL3 "नॉन-एक्सपोर्टेबिलिटी" आवश्यकता को सख्ती से पूरा नहीं कर सकती हैं। इसलिए, एक सेगमेंटेड रणनीति आवश्यक है: एडमिन के लिए हार्डवेयर कुंजियाँ (AAL3), कार्यबल के लिए सिंक की गई पासकीज़ (AAL2)।

2.4 डिवाइस तैयारी आवश्यकताएँ#

यह सुनिश्चित करने के लिए कि डिवाइस फ़िशिंग-प्रतिरोधी पासवर्डलेस ऑथेंटिकेशन के लिए तैयार हैं, उन्हें इन न्यूनतम संस्करणों को चलाना होगा:

पुराने ऑपरेटिंग सिस्टम को फ़िशिंग-प्रतिरोधी पासवर्डलेस ऑथेंटिकेशन का समर्थन करने के लिए बाहरी ऑथेंटिकेटर (FIDO2 सुरक्षा कुंजियों) की आवश्यकता हो सकती है।

न्यूनतम-संस्करण आवश्यकताओं से परे, ब्राउज़र-साइड क्षमता समर्थन भी प्लेटफ़ॉर्म के अनुसार भिन्न होता है। Corbado Passkey Benchmark 2026 WebAuthn client capabilities analysis के अनुसार, Q1 2026 ब्राउज़र समर्थन Conditional Get और Hybrid Transport के लिए 97–100% पर है, लेकिन एक विशिष्ट उपभोक्ता ब्राउज़र मिश्रण पर Conditional Create के लिए केवल 83–92% है — एक बाधा जो Windows पर सबसे कठिन रूप से आती है क्योंकि Windows Hello एक Conditional Create पथ नहीं है, और विशेष रूप से Edge उसी डेटासेट में बहुत कम Conditional Create समर्थन की रिपोर्ट करता है। बेंचमार्क कार्यबल वातावरण के बजाय उपभोक्ता-सामना करने वाले B2C डिप्लॉयमेंट को कवर करता है, लेकिन वही अंतर्निहित ब्राउज़र/OS क्षमता सीमाएँ अभी भी Entra ID रोलआउट पर लागू होती हैं; एंटरप्राइज़-भारी Edge आबादी मिश्रित 83–92% Conditional Create रेंज से भौतिक रूप से नीचे आ सकती है।

2.5 उपयोगकर्ता पर्सोना क्रेडेंशियल सिफ़ारिशें#

Microsoft क्रेडेंशियल डिप्लॉयमेंट के लिए उपयोगकर्ता पर्सोना-आधारित दृष्टिकोण की सिफ़ारिश करता है। विभिन्न भूमिकाओं में अलग-अलग सुरक्षा आवश्यकताएँ और स्वीकार्य घर्षण स्तर होते हैं:

पोर्टेबल क्रेडेंशियल्स (विभिन्न डिवाइस में उपयोग किए जा सकते हैं):

लोकल क्रेडेंशियल्स (डिवाइस-विशिष्ट):

अंतिम लक्ष्य: अधिकांश उपयोगकर्ताओं के पास कम से कम एक पोर्टेबल क्रेडेंशियल और प्रत्येक कंप्यूटिंग डिवाइस पर लोकल क्रेडेंशियल्स होने चाहिए।

3. लाइव पासकी डिप्लॉयमेंट से अनुभव#

जिन संगठनों ने पासकीज़ को डिप्लॉय किया है, उनसे बात करते समय कुछ वास्तविक दुनिया के घर्षण बिंदुओं और पैटर्न को पहचाना जाता है।

3.1 परिचालन बदलाव#

"चुनौतियाँ तकनीकी स्टैक में नहीं बल्कि परिचालन परत (operational layer) में हैं।" यह पुष्टि करता है कि "पासकी पंजीकृत नहीं है (Passkey not registered)" त्रुटियाँ या व्यक्तिगत डिवाइस पर Windows Hello विकल्पों की अदृश्यता जैसी तकनीकी बाधाएँ अद्वितीय विसंगतियां नहीं हैं बल्कि इकोसिस्टम की वर्तमान परिपक्वता में अंतर्निहित प्रणालीगत घर्षण बिंदु हैं। एंटरप्राइज़ संचालन के लिए, कुंजी मॉनिटरिंग में अपेक्षित और अप्रत्याशित विफलताओं को अलग करना है। WebAuthn त्रुटियों को स्पष्ट रूप से बकेट करें और NotAllowedError, AbortError, और Credential Manager पासकी त्रुटियों को विशिष्ट संकेतों के रूप में ट्रैक करें। हमारी ऑथेंटिकेशन एनालिटिक्स प्लेबुक इन संकेतों को वर्गीकृत करने के लिए एक ढांचा प्रदान करती है, और पासकी एनालिटिक्स पासकी-विशिष्ट KPI जैसे सक्रियण और लॉगिन दरों को कवर करता है।

3.2 एनरोलमेंट: "बनाओ या बिगाड़ो (make-or-break)" क्षण#

एनरोलमेंट डिप्लॉयमेंट का सबसे कठिन चरण है, जिसके लिए महत्वपूर्ण परिवर्तन प्रबंधन की आवश्यकता होती है।

• पूर्व-पंजीकरण जटिलता: नए कर्मचारियों को ऑनबोर्ड करना जिनके पास कोई पूर्व क्रेडेंशियल नहीं है, प्राथमिक बाधा है। एडमिन-मध्यस्थता एनरोलमेंट पर निर्भरता एक असंबद्ध उपयोगकर्ता अनुभव बनाती है।
• प्लेटफ़ॉर्म विखंडन: ब्राउज़र, ऑपरेटिंग सिस्टम और पासवर्ड मैनेजर के स्वतंत्र पुनरावृत्तियों के कारण "चरणों के साथ उपयोगकर्ता की निराशा"। यह अस्थायी विसंगतियों की ओर ले जाता है जहाँ एक फ़्लो Chrome/Windows पर काम करता है लेकिन Safari/macOS पर विफल हो जाता है या कॉर्पोरेट डिवाइस पर सफल होने पर अप्रबंधित व्यक्तिगत डिवाइस पर विफल हो जाता है।

3.3 मानसिक मॉडल का अंतर (Mental model gap)#

"उपयोगकर्ताओं को क्रिप्टोग्राफी की आवश्यकता नहीं है, उन्हें एक मानसिक मॉडल (mental model) की आवश्यकता है"। शब्दावली भ्रम संज्ञानात्मक भार (cognitive load) पैदा करता है:

• पासकी (Passkey)
• सुरक्षा कुंजी (Security Key)
• हार्डवेयर कुंजी (Hardware Key)
• YubiKey
• पासवर्डलेस (passwordless)
• Windows Security
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• फ़ोन साइन-इन

गैर-तकनीकी-प्रेमी उपयोगकर्ताओं या यहाँ तक कि तकनीकी-प्रेमी उपयोगकर्ताओं के लिए, इन शर्तों के अंतर स्पष्ट नहीं हैं।

हम एंड-यूज़र संचार में "फ़िशिंग-प्रतिरोधी" या "कुंजी-युग्म (key-pair)" जैसे शब्दजाल से बचने की सलाह देते हैं। इसके बजाय, "अनलॉक" अवधारणा पर ध्यान केंद्रित करें: "एंटरप्राइज़ के सिस्टम को अनलॉक करने के लिए अपने चेहरे का उपयोग करें," ठीक उसी तरह जैसे वे अपना फोन अनलॉक करते हैं।

3.4 संचार सीमाएँ#

शुरुआत में मजबूत रूप से अपनाना सफलता के लिए महत्वपूर्ण है, लेकिन संचार केवल एक हद तक ही जा सकता है। आप उपयोगकर्ताओं से उनके ऑथेंटिकेशन विधियों की जाँच करने के लिए नियमित ईमेल नहीं भेज सकते हैं। सामान्य तौर पर, आप उपयोगकर्ता के व्यवहार के लिए अच्छी तरह से योजना नहीं बना सकते हैं। यह वास्तविकता केवल उपयोगकर्ता शिक्षा पर निर्भर रहने के बजाय सक्रिय तकनीकी उपायों की आवश्यकता को प्रेरित करती है।

4. Microsoft Entra ID कॉन्फ़िगरेशन डीप-डाइव#

एंटरप्राइज़ वातावरण में पासकीज़ को डिप्लॉय करने के लिए परस्पर निर्भर नीतियों को समझने और सेट करने की आवश्यकता होती है। पासकी केवल एक ऐसी सुविधा नहीं है जिसे आप आसानी से चालू कर सकते हैं, क्योंकि इसका हर कर्मचारी के दैनिक काम पर बहुत प्रभाव पड़ता है।

4.1 ऑथेंटिकेशन मेथड्स पॉलिसी#

विरासत MFA और SSPR पोर्टल पदावनत (deprecated) हैं। सभी FIDO2 कॉन्फ़िगरेशन एकीकृत Authentication Methods Policy ब्लेड में होने चाहिए।

• FIDO2 सुरक्षा कुंजी विधि: इसे सक्षम और लक्षित किया जाना चाहिए। सक्षमता के लिए "सभी उपयोगकर्ता" को लक्षित करने की अनुशंसा करें लेकिन सशर्त पहुँच (Conditional Access) के माध्यम से प्रवर्तन (enforcement) को नियंत्रित करें।
• कुंजी प्रतिबंध (AAGUIDs): प्रत्येक FIDO2 डिवाइस (उदा. YubiKey 5 NFC, iOS पर Microsoft Authenticator, Google Password Manager) में एक अद्वितीय ऑथेंटिकेटर अटेस्टेशन GUID (AAGUID) होता है। सर्वोत्तम अभ्यास के रूप में, उच्च-सुरक्षा वातावरण के लिए, केवल विशिष्ट, अनुमोदित AAGUIDs की अनुमति देने के लिए "Enforce Key Restrictions" सेटिंग का उपयोग करें। यह उपयोगकर्ताओं को सस्ते, असत्यापित "ग्रे मार्केट" सुरक्षा कुंजियों को पंजीकृत करने से रोकता है।

4.2 अटेस्टेशन: महत्वपूर्ण निर्णय बिंदु#

सबसे महत्वपूर्ण कॉन्फ़िगरेशन निर्णयों में से एक "अटेस्टेशन लागू करें (Enforce Attestation)" है।

• यह क्या करता है: ऑथेंटिकेटर को पंजीकरण के दौरान Entra ID को अपने मेक और मॉडल को क्रिप्टोग्राफिक रूप से साबित करने के लिए मजबूर करता है।
• टकराव: सिंक की गई पासकीज़ (सॉफ़्टवेयर प्रदाताओं जैसे iCloud Keychain, Bitwarden या Google Password Manager में संग्रहीत) आमतौर पर अटेस्टेशन का समर्थन नहीं करती हैं क्योंकि वे सॉफ़्टवेयर-आधारित और प्लेटफ़ॉर्म-एग्नोस्टिक हैं। वे हार्डवेयर-बैच प्रमाणपत्र के साथ चुनौती पर हस्ताक्षर नहीं कर सकते।
• ट्रेड-ऑफ़:
  • YES पर सेट करें: उच्च आश्वासन (AAL3) के लिए आवश्यक। यह सुनिश्चित करता है कि कुंजी हार्डवेयर-बाउंड है। सॉफ़्टवेयर-आधारित पासकी प्रदाताओं को ब्लॉक करता है।
  • NO पर सेट करें: सिंक की गई पासकीज़ की अनुमति देता है। आश्वासन थोड़ा कम करता है (AAL2)। सॉफ़्टवेयर-आधारित पासकी प्रदाताओं को सक्षम करता है।

यदि आपके पास उच्च-विशेषाधिकार प्राप्त एडमिन हैं जिन्हें हार्डवेयर कुंजियों की आवश्यकता है, तो आप वैश्विक "नो अटेस्टेशन" नीति लागू नहीं कर सकते। आपको Passkey Profiles (Preview) का उपयोग करना होगा:

• प्रोफ़ाइल A (एडमिन): अटेस्टेशन लागू करें = Yes
• प्रोफ़ाइल B (सामान्य कर्मचारी): अटेस्टेशन लागू करें = No

4.3 पासकी प्रोफ़ाइल (Passkey Profiles) की व्याख्या#

Passkey Profiles को परिभाषित करने के तंत्र के रूप में सोचें:

• "ये उपयोगकर्ता सिंक की गई पासकीज़ का उपयोग कर सकते हैं"
• "इन उपयोगकर्ताओं को केवल डिवाइस-बाउंड का उपयोग करना चाहिए"
• "अटेस्टेशन आवश्यक बनाम आवश्यक नहीं" (और इसलिए: सिंक की गई पासकीज़ की अनुमति बनाम बाहर रखा गया)
• "कुछ ऑथेंटिकेटर प्रकारों (AAGUID प्रतिबंधों) तक सीमित करें"

नीचे आप Microsoft Entra एडमिन सेंटर में Passkey (FIDO2) सेटिंग्स पेज देख सकते हैं जहाँ आप पासकी प्रोफ़ाइल कॉन्फ़िगर करते हैं:

पासकी प्रोफ़ाइल को संपादित करते समय, आप अटेस्टेशन प्रवर्तन, लक्ष्य प्रकार (डिवाइस-बाउंड, सिंक की गई या दोनों) और विशिष्ट AAGUID प्रतिबंधों को कॉन्फ़िगर कर सकते हैं:

4.4 कंडीशनल एक्सेस और ऑथेंटिकेशन स्ट्रेंथ्स#

प्रवर्तन (Enforcement) को Authentication Strengths का उपयोग करते हुए कंडीशनल एक्सेस (CA) नीतियों के माध्यम से नियंत्रित किया जा सकता है।

• फ़िशिंग-प्रतिरोधी MFA शक्ति: इस अंतर्निहित शक्ति के लिए FIDO2, Windows Hello for Business (WHfB) या सर्टिफ़िकेट-बेस्ड ऑथेंटिकेशन (CBA) की आवश्यकता होती है।
• लॉकआउट ट्रैप: यदि आप एक CA नीति बनाते हैं जिसमें "सभी क्लाउड ऐप्स" के लिए "फ़िशिंग-प्रतिरोधी MFA" की आवश्यकता होती है और इसे "सभी उपयोगकर्ताओं" पर लागू करते हैं, तो आप तुरंत उस हर उपयोगकर्ता को लॉक कर देंगे जिसने अभी तक पासकी पंजीकृत नहीं की है। वे पंजीकरण करने के लिए लॉग इन भी नहीं कर पाएंगे।
• "सुरक्षा जानकारी पंजीकृत करें (Register Security Info)" विरोधाभास: यह CA में एक विशिष्ट उपयोगकर्ता कार्रवाई है। यदि आपको Register Security Information कार्रवाई करने के लिए फ़िशिंग-प्रतिरोधी MFA की आवश्यकता है, तो आप एक गोलाकार निर्भरता (मुर्गी-और-अंडे) बनाते हैं। एक उपयोगकर्ता अपनी पहली पासकी पंजीकृत नहीं कर सकता क्योंकि उन्हें पंजीकरण पृष्ठ तक पहुँचने के लिए एक पासकी की आवश्यकता होती है।

यहाँ एक अवलोकन दिया गया है कि कौन से ऑथेंटिकेशन तरीके किन शक्ति आवश्यकताओं को पूरा करते हैं:

4.5 सिस्टम-पसंदीदा ऑथेंटिकेशन#

Entra ID की "सिस्टम-पसंदीदा मल्टीफैक्टर ऑथेंटिकेशन" सुविधा साइन-इन इंजन को उपयोगकर्ता को सबसे सुरक्षित पंजीकृत विधि के लिए संकेत देने के लिए मजबूर करती है।

यदि किसी उपयोगकर्ता के पास SMS और पासकी दोनों पंजीकृत हैं, तो सिस्टम डिफ़ॉल्ट रूप से पासकी पर चला जाएगा। यह कठिन प्रवर्तन (hard enforcement) के बिना पासकी अपनाने को जैविक रूप से प्रेरित करता है। एक बार जब वे क्रेडेंशियल पंजीकृत कर लेते हैं, तो यह अनिवार्य रूप से उपयोगकर्ता की सुरक्षा मुद्रा को स्वचालित रूप से "अपग्रेड" कर देता है।

नीचे आप पासकी साइन-इन अनुभव देख सकते हैं। उपयोगकर्ता को "चेहरा, फिंगरप्रिंट, पिन या सुरक्षा कुंजी" का उपयोग करने के लिए प्रेरित किया जाता है और वे ब्राउज़र एक्सटेंशन या सिस्टम क्रेडेंशियल मैनेजर से अपनी पासकी का चयन कर सकते हैं:

4.6 macOS विचार: प्लेटफ़ॉर्म SSO#

मिश्रित Windows/macOS वातावरण वाले संगठनों के लिए, macOS Platform SSO Windows Hello for Business के Apple समकक्ष प्रदान करता है। MDM समाधानों के साथ संयुक्त, आप प्राप्त कर सकते हैं:

• Mac के Secure Enclave से बंधे डिवाइस-बाउंड क्रेडेंशियल्स
• नेटिव ऐप्स और वेब ऐप्स पर SSO अनुभव
• फ़िशिंग-प्रतिरोधी ऑथेंटिकेशन जो AAL2/AAL3 आवश्यकताओं को पूरा करता है

नोट: macOS Platform SSO के लिए macOS 13+ और उचित MDM कॉन्फ़िगरेशन की आवश्यकता होती है। सेटअप Windows WHfB से काफी अलग है, इसलिए अलग डिप्लॉयमेंट ट्रैक के लिए योजना बनाएँ।

5. सामान्य गलत कॉन्फ़िगरेशन: क्यों "यह केवल Microsoft Authenticator के साथ काम करता है"#

यदि आपका लक्ष्य अप्रबंधित डिवाइस पर सिंक की गई पासकीज़ है, तो ये सबसे आम ब्लॉकर्स हैं:

5.1 सिंक की गई पासकीज़ सक्षम/लक्षित नहीं#

Entra में केवल सामान्य रूप से "FIDO2" को सक्षम करना पर्याप्त नहीं है। सिंक की गई पासकीज़ के लिए आपको आमतौर पर आवश्यकता होती है:

• पूर्वावलोकन सुविधा पथ जैसा कि Synced passkeys (preview) में वर्णित है
• Passkey Profiles का उपयोग करके एक प्रोफ़ाइल कॉन्फ़िगरेशन

यदि किसी समूह को उस प्रोफ़ाइल द्वारा लक्षित नहीं किया जाता है जो सिंक की गई पासकीज़ की अनुमति देती है, तो आपको "केवल डिवाइस-बाउंड" दुनिया में वापस खींच लिया जाएगा।

5.2 अटेस्टेशन लागू किया गया (सिंक की गई पासकीज़ को ब्लॉक करता है)#

सुरक्षा के प्रति जागरूक संगठनों में अधिकांश प्रश्नों का कारण यही है:

• Entra कुछ पासकी परिदृश्यों के लिए अटेस्टेशन की आवश्यकता कर सकता है (ऑथेंटिकेटर प्रकार/उत्पत्ति को मान्य करने में मदद करता है)
• सिंक की गई पासकीज़ Entra में अटेस्टेशन का समर्थन नहीं करती हैं, इसलिए यदि अटेस्टेशन लागू किया जाता है, तो सिंक की गई पासकीज़ पंजीकरण में विफल हो जाती हैं और आप केवल डिवाइस-बाउंड विकल्पों के साथ समाप्त हो जाएंगे

5.3 AAGUID अनुमति-सूची प्रदाताओं को ब्लॉक करती है#

Entra आपको यह प्रतिबंधित करने देता है कि किन ऑथेंटिकेटर की अनुमति है (अक्सर AAGUID अनुमति/ब्लॉक सूचियों के माध्यम से)। यदि आप केवल Microsoft Authenticator (या ऑथेंटिकेटर के एक संकीर्ण सेट) को अनुमति देते हैं, तो तृतीय-पक्ष सिंक किए गए प्रदाता परोक्ष रूप से अवरुद्ध हो सकते हैं। भ्रम वाला हिस्सा यह है कि स्थानीय ऑथेंटिकेशन (उदा. Touch ID, Face ID, Windows बायोमेट्रिक स्कैन) काम करता है लेकिन Entra लॉगिन पेज तब एक त्रुटि प्रदर्शित करता है।

5.4 कंडीशनल एक्सेस कुछ पासकी प्रकारों को मजबूर करता है#

भले ही पासकीज़ सक्षम हों, कंडीशनल एक्सेस उपयोगकर्ताओं को प्रभावी ढंग से विधियों के एक सबसेट (उदा. "केवल ऑथेंटिकेटर" या एक शक्ति कॉन्फ़िगरेशन जो इच्छित पासकी प्रोफ़ाइल की अनुमति नहीं देता है) में मजबूर कर सकता है। व्यवहार में यह "ऑथेंटिकेटर निर्भरता" बनाता है, भले ही योजना सिंक की गई पासकीज़ हो।

5.5 B2B अतिथि बनाम सदस्य खाते#

यदि बाहरी भागीदार संसाधन किरायेदार (resource tenant) में B2B अतिथि उपयोगकर्ता हैं, तो वे कहाँ/कैसे ऑथेंटिकेशन विधियों को पंजीकृत कर सकते हैं, इसके बारे में ज्ञात सीमाएँ हैं। यह अक्सर छिपा हुआ "यह काम क्यों नहीं करता" है जब इरादा "भागीदार हमारे किरायेदार में पासकीज़ का उपयोग करते हैं" होता है।

6. परिचालन चुनौतियाँ और समाधान#

6.1 बूटस्ट्रैपिंग विरोधाभास#

सबसे व्यापक समस्या ("एनरोलमेंट सबसे कठिन हिस्सा है") बूटस्ट्रैपिंग समस्या है: आप उस उपयोगकर्ता को सुरक्षित रूप से उच्च-आश्वासन क्रेडेंशियल कैसे जारी करते हैं जिसके पास वर्तमान में कोई क्रेडेंशियल नहीं है (या केवल कम-आश्वासन वाले हैं)?

6.1.1 अस्थायी एक्सेस पास (Temporary Access Pass - TAP)#

Temporary Access Pass (TAP) पासवर्डलेस ऑनबोर्डिंग के लिए एक वास्तुशिल्प दृष्टिकोण है।

• यह क्या है: एक समय-सीमित (उदा. 1 घंटा), उच्च-एन्ट्रॉपी पासकोड जिसे Entra ID "मजबूत ऑथेंटिकेशन" विधि के रूप में मानता है। यह पासवर्ड या मौजूदा MFA की आवश्यकता को बायपास करता है।
• वर्कफ़्लो:
  1. पहचान सत्यापन: नए कर्मचारी की पहचान सत्यापित की जाती है (उदा. मानव संसाधन प्रक्रिया या प्रबंधक सत्यापन के माध्यम से)।
  2. जारी करना: एक एडमिन (या स्वचालित लॉजिक ऐप) उपयोगकर्ता के लिए एक TAP उत्पन्न करता है।
  3. "मैजिक" लॉगिन: उपयोगकर्ता aka.ms/mysecurityinfo पर नेविगेट करता है। वे अपना उपयोगकर्ता नाम और TAP दर्ज करते हैं।
  4. पंजीकरण: चूँकि TAP "सशक्त प्रमाणन (Strong Auth)" आवश्यकता को पूरा करता है, इसलिए उपयोगकर्ता को Security Info ब्लेड तक पहुँचने की अनुमति दी जाती है। वे "Add Method" पर क्लिक करते हैं और अपनी पासकी पंजीकृत करते हैं।
  5. स्थिर स्थिति (Steady State): TAP समाप्त हो जाता है। उपयोगकर्ता के पास अब एक फ़िशिंग-प्रतिरोधी क्रेडेंशियल है। उन्होंने कभी पासवर्ड टाइप नहीं किया।

6.1.2 Graph API के माध्यम से स्वचालन#

बड़े संगठनों के लिए, मैन्युअल TAP जारी करना स्केलेबल नहीं है। सर्वोत्तम अभ्यास Microsoft Graph API के माध्यम से स्वचालित करना है।

• परिदृश्य: एक नए कर्मचारी को HR सिस्टम (Workday/SuccessFactors) में प्रोसेस किया जाता है।
• ट्रिगर: प्रावधान घटना (provisioning event) एक Azure Logic App को ट्रिगर करती है।
• कार्रवाई: Logic App Graph API POST /users/{id}/authentication/temporaryAccessPassMethods को कॉल करता है।
• वितरण: पहले दिन की पहुँच के लिए उपयोगकर्ता के नियुक्ति प्रबंधक (hiring manager) या व्यक्तिगत ईमेल (एन्क्रिप्टेड) पर TAP सुरक्षित रूप से वितरित किया जाता है।

6.1.3 उच्च-आश्वासन ऑनबोर्डिंग के लिए Microsoft Entra Verified ID#

दूरस्थ ऑनबोर्डिंग या उच्च पहचान आश्वासन की आवश्यकता वाले परिदृश्यों के लिए, Face Check के साथ Microsoft का Entra Verified ID एक पासवर्डलेस-प्रथम एनरोलमेंट पथ प्रदान करता है:

1. पहचान का प्रमाण: नया उपयोगकर्ता IDV भागीदार (सरकारी ID स्कैन) के माध्यम से पहचान सत्यापित करता है।
2. बायोमेट्रिक मिलान: Face Check Azure AI Vision का उपयोग करके ID दस्तावेज़ की तस्वीर से लाइव सेल्फ़ी की तुलना करता है। केवल एक मिलान विश्वास स्कोर साझा किया जाता है (कोई कच्चा बायोमेट्रिक डेटा नहीं)।
3. सत्यापित क्रेडेंशियल जारी किया गया: उपयोगकर्ता को एक Verified ID क्रेडेंशियल प्राप्त होता है।
4. TAP जारी करना: सफल सत्यापन पर, सिस्टम एक अस्थायी एक्सेस पास जारी करता है।
5. पासकी बूटस्ट्रैप: उपयोगकर्ता TAP का उपयोग करके अपनी पहली पासकी पंजीकृत करता है।

Face Check फ़्लो उपयोगकर्ताओं को तीन चरणों में मार्गदर्शन करता है: Verify (क्रेडेंशियल्स साझा करें), Confirm (फ़ेस स्कैन करें) और Review (मिलान परिणाम देखें):

यह फ़्लो पहले दिन से वास्तव में पासवर्डलेस अकाउंट सक्षम करता है। कभी कोई पासवर्ड नहीं बनाया जाता है।

6.2 फ़ोन रिप्लेसमेंट समस्या (छिपी हुई स्केल चुनौती)#

पासकी डिप्लॉयमेंट में हेल्पडेस्क कॉल का यह अक्सर सबसे बड़ा स्रोत होता है। बड़ी BYOD आबादी वाले संगठन (उदा. 10,000 से अधिक डिवाइस) उपयोगकर्ताओं को नए फ़ोन मिलने और ऑथेंटिकेशन विधियों को फिर से पंजीकृत करने की प्रक्रिया न जानने के कारण बड़ी संख्या में समर्थन कॉल देख सकते हैं।

जब आप मिश्रण में पासकीज़ पेश करते हैं, तो यह और भी महत्वपूर्ण हो जाता है क्योंकि:

• उपयोगकर्ता अपने नए फ़ोन में ऐप (जैसे Outlook) इंस्टॉल करते हैं
• ये ऐप ऑथेंटिकेशन के लिए संकेत देते हैं
• MFA प्रॉम्प्ट पुराने फ़ोन पर दिखाई देता है (जिसे वे पहले ही बदल चुके या मिटा चुके होंगे)
• उपयोगकर्ता लॉक आउट हो जाता है और हेल्पडेस्क को कॉल करता है

6.2.1 फ़ोन रिप्लेसमेंट के लिए परिदृश्य मैट्रिक्स#

लक्ष्य हेल्पडेस्क की भागीदारी को कम करते हुए, यथासंभव अधिक से अधिक मामलों को पहली दो पंक्तियों में स्थानांतरित करना है।

6.2.2 Intune एनरोलमेंट ट्रिक#

एक चतुर अंतर्दृष्टि: Intune एनरोलमेंट के लिए पासकी की आवश्यकता उपयोगकर्ताओं को कॉर्पोरेट ऐप एक्सेस करने से पहले - अपने नए फ़ोन पर Microsoft Authenticator सेटअप तुरंत पूरा करने के लिए मजबूर करती है।

• आज: Intune एनरोलमेंट के लिए MFA स्टेप-अप की आवश्यकता है। इसका मतलब है कि यदि आप नए फ़ोन पर लॉग इन करना चाहते हैं, तो आप वहाँ Outlook इंस्टॉल करते हैं। हालाँकि, MFA प्रॉम्प्ट पुराने फ़ोन पर जाता है।
• पासकी की आवश्यकता के साथ: एनरोलमेंट पूरा करने के लिए उपयोगकर्ताओं को पहले नए फ़ोन पर Microsoft Authenticator पासकीज़ सेट करनी होंगी। यह पुराने फ़ोन के जाने के महीनों बाद के बजाय जल्दी (फ़ोन स्विच के दिन) होता है।

यह रिकवरी को हल नहीं करता है, लेकिन यह टाइमलाइन को बदल देता है। उपयोगकर्ता अपने नए डिवाइस को तब पंजीकृत करते हैं जब उनके पास अभी भी पुराने डिवाइस तक पहुंच होती है।

6.3 हार्डवेयर सुरक्षा कुंजियाँ लॉजिस्टिक समस्याओं के साथ आती हैं#

हार्डवेयर कुंजियाँ (YubiKeys, आदि) कभी-कभी सार्वभौमिक समाधान के रूप में स्थित होती हैं। सिद्धांत रूप में वे हैं, हालांकि वास्तविक दुनिया अधिक चुनौतियां दिखाती है:

• लॉजिस्टिक बुरा सपना: जिन संगठनों ने पहले भौतिक टोकन (जैसे RSA SecurID) तैनात किए थे, उन्होंने अक्सर उन्हें खत्म करने की कोशिश में वर्षों बिताए। एक भौतिक टोकन कार्यक्रम को दूसरे के साथ बदलना आकर्षक नहीं है।
• ड्रॉप-शिपिंग: Yubico उपयोगकर्ताओं को सीधे कुंजियाँ ड्रॉप-शिप कर सकता है और उन्हें हर कुछ वर्षों में बैटरी बदलने की आवश्यकता नहीं होती है (SecurID के विपरीत)। लेकिन अगर कोई अपनी कुंजी भूल जाता है, तो वे साइन इन नहीं कर सकते (साझा डेस्कटॉप के लिए)।
• स्थानीय IT बोझ: भूली हुई कुंजियों के लिए स्थानीय पर्यवेक्षकों को डी फैक्टो IT सपोर्ट नहीं बनना चाहिए।
• लागत: हार्डवेयर कुंजियाँ प्रति-उपयोगकर्ता लागत जोड़ती हैं जो कर्मचारियों की संख्या के साथ बढ़ती है।

जब हार्डवेयर कुंजियाँ अर्थपूर्ण होती हैं:

• टियर 0 एडमिन: डोमेन एडमिन, "ब्रेक-ग्लास" अकाउंट
• साझा वर्कस्टेशन: कियॉस्क वातावरण, कारखाने के फर्श, फील्ड टैबलेट
• BYOD के बिना ठेकेदार: बाहरी उपयोगकर्ता जो व्यक्तिगत उपकरणों का उपयोग नहीं करेंगे

6.4 अप्रबंधित डिवाइस चुनौतियाँ#

कई उपयोगकर्ता शिकायत करते हैं कि वे व्यक्तिगत डिवाइस पर पासकी उपयोग के विकल्प नहीं देख सकते हैं। यह एक क्लासिक "अप्रबंधित डिवाइस (unmanaged device)" घर्षण बिंदु है।

6.4.1 "पासकी पंजीकृत नहीं है (Passkey not registered)" त्रुटि विश्लेषण#

उपयोगकर्ता व्यक्तिगत डिवाइस पर पासकीज़ जोड़ने में असमर्थ हो सकते हैं, जबकि यह कॉर्पोरेट डिवाइस पर काम करता है। यह पंजीकरण फ़्लो के साथ इंटरैक्ट करने वाली Intune Compliance Policies के कारण होने की संभावना है।

• तंत्र: Windows Hello for Business (WHfB) एक प्लेटफ़ॉर्म क्रेडेंशियल है। यह विशिष्ट डिवाइस के TPM (डिवाइस-बाउंड पासकी) से जुड़ा है।
• बाधा: WHfB को पंजीकृत करने के लिए, डिवाइस को आमतौर पर किरायेदार से जोड़ा (joined) (Entra Joined या Hybrid Joined) होना चाहिए। एक व्यक्तिगत डिवाइस जो केवल "पंजीकृत (Registered)" (Workplace Joined) है, उसमें Intune के माध्यम से नीति प्रतिबंध लागू हो सकते हैं जो WHfB कंटेनरों के प्रावधान को रोकते हैं यदि डिवाइस पूरी तरह से प्रबंधित या अनुरूप नहीं है। FIDO2 security key sign-in requirements देखें।
• "पासकी" विकल्प: व्यक्तिगत डिवाइस पर, उपयोगकर्ता को FIDO2 सुरक्षा कुंजी (रोमिंग) या क्रॉस-डिवाइस पासकी (अपने फोन पर) पंजीकृत करने का प्रयास करना चाहिए, न कि Windows Hello for Business (जब तक कि BYOD एनरोलमेंट पूरी तरह से समर्थित न हो)।
• Entra ID दृश्यता समस्या: यदि "Windows Hello" एक विकल्प के रूप में दिखाई नहीं देता है, तो डिवाइस ने पूर्वापेक्षा MDM एनरोलमेंट पूरा नहीं किया है।

6.4.2 क्रॉस-डिवाइस ऑथेंटिकेशन (CDA) विफलताएँ#

अप्रबंधित डिवाइस पर, उपयोगकर्ता अक्सर क्रॉस-डिवाइस ऑथेंटिकेशन (CDA) फ़्लो (अपने फ़ोन से पीसी पर QR कोड स्कैन करना) का प्रयास करते हैं।

• ब्लूटूथ निर्भरता: CDA के लिए पीसी और फ़ोन दोनों पर ब्लूटूथ सक्षम होना आवश्यक है। उन्हें पेयर करने की आवश्यकता नहीं है, लेकिन निकटता साबित करने के लिए ब्लूटूथ लो एनर्जी (BLE) हैंडशेक करना होगा। विवरण के लिए device-bound passkeys in Microsoft Authenticator की समीक्षा करें।
• कॉर्पोरेट नीति ब्लॉकर: यदि "सुरक्षा" के लिए BIOS या GPO के माध्यम से कॉर्पोरेट लैपटॉप पर ब्लूटूथ अक्षम किया गया है, तो आपने रोमिंग पासकीज़ के लिए प्राथमिक तंत्र को पहले ही तोड़ दिया है।
• Websocket ब्लॉकिंग: CDA फ़्लो cable.ua5v.com या cable.auth.com के लिए वेबसॉकेट कनेक्शन का उपयोग करता है। आक्रामक कॉर्पोरेट फ़ायरवॉल या Zscaler कॉन्फ़िगरेशन अक्सर इन डोमेन को ब्लॉक कर देते हैं, जिससे QR कोड स्कैन हैंग हो जाता है या चुपचाप विफल हो जाता है। Microsoft Authenticator passkey documentation देखें।

6.5 B2B और बाहरी पहचान#

उद्यमों के लिए एक और दर्द बिंदु बाहरी सलाहकारों (B2B मेहमानों) से निपटना है।

• समस्या: एक सलाहकार SharePoint साइट तक पहुँचने का प्रयास करता है। किरायेदार एक कंडीशनल एक्सेस नीति लागू करता है जिसमें "फ़िशिंग-प्रतिरोधी MFA" की आवश्यकता होती है।
• विफलता: सलाहकार संसाधन किरायेदार में FIDO2 कुंजी पंजीकृत करने का प्रयास करता है। यह विफल रहता है। Entra ID संसाधन किरायेदार में अतिथि उपयोगकर्ताओं को FIDO2 कुंजियाँ पंजीकृत करने का समर्थन नहीं करता है।
• फिक्स: क्रॉस-किरायेदार (Cross-Tenant) एक्सेस सेटिंग्स
  • तर्क: अतिथि को अपने किरायेदार में क्रेडेंशियल पंजीकृत करने के लिए मजबूर करने के बजाय, आपको उस क्रेडेंशियल पर भरोसा करना चाहिए जिसका वे अपने किरायेदार में उपयोग करते हैं।
  • कॉन्फ़िगरेशन: External Identities > Cross-tenant access settings पर जाएँ। भागीदार संगठन का चयन करें। Inbound Trust के तहत, "Trust multifactor authentication from Microsoft Entra tenants" की जाँच करें।
  • परिणाम: जब सलाहकार अपने होम किरायेदार में YubiKey का उपयोग करके लॉग इन करता है, तो आपके किरायेदार को एक दावा (claim) प्राप्त होता है जो कहता है "MFA संतुष्ट + फ़िशिंग प्रतिरोधी।" उपयोगकर्ता को कुछ भी पंजीकृत करने की आवश्यकता के बिना एक्सेस प्रदान किया जाता है। यह क्रेडेंशियल जीवनचक्र प्रबंधन को भागीदार को आउटसोर्स करता है, जिससे आपकी देयता और हेल्पडेस्क लोड कम हो जाता है।

7. रिकवरी रणनीतियाँ#

अक्सर रिकवरी के निर्णय अभी भी वास्तविक रोलआउट से पीछे रह जाते हैं। आपके संगठन की आवश्यकताओं के आधार पर कई रिकवरी विकल्प मौजूद हैं।

7.1 Verified ID के साथ सेल्फ-सर्विस अकाउंट रिकवरी (SSAR)#

Microsoft Entra ID का नया Self-Service Account Recovery (SSAR) फ़्लो (पूर्वावलोकन में) हेल्पडेस्क हस्तक्षेप के बिना उच्च-आश्वासन रिकवरी की अनुमति देता है।

1. ट्रिगर: उपयोगकर्ता साइन इन नहीं कर सकता। "Recover my account" चुनता है।
2. पहचान सत्यापन: उपयोगकर्ता को तृतीय-पक्ष पहचान सत्यापन (IDV) प्रदाता (उदा. Onfido, IDemia) पर रीडायरेक्ट किया जाता है।
3. दस्तावेज़ जाँच: उपयोगकर्ता अपने मोबाइल कैमरे का उपयोग करके अपने भौतिक ड्राइवर लाइसेंस, राष्ट्रीय ID या पासपोर्ट को स्कैन करता है।
4. लाइवनेस जाँच: उपयोगकर्ता एक सेल्फ़ी Face Check करता है। इसका मिलान ID दस्तावेज़ (और संभावित रूप से Entra ID में संग्रहीत फ़ोटो) से किया जाता है। मिलान Azure AI Vision Face APIs का उपयोग करता है और केवल एक विश्वास स्कोर साझा किया जाता है। कोई कच्चा बायोमेट्रिक डेटा एप्लिकेशन में नहीं जाता है।
5. बहाली (Restoration): सफलता पर, सिस्टम स्वचालित रूप से उपयोगकर्ता को एक अस्थायी एक्सेस पास (TAP) जारी करता है।
6. पुनः एनरोलमेंट: उपयोगकर्ता तुरंत एक नई पासकी पंजीकृत करने के लिए TAP का उपयोग करता है।

सिफ़ारिश: यह स्वचालित, बायोमेट्रिक-समर्थित रिकवरी पथ "हेल्पडेस्क को कॉल करें" से बेहतर है, जो सोशल इंजीनियरिंग (डीपफेक वॉयस हमले) के प्रति संवेदनशील है।

7.2 My Staff के साथ मैनेजर-असिस्टेड रिकवरी#

यदि आप सर्विस डेस्क लोड को कम करना चाहते हैं लेकिन पूर्ण सेल्फ-सर्विस सक्षम नहीं कर सकते हैं, तो Microsoft Entra में My Staff नामक एक नेटिव डेलीगेटेड एडमिनिस्ट्रेशन सुविधा शामिल है।

• यह कैसे काम करता है: "टीम मैनेजर्स" (Entra में प्रशासनिक इकाइयों के माध्यम से) को सीमित अनुमतियाँ सौंपें।
• फ़्लो: यदि कोई उपयोगकर्ता एक्सेस खो देता है, तो वे एक डेलीगेटेड स्थानीय एडमिन से संपर्क कर सकते हैं, जो समर्थित रिकवरी कार्यों के लिए My Staff पोर्टल का उपयोग कर सकता है जैसे कि पासवर्ड रीसेट करना या फोन नंबर अपडेट करना।
• यह क्यों मदद करता है: यह सामान्य खाता-पुनर्प्राप्ति कार्य को केंद्रीय हेल्प डेस्क से दूर स्थानांतरित कर देता है और समर्थन को गति देता है।

7.3 सेल्फ-सर्विस रिकवरी कियॉस्क (इंट्रानेट)#

चूँकि उपयोगकर्ताओं के पास अक्सर एक विश्वसनीय, WHfB-सुरक्षित लैपटॉप होता है, आप एक साधारण "ब्रेक ग्लास" इंट्रानेट पेज बना सकते हैं।

• बिल्ड: एक साधारण आंतरिक वेब ऐप जिसे WHfB साइन-इन (मजबूत ऑथेंटिकेशन) की आवश्यकता होती है।
• कार्रवाई: प्रमाणित होने के बाद, उपयोगकर्ता "I have a new phone" पर क्लिक करता है। ऐप Microsoft Graph API (बैकग्राउंड सर्विस) का उपयोग करके एक अल्पकालिक अस्थायी एक्सेस पास (TAP) उत्पन्न करता है और इसे स्क्रीन पर प्रदर्शित करता है।
• परिणाम: उपयोगकर्ता Microsoft Authenticator ऐप को बूटस्ट्रैप करने के लिए अपने नए फ़ोन में वह TAP टाइप करता है। शून्य हेल्पडेस्क भागीदारी।

बिना नीति को कमजोर किए "क्लियर ऑथेंटिकेशन मेथड्स" रीसेट को कम करने के लिए यह प्रमुख लीवर है। यदि आपके पास एक मजबूत लैपटॉप-एज-बूटस्ट्रैप तंत्र है, तो आपके संचार का बोझ काफी कम हो जाता है क्योंकि उपयोगकर्ता सही अनुक्रम को जाने बिना पुनर्प्राप्त कर सकते हैं।

8. एंटरप्राइज़ पासकी डिप्लॉयमेंट के लिए सिफ़ारिशें#

अपने रोलआउट को परिपक्वता चरणों (Maturity Stages) के आसपास संरचित करें। घर्षण को स्वीकार करें ("तकनीक तैयार है, संचालन कठिन है") और इन शमन को लागू करें।

8.1 तत्काल कार्रवाई ("फ़िक्स-इट" चरण)#

1. ब्लूटूथ और फ़ायरवॉल का ऑडिट करें: सुनिश्चित करें कि कॉर्पोरेट लैपटॉप ब्लूटूथ (निकटता जांच के लिए) की अनुमति देते हैं और क्रॉस-डिवाइस विफलताओं को ठीक करने के लिए FIDO/WebAuthn रिले डोमेन (\*.cable.auth.com) को व्हाइटलिस्ट करते हैं।
2. क्रॉस-किरायेदार ट्रस्ट सक्षम करें: अतिथि पासकी पंजीकृत करने का प्रयास करना बंद करें। B2B एक्सेस समस्याओं को तुरंत हल करने के लिए प्रमुख भागीदारों के लिए MFA के लिए इनबाउंड ट्रस्ट कॉन्फ़िगर करें।
3. ऑनबोर्डिंग के लिए TAP लागू करें: "मुर्गी-और-अंडे" पंजीकरण अवरोधक को हल करने के लिए सभी नए उपयोगकर्ता ऑनबोर्डिंग के लिए अस्थायी एक्सेस पास के उपयोग को अनिवार्य करें।

8.2 रणनीतिक निर्णय ("आर्किटेक्चर" चरण)#

1. "हाइब्रिड एश्योरेंस" मॉडल अपनाएं:
   • टियर 0 (एडमिन): अटेस्टेशन और कुंजी प्रतिबंध लागू करें। केवल YubiKeys/हार्डवेयर की अनुमति (AAL3)।
   • टियर 1 (कार्यबल): पासकी प्रोफ़ाइल (Passkey Profiles) के माध्यम से अटेस्टेशन प्रवर्तन को अक्षम करें। घर्षण और लागत को कम करने के लिए सिंक की गई पासकीज़ की अनुमति दें (AAL2)।
2. macOS के लिए योजना: Windows WHfB के समानांतर ट्रैक के रूप में अपने MDM के साथ Platform SSO डिप्लॉय करें।

8.3 भविष्य-प्रूफिंग ("ऑप्टिमाइज़ेशन" चरण)#

1. SSAR के लिए योजना: हेल्पडेस्क को सोशल इंजीनियरिंग वेक्टर के रूप में खत्म करने के लिए Verified ID के साथ सेल्फ-सर्विस अकाउंट रिकवरी के लिए एक पायलट शुरू करें।
2. सिस्टम-पसंदीदा ऑथेंटिकेशन: उपयोगकर्ताओं को एक पासकी पंजीकृत करते ही स्वचालित रूप से "अपग्रेड" करने के लिए इस नीति को सक्षम करें, बिना किसी सख्त जनादेश के अपनाने को बढ़ावा दें।
3. रिकवरी विकल्प डिप्लॉय करें: My Staff और/या सेल्फ-सर्विस रिकवरी कियॉस्क के माध्यम से मैनेजर-असिस्टेड TAP लागू करें।
4. Intune पासकी आवश्यकता: नए डिवाइस पर शीघ्र पंजीकरण को बाध्य करने के लिए Intune एनरोलमेंट के लिए पासकी की आवश्यकता पर विचार करें।

8.4 समस्या निवारण मैट्रिक्स#

9. Phishing-Resistant Passwordless Workbook के साथ डिप्लॉयमेंट की निगरानी#

Microsoft ने एक Phishing-Resistant Passwordless Workbook जारी की है जिसका उपयोग Azure Monitor में लॉग वाले संगठन रोलआउट प्रगति को ट्रैक करने के लिए कर सकते हैं। इसे Entra एडमिन सेंटर के माध्यम से Monitoring > Workbooks के तहत एक्सेस करें:

कार्यपुस्तिका (workbook) में दो प्राथमिक खंड हैं:

9.1 एनरोलमेंट तैयारी चरण#

साइन-इन लॉग का विश्लेषण करने और यह निर्धारित करने के लिए कि कौन से उपयोगकर्ता पंजीकरण के लिए तैयार हैं बनाम किन उपयोगकर्ताओं को ब्लॉक किया जा सकता है, इस टैब का उपयोग करें। आप OS प्लेटफ़ॉर्म (Windows, macOS, iOS, Android) और क्रेडेंशियल प्रकार (Authenticator App Passkey, FIDO2 Security Key, Certificate-Based Authentication) द्वारा फ़िल्टर कर सकते हैं:

कार्यपुस्तिका दिखाती है:

• पंजीकरण के लिए तैयार उपयोगकर्ता/डिवाइस जोड़े (User/Device Pairs Ready for Enrollment): वे उपयोगकर्ता जो चयनित क्रेडेंशियल प्रकार को पंजीकृत कर सकते हैं
• तैयार नहीं उपयोगकर्ता/डिवाइस जोड़े (User/Device Pairs Not Ready): वे उपयोगकर्ता जिन्हें पंजीकरण की समस्या हो सकती है (उदा. पुराने OS संस्करण)

आप उन उपयोगकर्ताओं की सूची निर्यात कर सकते हैं जिन्हें उपचारात्मक कार्रवाइयों (उदा. OS अपग्रेड, डिवाइस रिप्लेसमेंट या वैकल्पिक क्रेडेंशियल विकल्प) की आवश्यकता है।

9.2 प्रवर्तन तैयारी चरण (Enforcement Readiness Phase)#

एक बार उपयोगकर्ता केवल-फ़िशिंग-प्रतिरोधी ऑथेंटिकेशन के लिए तैयार हो जाएं, तो प्रवर्तन तैयारी टैब का उपयोग करें। सबसे पहले, एक रिपोर्ट-ओनली (Report-Only) कंडीशनल एक्सेस नीति बनाएं जिसके लिए फ़िशिंग-प्रतिरोधी MFA की आवश्यकता होती है। यह इस डेटा के साथ साइन-इन लॉग भरता है कि प्रवर्तन सक्रिय होने पर पहुँच अवरुद्ध हो जाती या नहीं।

डैशबोर्ड दिखाता है:

• कुल उपयोगकर्ता दायरे में
• रिपोर्ट ओनली सफलता (Report Only Success) - उपयोगकर्ता जो प्रवर्तन पास करेंगे
• नीति संतुष्ट नहीं (Policy Not Satisfied) - उपयोगकर्ता जिन्हें ब्लॉक किया जाएगा (इनकी जांच करें!)
• डिवाइस स्थिति, डिवाइस प्लेटफ़ॉर्म और क्लाइंट ऐप ब्रेकडाउन

यह जांचने के लिए कि कुछ उपयोगकर्ताओं को ब्लॉक क्यों किया जाएगा, Further Data Analysis टैब का उपयोग करें। यह डेटा प्रवर्तन सक्षम करने से पहले उपयोगकर्ताओं को उपचारात्मक लक्षित करने में आपकी मदद करता है।

9.3 हेल्प डेस्क मॉनिटरिंग के साथ वेव-आधारित रोलआउट#

Microsoft लचीली तिथि सीमा के साथ तरंगों (waves) में डिप्लॉयमेंट निष्पादित करने की अनुशंसा करता है। सिग्नल के रूप में हेल्प डेस्क टिकट की मात्रा की निगरानी करें:

• टिकट की मात्रा बढ़ रही है: डिप्लॉयमेंट, संचार और प्रवर्तन कार्यों को धीमा करें
• टिकट की मात्रा कम हो रही है: गतिविधियों को वापस बढ़ाएँ

प्रत्येक लहर के लिए Microsoft Entra ID सुरक्षा समूह बनाएं और अपनी नीतियों में समूहों को वृद्धिशील रूप से जोड़ें। यह सहायता टीमों को भारी पड़ने से रोकता है।

10. सिंक की गई पासकी पायलट चेकलिस्ट#

यदि लक्ष्य Microsoft Authenticator निर्भरता के बिना सिंक की गई पासकीज़ है, तो इस पायलट मुद्रा का पालन करें:

1. सिंक की गई पासकीज़ सक्षम करें (पूर्वावलोकन) Synced passkeys (preview) का पालन करें।

2. पासकी प्रोफ़ाइल (पूर्वावलोकन) का उपयोग करें और पायलट समूह को लक्षित करें एक प्रोफ़ाइल बनाएँ/असाइन करें जो Passkey Profiles में वर्णित सिंक की गई पासकीज़ की अनुमति देता है।

3. अटेस्टेशन लागू न करें (कम से कम पायलट समूह के लिए) अटेस्टेशन लागू करना Passkeys (FIDO2) concepts documentation के अनुसार सिंक की गई पासकीज़ को बाहर करता है।

4. शुरू में सख्त AAGUID अनुमति-सूचियों से बचें फ़्लो की पुष्टि करने के लिए अनुमेय रूप से शुरू करें, फिर एक बार जब आप जान लें कि आप किन प्रदाताओं को अनुमति देना चाहते हैं तो प्रतिबंध कड़े कर दें। Enable passkeys (FIDO2) देखें।

5. पुष्टि करें कि कंडीशनल एक्सेस Microsoft Authenticator को बाध्य नहीं करता है सुनिश्चित करें कि CA/auth शक्तियाँ अभी भी आपके इच्छित पासकी प्रोफ़ाइल की अनुमति देती हैं (अन्यथा यह Microsoft Authenticator निर्भरता जैसा दिखता है)।

6. पहचान मॉडल (सदस्य बनाम अतिथि) को मान्य करें यदि उपयोगकर्ता अतिथि हैं, तो प्रोफ़ाइल ट्यून करने में समय बिताने से पहले अपने किरायेदार मॉडल में अपेक्षित समर्थन क्षमता की पुष्टि करें।

11. निष्कर्ष#

एंटरप्राइज़ पासकी डिप्लॉयमेंट परिचालन रूप से जटिल है, लेकिन आगे का रास्ता अच्छी तरह से परिभाषित है। ऊपर उठाए गए मुख्य परिचालन प्रश्नों के अनुरूप यहाँ प्रमुख उत्तर दिए गए हैं:

1. डिवाइस-बाउंड बनाम सिंक की गई पासकीज़: डिवाइस-बाउंड क्रेडेंशियल्स (उदा. Microsoft Authenticator, Windows Hello, YubiKeys, स्मार्टकार्ड) कड़ाई से एक डिवाइस से बंधे होते हैं और AAL3 को संतुष्ट करते हैं। सिंक की गई पासकीज़ (उदा. iCloud Keychain, Google Password Manager) डिवाइसों में काम करती हैं और AAL2 को पूरा करती हैं। अधिकांश संगठनों को दोनों की आवश्यकता होती है: एडमिन (AAL3) के लिए हार्डवेयर ऑथेंटिकेटर और व्यापक कार्यबल (AAL2) के लिए सिंक की गई पासकीज़।

2. नए कर्मचारियों की बूटस्ट्रैपिंग: ऑनबोर्डिंग में मुर्गी-और-अंडे की समस्या को हल करने के लिए अस्थायी एक्सेस पास (TAP) का उपयोग करें। बड़े पैमाने पर डिप्लॉयमेंट के लिए, इसे Graph API के माध्यम से स्वचालित करें। उच्च-आश्वासन उपयोग के मामलों के लिए, Entra Verified ID और Face Check के साथ ऑनबोर्डिंग को पूरक करें।

3. फ़ोन रिप्लेसमेंट रिकवरी: एकाधिक रिकवरी विधियाँ प्रदान करें: सेल्फ-सर्विस रिकवरी कियॉस्क (बूटस्ट्रैप डिवाइस के रूप में लैपटॉप का उपयोग करें), My Staff के माध्यम से मैनेजर-असिस्टेड TAP और एज केस के लिए Verified ID के साथ SSAR (सेल्फ-सर्विस अकाउंट रिकवरी)।

4. कॉन्फ़िगरेशन गलतियाँ: सबसे लगातार गलत कदमों में वैश्विक स्तर पर अटेस्टेशन लागू करना, सिंक की गई पासकीज़ के लिए पूर्वावलोकन सुविधाएँ सक्षम न करना, अत्यधिक सख्त AAGUID अनुमति-सूचियाँ और कंडीशनल एक्सेस (CA) नीतियां शामिल हैं जो गोलाकार निर्भरता (circular dependencies) बनाती हैं।

5. B2B मेहमान: अपने किरायेदार में B2B मेहमानों के लिए सीधे पासकीज़ पंजीकृत करने से बचें। इसके बजाय, अतिथि के होम किरायेदार से क्रेडेंशियल्स को मान्य करने के लिए क्रॉस-किरायेदार एक्सेस ट्रस्ट सक्षम करें।

6. हार्डवेयर कुंजियाँ बनाम मोबाइल पासकीज़: कुछ उच्च-सुरक्षा भूमिकाओं (एडमिन, साझा वर्कस्टेशन) के लिए हार्डवेयर सुरक्षा कुंजियाँ आवश्यक हैं, लेकिन बड़े पैमाने पर रसद बाधाएँ प्रस्तुत करती हैं। कार्यबल के लिए मोबाइल पासकीज़ आमतौर पर अधिक व्यावहारिक होती हैं।

7. Windows के साथ macOS: Windows डिप्लॉयमेंट के समानांतर macOS पर पासकी समर्थन को सक्षम करने के लिए JAMF/MDM के साथ Platform SSO का उपयोग करें। प्लेटफ़ॉर्म-विशिष्ट वर्कफ़्लो के लिए योजना बनाएँ।

8. सक्रिय उपाय: निष्क्रिय डिवाइस की पहचान करने के लिए Intune का उपयोग करें और लॉकआउट होने से पहले उपयोगकर्ताओं को सुधार के लिए प्रेरित करें। शीघ्र अपनाने को बढ़ावा देने के लिए Intune एनरोलमेंट के लिए पासकी पंजीकरण को पूर्वापेक्षा बनाने पर विचार करें। बूटस्ट्रैप डिवाइस के रूप में लैपटॉप का उपयोग करके एक सेल्फ-सर्विस रिकवरी वर्कफ़्लो बनाएँ।

तकनीक तैयार है। मुख्य चुनौती परिचालन निष्पादन है। रिकवरी योजना पहले दिन से ही अभिन्न होनी चाहिए, बाद में विचार करने वाली बात नहीं। एक बार इन्फ्रास्ट्रक्चर ठोस हो जाने पर, पासकी लॉगिन अपनाने के अनुकूलन पर ध्यान केंद्रित करें ताकि यह सुनिश्चित हो सके कि पासकीज़ आपके कार्यबल में प्राथमिक ऑथेंटिकेशन विधि बन जाएं।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Passkey Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

अक्सर पूछे जाने वाले प्रश्न (Frequently Asked Questions)#

कंडीशनल एक्सेस में फ़िशिंग-प्रतिरोधी MFA को सक्षम करने से मेरे सभी उपयोगकर्ता क्यों लॉक हो जाते हैं?#

सभी क्लाउड ऐप्स के लिए फ़िशिंग-प्रतिरोधी MFA की आवश्यकता वाली कंडीशनल एक्सेस नीति बनाने से तुरंत कोई भी उपयोगकर्ता अवरुद्ध हो जाता है जिसने अभी तक पासकी पंजीकृत नहीं की है, जिसमें Security Info पंजीकरण पृष्ठ तक पहुँच को अवरुद्ध करना भी शामिल है। इस गोलाकार निर्भरता (circular dependency), जिसे 'Register Security Info' विरोधाभास कहा जाता है, का अर्थ है कि आपको प्रवर्तन सक्षम करने से पहले प्रभावित उपयोगकर्ताओं को एक अस्थायी एक्सेस पास जारी करना होगा ताकि वे प्रारंभिक पंजीकरण पूरा कर सकें।

जब मेरे किरायेदार को फ़िशिंग-प्रतिरोधी MFA की आवश्यकता होती है, तो मैं B2B अतिथि उपयोगकर्ताओं को कैसे संभालूँ?#

Entra ID संसाधन किरायेदार में अतिथि उपयोगकर्ताओं को FIDO2 कुंजियाँ पंजीकृत करने का समर्थन नहीं करता है, इसलिए मेहमानों के लिए पासकी पंजीकरण लागू करने का प्रयास विफल हो जाएगा। सही सुधार अतिथि के होम किरायेदार से MFA दावों पर भरोसा करने के लिए External Identities के तहत Cross-Tenant Access Settings को कॉन्फ़िगर करना है, जिसका अर्थ है कि उनके अपने संगठन में उपयोग की जाने वाली YubiKey आपके किरायेदार में बिना किसी पंजीकरण के आपकी फ़िशिंग-प्रतिरोधी MFA आवश्यकता को पूरा करती है।

पासकी के साथ साइन इन करते समय क्रॉस-डिवाइस QR कोड ऑथेंटिकेशन चुपचाप विफल होने का क्या कारण है?#

क्रॉस-डिवाइस ऑथेंटिकेशन को BLE निकटता हैंडशेक को पूरा करने के लिए पीसी और फोन दोनों पर ब्लूटूथ सक्षम करने की आवश्यकता होती है, इसलिए ब्लूटूथ को अक्षम करने वाली कोई भी कॉर्पोरेट नीति प्रवाह को पूरी तरह से तोड़ देगी। प्रवाह cable.auth.com से WebSocket कनेक्शन का भी उपयोग करता है, जिसे फ़ायरवॉल या Zscaler कॉन्फ़िगरेशन अक्सर अवरुद्ध करते हैं, जिससे QR कोड स्कैन बिना किसी स्पष्ट त्रुटि संदेश के हैंग या विफल हो जाता है।

मैं इसे चालू करने से पहले यह कैसे मॉनिटर करूं कि कौन से कर्मचारी फ़िशिंग-प्रतिरोधी MFA प्रवर्तन के लिए तैयार हैं?#

Entra एडमिन सेंटर के माध्यम से Monitoring > Workbooks के तहत सुलभ Microsoft की Phishing-Resistant Passwordless Workbook, एक एनरोलमेंट तैयारी दृश्य प्रदान करती है जो दिखाती है कि कौन से उपयोगकर्ता/डिवाइस जोड़े प्लेटफ़ॉर्म और क्रेडेंशियल प्रकार द्वारा पंजीकृत हो सकते हैं। प्रवर्तन तैयारी के लिए, फ़िशिंग-प्रतिरोधी MFA की आवश्यकता वाली एक रिपोर्ट-ओनली कंडीशनल एक्सेस नीति बनाएं ताकि साइन-इन लॉग यह प्रकट करें कि लाइव प्रवर्तन सक्रिय करने से पहले किन उपयोगकर्ताओं को अवरुद्ध किया जाएगा।

उन कर्मचारियों के लिए सबसे अच्छी रिकवरी रणनीति क्या है जिन्हें नया फ़ोन मिलता है और वे अपनी पासकी तक पहुँच खो देते हैं?#

अनुशंसित दृष्टिकोण स्तरित (layered) है: एक WHfB-सुरक्षित लैपटॉप का उपयोग करने वाला सेल्फ-सर्विस रिकवरी कियॉस्क Graph API के माध्यम से एक अस्थायी एक्सेस पास उत्पन्न करता है और हेल्पडेस्क भागीदारी के बिना अधिकांश मामलों को कवर करता है। लैपटॉप के बिना उपयोगकर्ताओं के लिए, My Staff पोर्टल के माध्यम से मैनेजर-असिस्टेड TAP प्रत्यक्ष प्रबंधकों को रिकवरी सौंपता है, और Entra Verified ID बायोमेट्रिक Face Check के साथ सेल्फ-सर्विस अकाउंट रिकवरी पूर्ण पहचान पुनः सत्यापन की आवश्यकता वाले एज मामलों को संभालती है।

आगे की पढ़ाई (Further reading)#

एंटरप्राइज़ FIDO2/पासकी डिप्लॉयमेंट में डीप-डाइव के लिए, Merill Fernando और Jan Bakker जैसे विशेषज्ञों का अनुसरण करें जो नियमित रूप से Microsoft Entra ऑथेंटिकेशन पर व्यावहारिक मार्गदर्शन प्रकाशित करते हैं।