वैकल्पिक ADFS 2.0 पोर्ट को कॉन्फ़िगर करने के लिए क्वेस्ट

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

मैं तुरंत ही कहूंगा कि यहाँ कुछ भी सरल नहीं है (हल करने की प्रक्रिया में मैंने महसूस किया कि मैं कई मुद्दों में "तैरता हूँ"), लेकिन फिर भी, मुझे यह समाधान Google में नहीं मिला। यह सब इस तथ्य से शुरू हुआ कि हमारी कंपनी ने Lync ऑनलाइन को लागू करने का निर्णय लिया। मैं कार्यान्वयन प्रक्रिया का वर्णन नहीं करूंगा, पहले से ही एक विवरण है। कार्यान्वयन सफल रहा, लेकिन कई समस्याएं थीं।

पहली समस्या

समस्या ADFS सर्वर पर प्रमाण पत्र के साथ थी - यह हमारे आंतरिक सीए द्वारा जारी किया गया था। डोमेन में कंप्यूटरों के लिए, यह समस्या का कारण नहीं था, क्योंकि समूह नीतियों के माध्यम से हमारे सीए का प्रमाण पत्र विश्वसनीय रूट प्रमाणीकरण अधिकारियों में स्थापित किया गया था। उन कंप्यूटरों के लिए जिन्हें डोमेन में दर्ज नहीं किया गया है, समस्या को मैनुअल जोड़कर हल किया गया था, जो पहले से ही बहुत सुविधाजनक नहीं था। इसके अलावा, मुझे ADFS के प्रमाणपत्र के लिए HTTP CDP को जोड़कर इन कंप्यूटरों के लिए CA को कॉन्फ़िगर करना पड़ा। लेकिन समस्या मोबाइल उपकरणों के साथ अपनी पूरी क्षमता तक बढ़ गई है, क्योंकि विश्वसनीय रूट प्रमाणपत्र अधिकारियों के लिए एक प्रमाण पत्र जोड़ना उनके लिए तुच्छ नहीं है।

गो डेडी से मौजूदा प्रमाण पत्र को * .contoso.ru नाम से रखने का निर्णय लिया गया, यह केवल शर्मनाक था कि मेरा ट्रस्ट डोमेन corp.contoso.ru था, और ADFS सर्वर का नाम fs.corp.contoso.ru था, और यह प्रमाणपत्र अमान्य निकला। । लेकिन यह पता चला कि प्रमाण पत्र और सर्वर नाम की जगह कोई समस्या नहीं थी, जिसके बाद सर्वर को fs.contoso.ru कहा जाने लगा, और प्रमाणपत्र समस्याओं का समाधान किया गया।

दूसरी समस्या

दरअसल, यह लेख लिखने का कारण था। ADFS के कॉर्पोरेट नेटवर्क के बाहर काम करने के लिए, हमने ADFS प्रॉक्सी को लागू करने का निर्णय लिया। इसके संचालन के लिए, ADFS प्रॉक्सी सर्वर पर कॉर्पोरेट नेटवर्क में पोर्ट 443 को अग्रेषित करना आवश्यक है। लेकिन 443 बंदरगाह कम आपूर्ति में थे, वे सेवाओं के एक समूह के साथ व्यस्त हैं।

और फिर मुझे याद आया कि कार्यान्वयन प्रक्रिया के दौरान मैंने कहीं एक लेख देखा जिसमें एक वैकल्पिक बंदरगाह पर ADFS के विन्यास का वर्णन किया गया था। मिला , कॉन्फ़िगर करना शुरू किया - काम नहीं करता है। सेवाओं, सर्वर, पूल, आईआईएस के रिबूट के साथ खेला जाता है - काम नहीं करता है, चरण 3 में बन्द हो जाता है, AD FS 2.0 प्रॉक्सी कॉन्फ़िगरेशन विज़ार्ड ADFS सर्वर से कनेक्ट नहीं हो सकता है और विश्वास स्थापित नहीं कर सकता है। मुझे इस तरह का एक लेख भी मिला, लेकिन कुछ गलत वैकल्पिक पोर्ट हैं, ADFS और ADFSProxy के बीच के पोर्ट वहां बदलते हैं, न कि सेवा के पोर्ट।

लड़ाई

मैंने पैकेजों का विश्लेषण करने का फैसला किया। यह पता चला है कि उपरोक्त लिंक के चरण 3 को सफलतापूर्वक पूरा नहीं किया जा सका है, क्योंकि बाइंडिंग साइट और सेट-ADFSProxyProperties -HttpsPort 444 की सेटिंग के बावजूद, विज़ार्ड ADFS सर्वर के 443% पोर्ट के लिए अनुरोध भेजता है, और कोई स्टार्टअप कुंजी नहीं है नॉक करने के लिए कॉन्फ़िगर करने के लिए कोई फाइल नहीं।

