Office 365 में प्रमाणीकरण (सिद्धांत का एक सा)

कहीं से शुरू करना हमेशा कठिन होता है। बहुत सोचने के बाद, मैंने अपने पहले लेख को हैबे पर इस विषय पर समर्पित करने का फैसला किया कि मैं वर्तमान में काम कर रहा हूं - सभी अभिव्यक्तियों में ऑफिस 365।

साइट में पहले से ही इस सेवा के कुछ घटकों का वर्णन करने वाले कई लेख हैं। उन्होंने ADFS का उपयोग करके प्राधिकरण स्थापित करने और सक्रिय निर्देशिका के साथ सिंक्रनाइज़ेशन के बारे में भी लिखा, लेकिन अभ्यास के अलावा, थोड़ा सिद्धांत चोट नहीं पहुंचाता है। बेशक, यह सब कुछ बताना असंभव है, और यह दिलचस्प नहीं है, लेकिन यह महत्वपूर्ण क्षणों के लायक है, मेरी राय में।

अपने स्वयं के अनुभव से, मैं कह सकता हूं कि Office 365 में प्रमाणीकरण एक जटिल विषय है, स्पष्ट सरलता और स्पष्टता, जो अक्सर सूक्ष्म बारीकियों को छुपाता है, जिसके ज्ञान से आप सिस्टम को बेहतर ढंग से तैनात कर सकते हैं और समस्या को स्थानीय बनाने के लिए आवश्यक समय को कम कर सकते हैं। ये वो बारीकियां हैं जिनके बारे में मैं आज बात करना चाहूंगा।


Office 365 में तीन प्रकार के पहचानकर्ता हैं जिनका उपयोग आपके उपयोगकर्ताओं को Exchange Online, Sharepoint ऑनलाइन, Lync ऑनलाइन और यहां तक ​​कि Office Pro Plus के साथ प्रमाणित करने के लिए किया जाता है।

1. Microsoft ऑनलाइन ID एक नियमित Windows Azure सक्रिय निर्देशिका खाता है। यह परिचित सक्रिय निर्देशिका का एक एनालॉग है, लेकिन Microsoft क्लाउड उत्पादों के साथ काम करने के लिए अनुकूलित है (उदाहरण के लिए, Office 365 के अलावा, इसका उपयोग MS Dynamics CRM ऑनलाइन के लिए भी किया जाता है)। उपयोगकर्ता CSV फ़ाइल के माध्यम से प्रशासन पोर्टल या बल्क में मैन्युअल रूप से बनाया जाता है।
2. Microsoft ऑनलाइन ID + DirSync एक ही "क्लाउड" उपयोगकर्ता हैं, लेकिन वे Microsoft AD सिंक्रोनाइज़ेशन उपयोगिता या शॉर्ट के लिए DirSync का उपयोग करके आपके AD से बनाए गए खातों की एक प्रति हैं। लगभग सभी मुख्य विशेषताओं को स्थानीय AD से स्थानांतरित किया जाता है, लेकिन उपयोगकर्ता पासवर्ड स्थानांतरित नहीं होते हैं। उपयोगकर्ता प्रबंधन आंशिक रूप से विज्ञापन के माध्यम से किया जाता है, आंशिक रूप से पोर्टल पर।
3. Federated ID + DirSync - सिस्टम के केंद्र में आपके विज्ञापन से खातों की प्रतिलिपि बनाने का एक ही सिद्धांत है, एकमात्र अंतर यह है कि सक्रिय निर्देशिका फेडरेशन सेवा 2.0 का उपयोग प्राधिकरण के लिए किया जाता है। उपयोगकर्ता प्रबंधन स्थानीय विज्ञापन के माध्यम से किया जाता है।

पहचानकर्ता प्रकार तुलना

