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

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

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

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

हालांकि, ऐसे वातावरण में जहां वेब सर्वर (आईआईएस) को लोड बैलेंसर के अंतर्गत रखा जाता है और संचार एसएसएल/टीएलएस के साथ एन्क्रिप्ट किया जाता है, ऐसे मामले होते हैं जहां यह विंडोज प्रमाणीकरण सही ढंग से काम नहीं करता है।ऐसा क्यों?

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

मुख्य बिंदु यह है कि विंडोज प्रमाणीकरण तंत्र と लोड बैलेंसर संचालन यह वहीं स्थित है।

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

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

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

①: L7 लोड बैलेंसर SSL टर्मिनेशन + IIS (80 या 443) पर फॉरवर्डिंग

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

उपलब्धता

इस कॉन्फ़िगरेशन में विंडोज़ प्रमाणीकरणअनुपलब्धहै।

कारण

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

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

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

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

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

उपलब्धता

यह कॉन्फ़िगरेशन विंडोज़ प्रमाणीकरण के लिए है।उपलब्धहै।

कारण

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

योग्यता

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

नुकसान

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

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

विशेष रूप से, जब किसी FQDN (पूर्णता प्राप्त डोमेन नाम) का उपयोग करके विंडोज प्रमाणीकरण पृष्ठ तक पहुँच प्राप्त की जाती है। एसपीएन पंजीकरण यह काफी जटिल है, इसलिए कृपया निम्नलिखित बातों की भी जांच कर लें।

वेब कॉन्फ्रेंसिंग, चैट और मैसेंजर

L4 लोड बैलेंसर वातावरण में सफल एकीकृत विंडोज प्रमाणीकरण के लिए IIS कॉन्फ़िगरेशन | चैट और मैसेंजर वेब कॉन्फ्रेंसिंग संक्षिप्त विवरण: निम्नलिखित लेख में L4 लोड बैलेंसर + SSL टर्मिनेशन वातावरण में IIS में इंटीग्रेटेड विंडोज ऑथेंटिकेशन (IWA) को कॉन्फ़िगर करने का तरीका बताया गया है। यह विधि…

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

• विंडोज प्रमाणीकरण के लिए इंटरनेट विकल्प में "सुरक्षा" टैब आवश्यक है।स्थानीय इंट्रानेट पर स्थित "साइट" सेटिंग
• IIS साइट बाइंडिंग कॉन्फ़िगरेशन और SSL प्रमाणपत्र (लोड बैलेंसर पर प्रमाणपत्र स्थापित करने की आवश्यकता नहीं है)

सफलता मिलने तक फ्लोचार्ट प्रक्रिया का पालन करें

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

[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 टर्मिनेशन)
एलबी ── HTTP 302 (रीडायरेक्ट प्रतिक्रिया) → क्लाइंट
क्लाइंट ──HTTPS──▶ IIS (पोर्ट 443 तक सीधी पहुँच)

उपलब्धता

यह कॉन्फ़िगरेशन विंडोज़ प्रमाणीकरण के लिए है।उपलब्धहै।

कारण

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

परिणाम,दूसरे अनुरोध में, क्लाइंट और आईआईएस टीएलएस के माध्यम से सीधे जुड़ते हैं।इसलिए, Kerberos/NTLM प्रमाणीकरण जानकारी का आदान-प्रदान भी सीधे तौर पर एंड-टू-एंड होता है। चूंकि लोड बैलेंसर प्रमाणीकरण प्रक्रिया के दौरान हस्तक्षेप नहीं करता है, इसलिए कॉन्फ़िगरेशन योजना ① में दर्शाई गई प्रमाणीकरण हेडर हानि की समस्या से बचा जा सकता है।

योग्यता

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

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

नुकसान

एक नुकसान यह है कि IIS को लोड बैलेंसर के पीछे तैनात नहीं किया जा सकता है, जिसके लिए सार्वजनिक सर्वर के रूप में IIS के लिए एक अलग एंडपॉइंट डिज़ाइन की आवश्यकता होती है, और लोड बैलेंसर की तुलना में एक अलग प्रमाणपत्र प्लेसमेंट की आवश्यकता होती है।

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

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

प्रत्येक विन्यास की तुलना तालिका

सारांश

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

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

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

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

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