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 नीति राख्नुहोस्। यदि स्थानीय खाताले डाइरेक्टरी अवरोधका लागि स्वीकृत पुनर्प्राप्ति मार्ग दिन्छन् भने त्यो मार्ग नामित प्रशासकहरूमा सीमित गर्नुहोस् र जानाजान चलाउनुहोस्, किनकि प्रत्येक कर्मचारीका लागि स्थानीय आपत्कालीन खाता कमजोर निगरानी भएको दोस्रो प्रमाणीकरण प्रणाली हो।
क्लाइन्ट डोमेन, प्रमाणीकरण स्रोत र प्रभावकारी पहुँच एउटै रेकर्डमा लेख्नुहोस्। अर्को प्रशासकले त्यसपछि काम गर्ने मिश्रित खाता डिजाइन पुनः सिर्जना गर्न सक्छ, लगइन सफल नहुँदासम्म डोमेन स्ट्रिङ परीक्षण गर्नुको सट्टा।