Microsoft ऑनलाइन आईडी	Microsoft ऑनलाइन ID + DirSync	Federated ID + DirSync
दर्शक ऑन-प्रिमाइसेस सक्रिय निर्देशिका के बिना छोटे संगठन	दर्शक ऑन-प्रिमाइसेस सक्रिय निर्देशिका के साथ मध्यम आकार के संगठन	दर्शक ऑन-प्रिमाइसेस सक्रिय निर्देशिका के साथ बड़े संगठन
"के लिए" कोई स्थानीय सर्वर की आवश्यकता नहीं है	"के लिए" स्थानीय उपयोगकर्ता और समूह प्रबंधन सह-अस्तित्व के परिदृश्य	"के लिए" कॉर्पोरेट विवरण के साथ एकल साइन-ऑन टोपोलॉजी स्थानीय पहचान प्रबंधन पासवर्ड नीति स्थानीय रूप से नियंत्रित की जाती है दो-कारक प्रमाणीकरण संभव सह-अस्तित्व के परिदृश्य
"के खिलाफ" एकल साइन-ऑन टोपोलॉजी में असमर्थ दो-कारक प्रमाणीकरण संभव नहीं है विभिन्न पासवर्ड नीतियों के साथ विवरण के दो सेट क्लाउड आइडेंटिटी मैनेजमेंट	"के खिलाफ" एकल साइन-ऑन टोपोलॉजी का उपयोग करने में असमर्थ दो-कारक प्रमाणीकरण संभव नहीं है विभिन्न पासवर्ड नीतियों के साथ विवरण के दो सेट सर्वर परिनियोजन आवश्यक है	"के खिलाफ" उच्च उपलब्धता सर्वर परिनियोजन आवश्यक है

व्यवहार में, तीसरा विकल्प सबसे अधिक बार चुना जाता है क्योंकि यह उपयोगकर्ताओं को खातों की एकरूपता प्राप्त करने और उपयोगकर्ता प्रबंधन को सरल बनाने की अनुमति देता है, जबकि एक्सेस अधिकारों और पासवर्ड नीतियों पर पूर्ण नियंत्रण बनाए रखता है।

यदि पहले दो विकल्प तकनीकी रूप से काफी स्पष्ट हैं, तो जब ADFS का उपयोग करके प्रमाणीकरण को लागू करना मुश्किलें हैं।

प्रमाणीकरण तंत्र के बारे में बात करने से पहले, मैं वास्तविक जीवन की स्थिति दे दूंगा: 1000+ उपयोगकर्ताओं ने ADFS के माध्यम से प्रमाणीकरण के साथ Office 365 का उपयोग किया। एक नहीं, इतनी सुंदर सुबह, उपयोगकर्ताओं ने शिकायत करना शुरू कर दिया कि उनका आउटलुक मेल से कनेक्ट नहीं हो सकता है, लेकिन फिर भी आउटलुक वेब एक्सेस, SharePoint, या Lync तक पहुंच थी। विफलता का कारण सर्वर नीतियों में परिवर्तन था और परिणामस्वरूप, ADFS प्रॉक्सी सेवा क्रैश हो गई। इस समस्या को स्थानीय बनाने के लिए कुछ घंटे बिताए गए थे, जिसे ऑफिस 365 में प्रमाणीकरण के बारे में कुछ सरल बातों को समझकर बचाया जा सकता है।

इसलिए, Office 365 प्रमाणीकरण के लिए दो मुख्य तंत्रों (कभी-कभी प्रोफाइल कहा जाता है) का उपयोग करता है:

निष्क्रिय तंत्र - एक ब्राउज़र या एकल साइन-ऑन सेवा का उपयोग करके Office 365 सेवाओं में प्राधिकरण के लिए उपयोग किया जाता है।
इस तंत्र के संचालन के सिद्धांत को योजना द्वारा दर्शाया जा सकता है:

