लोड बैलेंसर + SSL वातावरण में सफल होने के लिए IIS एकीकृत विंडोज प्रमाणीकरण को कैसे कॉन्फ़िगर करें

एकीकृत विंडोज प्रमाणीकरण के बारे में

एकीकृत विंडोज प्रमाणीकरण एक ऐसा तंत्र है जो IIS को उपयोगकर्ता प्रमाणीकरण जानकारी स्वचालित रूप से प्रदान करता है जब IIS और उपयोगकर्ता एक ही सक्रिय निर्देशिका डोमेन से संबंधित होते हैं। जब आप ASP.NET C# का उपयोग करके कोई साइट बनाते हैं, तो आप यह निर्धारित कर सकते हैं कि कोई उपयोगकर्ता प्रमाणीकृत है या नहीं और प्रमाणीकृत उपयोगकर्ताओं के बारे में जानकारी प्राप्त कर सकते हैं।

यह उपयोगकर्ताओं को अतिरिक्त लॉगिन संचालन के बिना आईआईएस द्वारा होस्ट किए गए (या लिंक किए गए) वेब एप्लिकेशन तक पहुंचने की अनुमति देता है, और अन्य एप्लिकेशन सर्वर के साथ एसएसओ एकीकरण को सक्षम बनाता है।

हालाँकि, ऐसे वातावरण में जहाँ वेब सर्वर (IIS) लोड बैलेंसर के अधीन है और संचार SSL/TLS के साथ एन्क्रिप्टेड है, यह Windows प्रमाणीकरण ठीक से काम नहीं कर सकता है।ऐसा क्यों?

यदि विंडोज प्रमाणीकरण सफल होता है, तो आप प्रमाणीकरण साइट तक निर्बाध रूप से पहुंच सकेंगे, लेकिन यदि यह विफल हो जाता है, तो एक साइन-इन डायल प्रदर्शित होगा। यदि आप सही तरीके से प्रमाणीकरण नहीं करते हैं, तो आपको HTTP त्रुटि 401.1 - अनधिकृत प्राप्त होगी।

बात यह है विंडोज़ प्रमाणीकरण कैसे काम करता है और लोड बैलेंसर ऑपरेशन स्थित है।

NTLM प्रत्येक क्लाइंट और सर्वर के बीच एकल TCP कनेक्शन पर एक चुनौती/प्रतिक्रिया प्रमाणीकरण विधि है। केर्बेरोस के साथ, क्लाइंट सेवा पहचानकर्ता (एसपीएन) के आधार पर एक टिकट भी प्राप्त करता है और उसे आईआईएस को भेजता है। ये क्रेडेंशियल HTTP हेडर के माध्यम से भेजे जाते हैं (प्राधिकरण: बातचीत... लेन-देन उपरोक्त विधियों का उपयोग करके किया जाता है। हालाँकि, लेयर 7 लोड बैलेंसर अपने डिवाइस पर क्लाइंट से HTTPS कनेक्शन को समाप्त कर देता है, सामग्री का विश्लेषण करता है, और इसे नए अनुरोध के रूप में बैकएंड IIS को अग्रेषित करता है। इस प्रक्रिया के दौरानक्लाइंट और IIS के बीच एंड-टू-एंड TLS सत्र समाप्त हो गया है।इसके अलावा, NTLM जैसी स्थायी प्रमाणीकरण जानकारी को आगे नहीं बढ़ाया जाता, जिसके कारण प्रमाणीकरण प्रक्रिया विफल हो जाती है।

उपरोक्त पृष्ठभूमि के आलोक में, यह आलेख "लोड बैलेंसर + SSL वातावरण में सफलता के लिए IIS एकीकृत Windows प्रमाणीकरण को कॉन्फ़िगर करना हम निम्नलिखित पर विचार करेंगे। हम तीन विशिष्ट कॉन्फ़िगरेशन पैटर्न सूचीबद्ध करेंगे और प्रत्येक के लिए यह बताएंगे कि क्या Windows प्रमाणीकरण समर्थित है, इसके तकनीकी कारण क्या हैं, तथा कॉन्फ़िगरेशन के लाभ और हानियाँ क्या हैं।

प्रत्येक कॉन्फ़िगरेशन योजना का तकनीकी सत्यापन

①: L7 लोड बैलेंसर SSL समाप्ति + IIS को अग्रेषित करना (80 या 443)

क्लाइंट ──HTTPS──▶ L7 लोड बैलेंसर (SSL समाप्ति) ──HTTP(S)──▶ IIS (80 या 443)

उपलब्धता

इस कॉन्फ़िगरेशन में Windows प्रमाणीकरण समर्थित नहीं है.उपलब्ध नहीं हैहै।

कारण

चूँकि क्लाइंट और IIS के बीच TLS सत्र लोड बैलेंसर पर एक बार समाप्त हो जाता है,संपूर्ण क्रेडेंशियल स्थानांतरण संभव नहीं हैइसीलिए। L7 लोड बैलेंसर प्राप्त HTTPS ट्रैफ़िक को डिक्रिप्ट करता है और क्लाइंट की ओर से IIS तक पहुँचता है। इस समय, ग्राहक को भेजना चाहिए प्राधिकरण: बातचीत हेडर (केर्बेरोस टिकट और एनटीएलएम टोकन सहित प्रमाणीकरण हेडर) आईआईएस तक सही ढंग से नहीं पहुंचेंगे। विशेष रूप से, NTLM के साथ, IIS द्वारा प्रारंभिक अनुरोध पर भेजा जाने वाला प्रमाणीकरण चुनौती प्रत्युत्तर (WWW-प्रमाणित) क्लाइंट पुनः अनुरोध भेजता है, लेकिन LB के माध्यम सेसमान TCP सत्र कायम नहीं रखा गया हैइसलिए, NTLM हैंडशेक सफल नहीं होता है।

वास्तव में, AWS वातावरण में भी, Windows प्रमाणीकरण एप्लिकेशन लोड बैलेंसर (ALB) या HTTP श्रोताओं के साथ काम नहीं करता है, और नेटवर्क लोड बैलेंसर (NLB) जैसे TCP-स्तरीय LB की आवश्यकता होती है।संदर्भ]. इसके अलावा, Azure एप्लिकेशन गेटवे v2 बैकएंड पर एकीकृत प्रमाणीकरण सहित HTTP हेडर पास करने का समर्थन नहीं करता है।संदर्भ].