तब मैंने http प्रॉक्सी का उपयोग करके समस्या के आसपास काम करने का फैसला किया, यह विकल्प चरण 3 में उपलब्ध है। मैंने IIS में रूटिंग अनुरोध स्थापित किया, रूटिंग अनुरोधों के नियमों को कॉन्फ़िगर किया (जैसे "1555 पोर्ट के सभी अनुरोधों को fs.contoso.ru:44444 पर पुनः निर्देशित किया गया है, मैं ब्राउज़रों के माध्यम से जांचता हूं - हुर्रे, सब कुछ काम करता है! मैं विज़ार्ड लॉन्च करता हूं, प्रॉक्सी पता निर्दिष्ट करता हूं, पोर्ट 1555, परीक्षण चलाएं - और फिर एक त्रुटि। मैं अनुरोधों को देखता हूं - विज़ार्ड अनुरोध भेजता है "कनेक्ट fs.contoso.ru:443"। यह स्पष्ट है कि एआरआर कनेक्टिंग टनलिंग का समर्थन नहीं करता है, आपको एक प्रॉक्सी की तलाश करनी होगी जो इसका समर्थन करती है।

मैंने ADFS सर्वर पर फ़िडलर स्थापित किया, सेटिंग्स में दूरस्थ कनेक्शन सक्षम किया, HTTPS CONNECTS कैप्चर, डिक्रिप्ट को सक्षम किया, नियमों में OnBeforeRequest सेक्शन में निम्न पंक्तियाँ जोड़ीं:

if (oSession.url.toLowerCase() == "fs.contoso.ru:443") oSession.url = "fs.contoso.ru:444" - परिवर्तन अनुरोध url (वही „कनेक्ट fs.contoso.ru:443) ")

if (oSession.host.toLowerCase() == "fs.contoso.ru") oSession.host = "fs.contoso.ru:444" - हम वांछित पोर्ट के लिए सुरंग के अंदर पुनर्निर्देशित अनुरोध करते हैं

oSession.utilReplaceInRequest("https://fs.contoso.ru/","https://fs.contoso.ru:444/") - अनुरोध के मुख्य भाग में हम उन लिंक को बदलते हैं जिनकी आपको ज़रूरत है।

इस संयोजन में, परीक्षण पास हो जाता है, विज़ार्ड सफलतापूर्वक पूरा हो जाता है, बाहरी काम से एडीएफएस वेब लिंक, वे portal.microsoftonline.com, अर्थात् शुरू करते हैं। हमारे ADFS प्रॉक्सी ने कमाया है!

लेकिन हमने Microsoft निर्देश के चरण 3 को किया, इसलिए अब, "गॉडल, एस्चर, बाख: द एंडलेस गारलैंड" पुस्तक की शब्दावली में, ( यहाँ से , धन्यवाद सीलन !), हमें फिर से इस निर्देश में खुद को धकेलने और सेटिंग जारी रखने की कोशिश करने की आवश्यकता है। और मैं प्रॉक्सी मध्यस्थ से छुटकारा पाना चाहता हूं। मैं चरण 4 और 6 का पालन करता हूं (यह मेरे लिए चरण 5 के बिना काम करता है), मैं विज़ार्ड को फिर से निर्दिष्ट किए बिना प्रॉक्सी को फिर से कॉन्फ़िगर करने की कोशिश करता हूं ताकि वह प्रॉक्सी के बिना काम कर सके, लेकिन परिणाम समान है - यह पोर्ट 443 को अनुरोध भेजता है। फिर मैं बस Set-ADFSProxyProperties -ForwardProxyUrl "" साथ प्रॉक्सी सेटिंग्स को हटाने की कोशिश करता हूं, फिडलर को बंद कर Set-ADFSProxyProperties -ForwardProxyUrl "" , सेवा को पुनरारंभ करता हूं, लॉग में देखता हूं और देखता हूं कि सेवा बिना किसी प्रॉक्सी प्रॉक्सी के सफलतापूर्वक काम करती है, साइटें खुलती हैं, Lync जुड़ा हुआ है। लक्ष्य प्राप्त होता है!

सारांश

इस प्रकार, एक अस्थायी प्रॉक्सी का उपयोग करते हुए, मैं ADFS प्रॉक्सी को ADFS से कनेक्ट करने में सक्षम था और फिर इसी प्रॉक्सी को हटा दें, दोनों सर्वर 444 पोर्ट पर चल रहे हैं (मैंने http पोर्ट नहीं बदला)। यह विधि उन छोटी कंपनियों के लिए उपयोगी होगी जिनके पास बाहरी IP पते की कमी है, और वे ऑफिस 365 का उपयोग करना चाहते हैं। ठीक है, Microsoft की इच्छा - निर्देशों को सही करें, इसमें कुछ गलत है)