1. एक उपयोगकर्ता, जो ब्राउज़र या Lync क्लाइंट का उपयोग कर रहा है, SharePoint ऑनलाइन सेवा, Exchange OWA, या Lync सर्वर से जानकारी का अनुरोध करता है और प्रमाणीकरण प्लेटफ़ॉर्म पर प्राधिकरण से अनुरोध के लिए प्रतिक्रिया प्राप्त करता है।
2. अनुरोध प्राप्त करने के बाद, प्रमाणीकरण प्लेटफ़ॉर्म निर्धारित करता है कि एक फ़ेडरेटेड पहचानकर्ता का उपयोग किया जाता है और उसे एक उपयोगकर्ता स्रोत आईडी की आवश्यकता होती है जो स्थानीय सक्रिय निर्देशिका में उपयोगकर्ता की वैधता की पुष्टि करता है), जो ADFS सर्वर URL के अनुरोध को पुनर्निर्देशित करता है।
3. ADFS सर्वर स्थानीय AD में उपयोगकर्ता को प्रमाणित करता है और एक हस्ताक्षरित उपयोगकर्ता स्रोत आईडी जारी करता है।
4. एक तरह के "पासपोर्ट" के साथ सशस्त्र, उपयोगकर्ता एक बार फिर प्रमाणीकरण प्लेटफ़ॉर्म पर जाता है, जिससे इस बार "क्लाउड-आधारित पहचान" नेट आईडी प्राप्त होती है।
5. इस प्रमाणपत्र का उपयोग सेवाओं के साथ काम करने के लिए किया जाता है

सक्रिय तंत्र - का उपयोग आउटलुक का उपयोग करते हुए या ActiveSync, IMAP, POP3 प्रोटोकॉल का उपयोग करते हुए ईमेल सेवा में प्राधिकरण के लिए किया जाता है।
सर्किट पिछले संस्करण के समान है:

इस प्राधिकरण तंत्र के संचालन का सिद्धांत सभी चरणों को दोहराता है, एक महत्वपूर्ण विवरण के अपवाद के साथ - उपयोगकर्ता एक्सचेंज ऑनलाइन सेवा को स्पष्ट रूप से (स्वाभाविक रूप से HTTPS के माध्यम से संरक्षित) अपनी साख भेजता है। Exchange ऑनलाइन, प्रतिरूपण तंत्र का उपयोग करते हुए, ADFS सर्वर के साथ संचार और उपयोगकर्ता स्रोत आईडी प्राप्त करने सहित उपयोगकर्ता की ओर से सभी और कदम बढ़ाता है।

इसलिए, आप कई प्रमुख बिंदुओं की पहचान कर सकते हैं, जिन पर आपको ध्यान देना चाहिए - ये DNS, प्रमाण पत्र, प्रकाशन और दोष सहिष्णुता हैं।

डीएनएस
यदि समस्याएं उत्पन्न होती हैं, तो आपको हमेशा याद रखना चाहिए कि किसी विशेष सेवा के लिए अधिकृत करते समय उपयोगकर्ता किस DNS सर्वर का उपयोग कर रहा है।

प्रमाणपत्र
यदि आपके सभी उपयोगकर्ता कॉर्पोरेट नेटवर्क पर हैं और Office 365 के साथ काम करने के लिए केवल एक ब्राउज़र और Lync क्लाइंट का उपयोग करते हैं, तो आप इस आइटम के बारे में भूल सकते हैं और अपने CA के स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग करने के लिए स्वतंत्र महसूस कर सकते हैं। लेकिन जैसे ही आपके पास बाहरी उपयोगकर्ता हैं या आप कॉर्पोरेट मेल प्राप्त करने के लिए अपने पसंदीदा फोन को कॉन्फ़िगर करना चाहते हैं, आपको एक विश्वसनीय प्रमाणीकरण प्राधिकारी द्वारा जारी किए गए वैध प्रमाण पत्र की आवश्यकता होगी। एक सर्वोत्तम अभ्यास के रूप में, यहां तक ​​कि Office 365 में संक्रमण के चरण में, यह तुरंत खरीदने की योजना बना रहा है यदि वाइल्डकार्ड नहीं है, तो कम से कम एक SAN की जोड़ी के साथ एक साधारण, यह उम्मीद न करें कि आपके पास एक अद्वितीय स्थिति है और बाहरी उपयोगकर्ता कभी दिखाई नहीं देंगे।

