अवलोकन #
माइक्रोसॉफ्ट का वेब सर्वर, इंटरनेट इंफॉर्मेशन सर्विसेज (IIS), एक्टिव डायरेक्टरी या स्टैंड-अलोन (LDAP आधारित प्रमाणीकरण) सिस्टम के विरुद्ध उपयोगकर्ताओं को सत्यापित करने के लिए कई प्रमाणीकरण तंत्रों को एकीकृत करता है। NTLM विंडोज चैलेंज/रिस्पॉन्स प्रमाणीकरण प्रोटोकॉल है जिसका उपयोग नेटवर्क और एप्लिकेशन में किया जा सकता है जो दोनों वातावरणों में उपयोग किए जा सकते हैं।
दो अलग-अलग परिदृश्यों पर विचार किया जा सकता है: इंटरैक्टिव एनटीएलएम प्रमाणीकरण दो प्रणालियों का एक संयोजन है - एक क्लाइंट और एक डोमेन कंट्रोलर, जिसका उपयोग प्रमाणीकरण के लिए आवश्यक उपयोगकर्ता डेटा को संग्रहीत करने के लिए किया जाता है, और गैर-इंटरैक्टिव एनटीएलएम प्रमाणीकरण में तीन अलग-अलग प्रणालियाँ शामिल होती हैं - एक क्लाइंट, एक एप्लिकेशन सर्वर और एक डोमेन, ताकि उपयोगकर्ता को एप्लिकेशन में किसी विशिष्ट संसाधन तक पहुँचने की अनुमति मिल सके।
ASP.NET प्रतिरूपण उन वेब अनुप्रयोगों को अनुमति देता है जो Microsoft IIS पर निर्भर उपयोगकर्ताओं को प्रमाणित और अधिकृत कर सकते हैं।
इस लेख में हम बताएंगे कि गैर-इंटरैक्टिव उपयोगकर्ता प्रमाणीकरण परिदृश्यों के लिए NTLM प्रोटोकॉल को एकीकृत करने वाले अनुप्रयोगों का लोड संतुलन कैसे किया जाए।
एनटीएलएम कैसे काम करता है? #
NTLM प्रोटोकॉल HTTP/S प्रोटोकॉल पर निर्भर करता है, जहां एक क्लाइंट प्रमाणीकृत सत्र स्थापित करने के लिए कुल 6 चरणों का हैंडशेक शुरू करता है।
प्रमाणीकृत सत्र हैंडशेक के लिए निम्नलिखित चरणों की आवश्यकता होती है:
1. क्लाइंट किसी वेब सर्वर से किसी निश्चित संसाधन के लिए अनाम अनुरोध आरंभ करता है।
प्राप्त करें / HTTP
2. सर्वर अनधिकृत संदेश और क्लाइंट द्वारा उपयोग की जाने वाली प्रमाणीकरण विधि के साथ प्रतिक्रिया करता है।
401 अनधिकृत WWW-प्रमाणीकरण: NTLM
3. क्लाइंट NTLM प्रारूप प्रमाणीकरण चुनौती सहित अनुरोध को पुनः भेजता है।
GET / HTTP प्राधिकरण: NTLM
4. सर्वर अनधिकृत संदेश के साथ प्रतिक्रिया करता है और क्लाइंट से अधिक जानकारी का अनुरोध करता है।
401 अनधिकृत WWW-प्रमाणीकरण: NTLM
5. क्लाइंट सत्र की शेष जानकारी सहित अनुरोध को पुनः भेजता है।
GET / HTTP प्राधिकरण: NTLM
6. सर्वर प्रमाणीकरण अनुरोध को पूरा करने के लिए डोमेन कंट्रोलर से जुड़ता है और फिर क्लाइंट को प्रमाणीकरण की पुष्टि करता है।
HTTP 200 ठीक है
ध्यान दें कि यह हैंडशेक हर नए कनेक्शन में आवश्यक है, HTTP अनुरोधों में नहीं, और चरण 3 से 6 के दौरान, कनेक्शन को चालू रखना आवश्यक है। यदि कनेक्शन बंद है, तो हैंडशेक के इस भाग को दोहराया जाना चाहिए और चरण 5 से केवल दोहराना मान्य नहीं है। दूसरी ओर, एक बार कनेक्शन प्रमाणित हो जाने के बाद, प्राधिकरण हेडर को फिर से भेजने की आवश्यकता नहीं होती है, जबकि कनेक्शन एक्सेस किए गए संसाधन से स्वतंत्र रूप से बंद नहीं होता है।
एनटीएलएम प्रमाणीकरण का उपयोग करके वेब अनुप्रयोगों का लोड संतुलन कैसे करें? #
- RELIANOIDउच्च उपलब्धता में NTLM आधारित वेब अनुप्रयोग को संतुलित करने और बनाने के लिए 2 मुख्य तरीके हैं, एक सरल लेयर 4 TCP लोड बैलेंसर के साथ या उन्नत सुविधाओं के लिए लेयर 7 प्रॉक्सी के साथ।
परत 4 पर सरल NTLM लोड संतुलन #
सरल कॉन्फ़िगरेशन के साथ NTLM प्रमाणीकरण समर्थन के साथ वेब एप्लिकेशन को लोड बैलेंस करने के लिए, हम L4xNAT प्रोफ़ाइल के साथ LSLB आधारित फ़ार्म बना सकते हैं। हम HTTP या HTTPS प्रोटोकॉल का उपयोग कर सकते हैं।
फिर, वैश्विक कॉन्फ़िगरेशन में यह सुनिश्चित करें कि उपयोग किया जाने वाला प्रोटोकॉल TCP हो , लेकिन हम आवश्यक टोपोलॉजी के अनुसार NAT या DNAT का चयन कर सकते हैं।
सर्विसेज सेक्शन में , यह सुनिश्चित करने के लिए परसिस्टेंस सेट करना आवश्यक है कि किसी निश्चित क्लाइंट के लिए प्रमाणीकरण हमेशा एक ही बैकएंड पर जाए, अन्यथा कनेक्शन प्रमाणीकरण नहीं किया जा सकेगा।
अंत में, अपने बैकएंड की सूची जोड़ें और नीचे दिए गए अनुभागों में बताए अनुसार स्वास्थ्य जांच कॉन्फ़िगर करें।
परत 7 पर NTLM लोड संतुलन #
यह विकल्प LSLB मॉड्यूल और HTTP फ़ार्म के माध्यम से कॉन्फ़िगर किए गए लेयर 7 प्रॉक्सी के साथ NTLM सपोर्ट वाले HTTP/S डेटा को संभालने की अनुमति देता है। इसके लिए, हमें वर्चुअल सेवा की SSL आवश्यकताओं के अनुसार HTTP या HTTPS के लिए एक फ़ार्म बनाना होगा। एकमात्र अंतर बनाए गए फ़ार्म की वैश्विक सेटिंग्स में कॉन्फ़िगर किए गए लिसनर में होगा।
इस स्तर पर, चूंकि एप्लिकेशन अभी तक किसी भी सत्र कुकी को बनाने में सक्षम नहीं है ताकि निरंतरता या कनेक्शन पिनिंग बनाई जा सके, हम कुकी सम्मिलन विकल्प का उपयोग कर सकते हैं जो लोड बैलेंसर को एनटीएलएम प्रमाणीकरण के प्रारंभिक हैंडशेक के दौरान एक नई कुकी बनाने की अनुमति देता है।
अंत में, अपने बैकएंड की सूची जोड़ें और नीचे दिए गए अनुभागों में बताए अनुसार स्वास्थ्य जांच कॉन्फ़िगर करें। आप इस तरह के फ़ार्म में शामिल प्रॉक्सी स्तर पर अतिरिक्त एप्लिकेशन विकल्प कॉन्फ़िगर कर सकते हैं और NTLM समर्थन प्रभावित नहीं होगा।
NTLM प्रमाणीकरण वेबसाइटों के लिए उन्नत स्वास्थ्य जांच #
NTLM प्रमाणित अनुप्रयोगों के लिए अपना कस्टम उन्नत स्वास्थ्य जांच बनाने के लिए, हमें /usr/local/relianoid/app/libexec पथ के अंतर्गत एक स्क्रिप्ट बनानी होगी जो बैकएंड की जांच करे, जैसा कि नीचे दिखाया गया है। उदाहरण के लिए, check_ntlm.sh को उचित अनुमतियों के साथ बनाएं।
#!/bin/bash # इनपुट पैरामीटर्स प्राप्त करें BACKEND=$1 PORT=$2 USER=$3 PASS=$4 URI=$5 STRING=$6 /usr/bin/curl http://${BACKEND}:${PORT}${URI} --ntlm -negotiate -u ${USER}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null if [ $? == 0 ] then # यदि कर्ल कमांड विफल नहीं होती है तो सूचित करें कि बैकएंड चालू है echo "सर्वर ${BACKEND}:${PORT} ठीक है" exit 0 fi # यदि कर्ल कमांड विफल होती है तो सूचित करें कि बैकएंड बंद है echo "सर्वर ${BACKEND}:${PORT} ठीक नहीं है" exit 1
मॉनिटरिंग >> फार्मगार्डियन सेक्शन में , यदि लागू हो, या इसे फार्म सेवा में जांच करने के लिए कमांड में जोड़कर।
हम स्वास्थ्य जांच स्क्रिप्ट का परीक्षण निम्न प्रकार से कर सकते हैं:
/usr/local/relianoid/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/my/uri" "DOCTYPE html"
यह जानते हुए कि बैकएंड आईपी 192.168.0.99 है, पोर्ट 80 HTTP है, johndoe हमारे डोमेन में एक डमी उपयोगकर्ता है, johnsecret डमी पासवर्ड है, "/my/uri" जांच करने के लिए URI है और "DOCTYPE html" वह स्ट्रिंग है जिसे अनुरोध सफल होने पर प्रतिक्रिया डेटा में खोजना है।
हम एक डमी उपयोगकर्ता बनाने की सलाह देते हैं जो डोमेन में लॉग इन कर सके लेकिन उसे कोई विशेष अनुमति न हो, ताकि उसे हमारी सेवाओं के हेल्थ चेक में शामिल किया जा सके। यही कारण है कि हम अपने कस्टम हेल्थ चेक में johndoe डमी उपयोगकर्ता का उपयोग करते हैं।
जब हमारी स्वास्थ्य जांच कमांड लाइन से जांच ली जाती है और तैयार हो जाती है, तो हम इसे NTLM समर्थन के साथ कॉन्फ़िगर किए गए फार्मों को सौंप सकते हैं।
अपने लोड संतुलित NTLM वेब अनुप्रयोगों का आनंद लें!