तथ्य यह है कि यह प्रत्येक क्लाउड विक्रेता के प्रबंधित एलबी द्वारा आधिकारिक रूप से समर्थित नहीं है, यह L7 स्तर पर विंडोज प्रमाणीकरण को बनाए रखने की कठिनाई को दर्शाता है।

②: L4 लोड बैलेंसर (TLS पास-थ्रू) + IIS फ़ॉरवर्डिंग

क्लाइंट ──HTTPS──▶ L4 लोड बैलेंसर (TLS पास-थ्रू) ──HTTPS──▶ IIS (443)

उपलब्धता

यह कॉन्फ़िगरेशन Windows प्रमाणीकरण का उपयोग करता है.अनुकूलहै।

कारण

चूंकि L4 लोड बैलेंसर (LB जो OSI लेयर 4 पर संचालित होता है) पैकेटों को TCP स्तर पर रिले करता है,क्लाइंट और IIS के बीच TLS सत्र को एंड-टू-एंड बनाए रखा जाता हैकिया जायेगा। लोड बैलेंसर एन्क्रिप्शन को समाप्त नहीं करता है, बल्कि प्रत्येक सर्वर को केवल TCP कनेक्शन वितरित करता है, जिससे NTLM प्रमाणीकरण द्वारा अपेक्षित "समान TCP कनेक्शन पर संचार" कायम रहता है। जहां तक ​​केर्बेरोस का प्रश्न है, क्लाइंट के दृष्टिकोण से, इसे इस प्रकार पुनरुत्पादित किया जा सकता है मानो क्लाइंट सीधे IIS (सेवा) के FQDN से जुड़ रहा हो, अतः जब तक SPN को उचित रूप से सेट किया गया है, टिकट-आधारित प्रमाणीकरण उसी प्रकार आगे बढ़ता रहेगा। AWS NLB और क्लासिक LB TCP श्रोता मोड, Azure आंतरिक लोड बैलेंसर, F5 L4 मोड, आदि इस श्रेणी से संबंधित हैं (अन्य में HAProxy TCP मोड और nginx स्ट्रीम शामिल हैं), और Windows एकीकृत प्रमाणीकरण से गुजर सकते हैं।

योग्यता