दोष सहिष्णुता
ऐसा लगता है कि व्यवहार में किसी भी आईटी प्रणाली की सबसे स्पष्ट बात, सबसे दर्दनाक है। ADFS सर्वर रिसीबिलिटी सुनिश्चित करना एक महत्वपूर्ण और अक्सर अनदेखी कदम है जब फेडरेटेड प्रमाणीकरण की स्थापना की जाती है। ADFS की विश्वसनीयता में सुधार करना काफी आसान काम है, जिसमें किसी तृतीय-पक्ष NLB या एक मानक विंडोज लोड बैलेंसर (WNLNB) का उपयोग करना शामिल है। मैं समझता हूं कि मैं स्पष्ट चीजों के बारे में बात कर रहा हूं, लेकिन, दुर्भाग्य से, कई प्रशासक दोष सहिष्णुता के विषय पर ध्यान नहीं देते हैं, "एक दिन बाद" दूसरे सर्वर को देने की कोशिश कर रहे हैं। विवरण में जाने के बिना, व्यवहार में, ADFS संतुलन की कमी Office 365 के साथ समस्याओं का सबसे आम कारण है।

प्रकाशन
जैसे ही आपके Office 365 उपयोग मामले में Outlook या ActiveSync प्रकट होता है, प्रश्न ADFS को बाहर तक सही ढंग से प्रकाशित करने के लिए उठता है। इसके लिए कई संभावनाएं हैं:

• ADFS सर्वर एक्सपोज़ करना सबसे अच्छा और सबसे असुरक्षित विकल्प है जिसका उपयोग प्रशासक अच्छे जीवन से नहीं करते हैं।
• ADFS प्रॉक्सी को तैनात करें - आपको दो अतिरिक्त सर्वरों की आवश्यकता होगी और उनके बीच संतुलन को फिर से लोड करना होगा (फिर से एक तृतीय-पक्ष एनएलबी या डब्ल्यूएनएलबी का उपयोग करके)। फायदे के बीच, यह सेटअप और प्रशासन की आसानी को ध्यान देने योग्य है। वहाँ तोड़ने के लिए लगभग कुछ भी नहीं है।
• फ़ोरफ़्रंट TMG / UAG के माध्यम से प्रकाशित करना कठिन है और इसे बनाए रखना है, लेकिन बहुत अधिक कार्यात्मक है। यह आपको बाहरी उपयोगकर्ताओं के लिए ADFS कार्यक्षमता का विस्तार करने और अधिक जटिल Office 365 प्राधिकरण परिदृश्यों को कार्यान्वित करने की अनुमति देता है। कुछ प्रशासक TMG और ADFS प्रॉक्सी प्रकाशनों का उपयोग करने का प्रबंधन करते हैं, जो सिद्धांत रूप में संभव है, लेकिन कई कठिनाइयों और अस्थिरताओं का वहन करता है जो स्थानीयकरण के लिए मुश्किल है।
• बाहरी रिवर्स प्रॉक्सी - कोई भी समाधान / उपकरण हो सकता है जो SAML अनुरोधों / प्रतिक्रियाओं को संशोधित नहीं करता है, उदाहरण के लिए Citrix NetScaler या एक साधारण स्टनलाइन। रिवर्स प्रॉक्सी आवश्यकताएं यहां पाई जा सकती हैं।

Office 365 में प्रमाणीकरण एक ऐसा विषय है जिसके बारे में आप बहुत लंबे समय तक लिख सकते हैं। आज मैंने अपनी राय में, महत्वपूर्ण बिंदुओं को बताने की कोशिश की, जो अक्सर गलतफहमी और गलतियों का कारण बनते हैं। कुछ के लिए, यह लेख स्पष्ट होगा, लेकिन मुझे आशा है कि ऐसे लोग हैं जो समस्या के स्थानीयकरण और तंत्रिका कोशिकाओं के एक किलोग्राम के कई अप्रिय घंटे बचाएंगे।