NetExtender लॉग इन होता है पर पहुँच नहीं: SonicWall स्थानीय + LDAP
NetExtender जुड़ता है पर कोई जवाब नहीं देता: SonicWall प्रमाणीकरण, SSL VPN सेवा की सदस्यता और स्थानीय व LDAP उपयोगकर्ताओं के लिए VPN पहुँच अनुमतियाँ अलग-अलग जाँचें।
लॉग इन सफल होता है, टनल बनती है और फ़ायरवॉल के पीछे कुछ भी जवाब नहीं देता। SonicWall SSL VPN पर यह पैटर्न आम तौर पर बताता है कि खाता प्रमाणीकरण से गुज़र गया और बाद की दो अनुमतियों में से एक पर रुक गया: SSL VPN सेवा में स्वीकृति, या किसी संसाधन तक पहुँचने की अनुमति। स्थानीय और LDAP खाते मिले-जुले हों तो स्थिति बिगड़ती है, क्योंकि दोनों भंडार इन अनुमतियों तक अलग-अलग रास्तों से पहुँचते हैं। क्लाइंट की ओर से लक्षण एक जैसा होता है, इसलिए परतों को जानबूझकर अलग करना पड़ता है।
लक्षण और उसके पीछे की तीन अनुमतियाँ
उपयोगकर्ता नाम और पहुँच योग्य सर्वर के बीच तीन स्वतंत्र निर्णय होते हैं। प्रमाणीकरण का तरीका तय करता है कि क्रेडेंशियल स्वीकार होते हैं या नहीं और कौन-सा भंडार उन्हें स्वीकार करता है। SSL VPN सेवा की सदस्यता तय करती है कि यह पहचान SSL VPN इस्तेमाल कर सकती है या नहीं। VPN पहुँच सूची तय करती है कि सत्र किन निजी गंतव्यों तक पहुँच सकता है। एक से गुज़रना अगली दो के बारे में कुछ नहीं कहता।
जो उपयोगकर्ता प्रमाणित होता है पर SSL VPN सेवा समूह में नहीं है, वह ऐसा कनेक्शन देखता है जो बनता है और फिर कुछ नहीं ले जाता, और फ़ायरवॉल लॉग विफलता के बजाय स्वीकृत लॉगिन दिखाता है। यही वह स्थिति है जिसे जल्दी पहचानना चाहिए, क्योंकि समाधान समूह की सदस्यता है, पासवर्ड रीसेट नहीं।
जो उपयोगकर्ता स्वीकार होता है पर उसके पास संसाधन नहीं हैं, वह ऐसा सत्र देखता है जो जुड़ता है और किसी काम की जगह नहीं जाता। हेल्प डेस्क की नज़र में दोनों टूटी टनल जैसे लगते हैं, और दोनों कनेक्टिविटी नहीं, कॉन्फ़िगरेशन की समस्या हैं।
डोमेन बॉक्स डायरेक्टरी नहीं है
NetExtender डोमेन माँगता है, और वह फ़ील्ड Active Directory के लिए खोज आधार नहीं है। डिफ़ॉल्ट व्यवस्था में फ़ील्ड उस SSL VPN उपयोगकर्ता डोमेन के बराबर होना चाहिए जो फ़ायरवॉल ने कॉन्फ़िगर किया है, और उसके लिए प्रलेखित डिफ़ॉल्ट मान है LocalDomain। तुलना केस-संवेदी है, इसलिए अलग बड़े-छोटे अक्षरों में लिखा मान खाता सही होने पर भी विफल होता है।
जब प्रमाणीकरण विभाजन कॉन्फ़िगर होता है, तो विभाजन नाम बाहरी प्रमाणीकरण संदर्भ चुनते हैं, और कॉन्फ़िगर किया गया डिफ़ॉल्ट अपनी भूमिका बनाए रखता है। दोनों व्यवस्थाओं में क्लाइंट पक्ष का डोमेन लेबल उपयोगकर्ता नाम के हिस्से के रूप में LDAP या RADIUS को नहीं भेजा जाता, इसलिए वह डायरेक्टरी खोज को निर्देशित नहीं कर सकता।
तीनों स्ट्रिंग अपने नोट्स में अलग रखें: कंपनी का DNS सफ़िक्स, LDAP खोज आधार और NetExtender डोमेन लेबल। ये एक जैसे लगते हैं और कोई किसी की जगह नहीं लेता। इस इंस्टॉलेशन के लिए ऑपरेटर का मान कॉपी करें, किसी दूसरे फ़र्मवेयर रिलीज़ के बारे में फ़ोरम पोस्ट का मान नहीं।
स्वीकृति और संसाधन पहुँच अलग अनुमतियाँ हैं
स्थानीय खातों को सेवा द्वारा स्वीकार होने से पहले SSL VPN सेवा समूह की सदस्यता चाहिए। डायरेक्टरी खाते उसी समूह तक समर्थित समूह मैपिंग वर्कफ़्लो से पहुँचते हैं, यानी LDAP समूह संबंध कॉन्फ़िगर करना होता है और फिर डायरेक्टरी पक्ष से मान लेने के बजाय प्रभावी सदस्यता के रूप में सत्यापित करना होता है।
संसाधन पहुँच इसके बाद आती है, उपयोगकर्ता या समूह पर VPN पहुँच के अंतर्गत। केवल वही विशिष्ट सबनेट और सेवाएँ दें जिनकी भूमिका को ज़रूरत है, और एक एप्लिकेशन की ज़रूरत के कारण पूरा LAN देने के शॉर्टकट से बचें। सत्र के रूट, पहुँच नियम और गंतव्य सेवा की अनुमतियाँ सभी इस दायरे से मेल खानी चाहिए।
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
क्लाइंट पर रूट गंतव्य को चुनने योग्य बनाता है और उसे अनुमति नहीं देता। SSL VPN समूह की सदस्यता खाते को फ़ायरवॉल व्यवस्थापक भी नहीं बनाती, और इसे सामान्य विशेषाधिकार देने की तरह नहीं देखना चाहिए।
दो पहचान, हर एक के चार जाँच
एक स्थानीय खाते और एक डायरेक्टरी खाते से परखें, दोनों को सीमित अनुमति दें और दोनों को परीक्षण खाते के रूप में दर्ज करें। हर एक के लिए वह प्रमाणीकरण स्रोत लिखें जिसने लॉगिन स्वीकार किया, प्रभावी समूह, आवंटित संसाधन पहुँच और एक स्वीकृत एप्लिकेशन क्रिया। चार जाँच, दो भंडार और हर संयोजन के लिए लिखित परिणाम।
फिर नकारात्मक स्थितियाँ परखें: वह संसाधन जिस तक खाता नहीं पहुँचना चाहिए, और वह खाता जिसे तुरंत अस्वीकार करना चाहिए। केवल सकारात्मक रास्ता साबित करने वाला डिज़ाइन अक्सर दूसरा दरवाज़ा खुला छोड़ देता है, खासकर जब वही छोटा उपयोगकर्ता नाम दोनों भंडारों में मौजूद हो। डायरेक्टरी खाता बंद करें और पुष्टि करें कि स्थानीय खाता चुपचाप काम नहीं करता रहता।
दोहराए गए नामों की समीक्षा परिनियोजन का हिस्सा मानें, किसी घटना के बाद नहीं। एक ही व्यक्ति का दो भंडारों में होना एक साथ सहायता की सुविधा और ऑडिट की समस्या है, और फ़ायरवॉल खुशी से उसी को प्रमाणित करेगा जिसे आपने कॉन्फ़िगर किया।
रिकवरी पथ संकीर्ण रखें
स्थानीय खातों को छूट देने के बजाय हर खाता वर्ग के लिए MFA नीति बनाए रखें। अगर स्थानीय खाते डायरेक्टरी बाधा के लिए स्वीकृत रिकवरी पथ देते हैं, तो उस पथ को नामित व्यवस्थापकों तक सीमित रखें और सोच-समझकर चलाएँ, क्योंकि हर कर्मचारी के लिए स्थानीय आपातकालीन खाता कमज़ोर निगरानी वाला दूसरा प्रमाणीकरण तंत्र है।
क्लाइंट डोमेन, प्रमाणीकरण स्रोत और प्रभावी पहुँच एक ही रिकॉर्ड में लिखें। अगला व्यवस्थापक तब काम करने वाला मिश्रित खाता डिज़ाइन दोबारा बना सकता है, बजाय इसके कि लॉगिन सफल होने तक डोमेन स्ट्रिंग आज़माता रहे।