क्लाइंट से सर्वर तक TLS सत्र बाधित नहीं होता है।विंडोज़ प्रमाणीकरण प्रोटोकॉल वैसे ही काम करना जारी रखते हैं जैसे उन्हें करना चाहिएकर सकना। NTLM तीन-तरफ़ा हैंडशेक भी एक ही कनेक्शन के भीतर पूरा हो जाता है, और केर्बेरोस टिकट बैक-एंड सर्वर द्वारा सही ढंग से प्राप्त किया जाता है। इसके अतिरिक्त, चूंकि LB एक L4 ऑपरेशन है, इसलिए इसका ओवरहेड कम है और इससे उच्च थ्रूपुट प्राप्त करने की उम्मीद की जा सकती है।

अवगुण

L4 लोड बैलेंसर को कॉन्फ़िगर करने में सबसे बड़ी चुनौती विस्तृत पथ-आधारित या होस्टनाम-आधारित रूटिंग करने में असमर्थता है। उदाहरण के लिए, किसी URL पथ में (उदा./एपीआई,/बात करनाप्रत्येक अनुरोध (या एकाधिक अनुरोधों) को एक अलग बैकएंड सर्वर पर वितरित करना एक ऐसी सुविधा है जो केवल L7 (HTTP) के साथ प्राप्त की जा सकती है और L4 (TCP) के साथ संभव नहीं है।

इसलिए, सिस्टम आवश्यकताओं के आधार पर, लोड बैलेंसर के भीतर कई FQDN तैयार करना और विभिन्न उद्देश्यों (वेब सर्वर, विंडोज प्रमाणीकरण के लिए सर्वर, आदि) के लिए अलग-अलग वर्चुअल सर्वर आवंटित करना आवश्यक हो सकता है, जिसका नुकसान यह है कि कॉन्फ़िगरेशन अधिक कठिन हो जाता है।

इसके अलावा, कृपया ध्यान दें कि विंडोज प्रमाणीकरण के लिए आवश्यक निम्नलिखित सभी सेटिंग्स लोड बैलेंसर का FQDN सेट करती हैं।

• इंटरनेट विकल्प "सुरक्षा" टैब में विंडोज़ प्रमाणीकरण आवश्यक है।"स्थानीय इंट्रानेट" "साइटें" सेटिंग
• FQDN (पूर्णतः योग्य डोमेन नाम) का उपयोग करके Windows प्रमाणीकरण पृष्ठ तक पहुँचने पर एसपीएन पंजीकरण
• IIS साइट बाइंडिंग सेटिंग्स और SSL प्रमाणपत्र (लोड बैलेंसर पर कोई प्रमाणपत्र स्थापित करने की आवश्यकता नहीं है)

* यदि लोड बैलेंसर FQDN lb.example.com है, तो केर्बेरोस सफल होने तक प्रवाह निम्नानुसार है:

[Client]
  | 1. DNS解決: lb.example.com → LB
  |
  | 2. Kerberos: SPN = HTTP/lb.example.com
  |             → ドメインコントローラーにTGSを要求
  |
  | 3. TLSハンドシェイク: SNI = lb.example.com
  |             → IISで一致する証明書必要
  |
  | 4. リクエスト送信: Hostヘッダ = lb.example.com
[IIS]
  → SPN受け入れOK、証明書OK、認証成功

③: L7 लोड बैलेंसर SSL समाप्ति + IIS कॉन्फ़िगरेशन पर रीडायरेक्ट

क्लाइंट ──HTTPS──▶ L7 लोड बैलेंसर (SSL समाप्ति)
LB ──HTTP 302 (रीडायरेक्ट प्रतिक्रिया) → क्लाइंट
क्लाइंट ──HTTPS──▶ IIS (443 तक सीधी पहुंच)

उपलब्धता

यह कॉन्फ़िगरेशन Windows प्रमाणीकरण का उपयोग करता है.अनुकूलहै।

कारण

विचार यह है कि लोड बैलेंसर वास्तविक संचार को रिले नहीं करता है, बल्कि क्लाइंट को सीधे बैकएंड IIS (HTTP 302 प्रतिक्रिया) पर पुनर्निर्देशित करता है। जब कोई उपयोगकर्ता पहली बार LB URL तक पहुंचता है, तो L7 लोड बैलेंसर वहां SSL को समाप्त कर देता है, सामग्री का विश्लेषण करता है, और HTTPS के माध्यम से उपयुक्त IIS पते (उदाहरण के लिए, प्रत्येक IIS के लिए अलग-अलग होस्टनाम या IP पता) से कनेक्ट करने के लिए लोकेशन हेडर के साथ 302 प्रतिक्रिया देता है। क्लाइंट ब्राउज़र इस रीडायरेक्ट को प्राप्त करता है और स्वचालित रूप से HTTPS के माध्यम से सीधे निर्दिष्ट IIS पर अनुरोध पुनः सबमिट करता है।

परिणाम,दूसरे अनुरोध के लिए, क्लाइंट और IIS सीधे TLS के माध्यम से कनेक्ट होते हैंइसलिए, केर्बेरोस/एनटीएलएम प्रमाणीकरण जानकारी को शुरू से अंत तक यथावत पारित किया जाता है। चूंकि लोड बैलेंसर प्रमाणीकरण प्रक्रिया में शामिल नहीं होता है, इसलिए यह प्रमाणीकरण हेडर हानि की समस्या से बच सकता है जैसा कि कॉन्फ़िगरेशन 1 में देखा गया है।

योग्यता

इसका एक प्रमुख लाभ यह है कि TLS सीधे क्लाइंट से IIS से जुड़ा होता है, जिससे Windows प्रमाणीकरण को सफल बनाना आसान हो जाता है।है।
यदि केवल IIS का उपयोग करके प्रमाणीकरण सफल हो जाता है, तो कॉन्फ़िगरेशन को उसी रूप में उपयोग किया जा सकता है, इसलिए लोड बैलेंसर को मध्यस्थ के रूप में उपयोग करने पर भी कठिनाई में कोई वृद्धि नहीं होती है।

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

अवगुण

इसका नुकसान यह है कि IIS को LB के पीछे तैनात नहीं किया जा सकता है, तथा IIS के लिए एक सार्वजनिक सर्वर के रूप में एक अलग समापन बिंदु डिजाइन किया जाना चाहिए, तथा LB के लिए एक अलग प्रमाणपत्र रखा जाना चाहिए।

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

IIS पर रीडायरेक्ट करने और Windows प्रमाणीकरण से गुजरने के बाद हमारी सेवा में लॉग इन करने की गति के संदर्भ के लिए, यहां देखेंचलचित्रकृपया देखें।

प्रत्येक कॉन्फ़िगरेशन की तुलना तालिका

सारांश

विंडोज प्रमाणीकरण (NTLM/Kerberos) के ठीक से काम करने के लिए, यह आवश्यक है कि TLS सत्र को क्लाइंट से लेकर IIS तक बनाए रखा जाए।

विकल्प 2 के L4 लोड बैलेंसर कॉन्फ़िगरेशन में, TLS रिले नहीं किया जाता है और सीधे IIS तक पहुंचता है, इसलिए प्रमाणीकरण सफल होता है। हालाँकि, इसे कॉन्फ़िगर करना अधिक कठिन है क्योंकि यह विस्तृत पथ-आधारित रूटिंग की अनुमति नहीं देता है और लोड बैलेंसर के भीतर कई वर्चुअल सर्वरों को कॉन्फ़िगर करना आवश्यक है।

दूसरी ओर, विकल्प 3 में रीडायरेक्ट कॉन्फ़िगरेशन को केवल पहली बार L7 लोड बैलेंसर द्वारा संसाधित किया जाता है, और फिर सीधे IIS से कनेक्ट किया जाता है, जो TLS और प्रमाणीकरण के दृष्टिकोण से एक आदर्श प्रवाह है। विशिष्ट पथों को IIS FQDN पर पुनर्निर्देशित करके, आप L7 नियम नियंत्रण और Windows प्रमाणीकरण दोनों प्राप्त कर सकते हैं। यह जांचना आवश्यक है कि क्या IIS के साथ कोई नीतिगत मुद्दे हैं जो पोर्ट 443 को ANY के रूप में अनुमति देने वाले LB के पीछे नहीं है।

दूसरी ओर, विकल्प 1 जैसे कॉन्फ़िगरेशन में, जहां L7 लोड बैलेंसर TLS समाप्ति या HTTP व्याख्या करता है, प्रमाणीकरण जानकारी बाधित होती है और Windows प्रमाणीकरण काम नहीं करता है।

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