VPN प्रमाणपत्रले LDAP भागको रक्षा गर्दैन

निर्देशिकाविरुद्ध प्रमाणहरू जाँच्ने VPN लगइनमा दुई अलग नेटवर्क जडानहरू हुन्छन्। प्रयोगकर्ताको गेटवेसँगको जडान VPN को आफ्नै प्रमाणपत्र र प्रोटोकल कन्फिगरेसनले सुरक्षित गर्छ। गेटवेको निर्देशिकासँगको जडान आफ्नै TLS सेटिङ, आफ्नै ट्रस्ट स्टोर र आफ्नै असफलता विधिहरू भएको अर्को सत्र हो। पहिलोबारे केहीले पनि दोस्रोबारे केही सुनिश्चित गर्दैन।

यही असमानता इन्क्रिप्ट गरिएको देखिने र तैपनि bind पासवर्ड खुला रूपमा पठाउने लगइनको पछाडिको क्रियाविधि हो।

दुई जडान, दुई विश्वास निर्णय

बाह्य सत्र प्रयोगकर्ताले देख्ने कुरा हो: VPN होस्टनामसँग बाँधिएको प्रमाणपत्र, क्लाइन्टद्वारा प्रमाणित, प्रमाणीकरणको आदानप्रदान बोक्ने। आन्तरिक सत्र गेटवेभित्रको निर्देशिका क्लाइन्टको हो, जसले आफ्नै जडान खोल्छ र TLS मा वार्तालाप गर्छ वा गर्दैन। प्रत्येक पक्षले आफूले बोल्ने अर्को पक्षलाई अर्को कन्फिगरेसन फाइलको सामग्रीले प्रमाणित गर्छ। गलत कन्फिगर गरिएको आन्तरिक भाग प्रयोगकर्ताको पक्षबाट अदृश्य रहन्छ, किनकि बाह्य भाग ठ्याक्कै सोचेअनुसार काम गर्छ।

त्यसैले असफलता ठूलो स्वरमा नभई शान्त हुन्छ। निर्देशिकाको प्रमाणपत्र कहिल्यै नजाँच्ने गेटवेले प्रयोगकर्ताहरूलाई सही रूपमा प्रमाणित गर्छ; यसले तिनीहरूलाई नजाँचेको च्यानलबाट मात्र प्रमाणित गर्छ।

StartTLS र LDAPS, सचेत रूपमा छानिएका

StartTLS साधारण LDAP को रूपमा खुल्छ र त्यहीँ उन्नत हुन्छ, सामान्यतया पोर्ट 389 मा। LDAPS जडानसँगै TLS सुरु गर्छ, सामान्यतया 636 मा। दुवै वैध छन् र एडाप्टरले निर्देशिकाले दिनेसँग मिल्नुपर्छ। StartTLS अनिवार्य गर्नु भनेको यसलाई प्रयास गरेर उन्नयन असफल हुँदा अगाडि बढ्नु होइन, र ठ्याक्कै त्यही भिन्नतामा bind पासवर्ड बाहिर निस्कन सक्छ। कडा मोड कन्फिगर गर्नुहोस्, र पासवर्ड bind का लागि असुरक्षित वैकल्पिक मार्गलाई अनुमति नदिनुहोस्।

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ विकल्प नै पूरै कुरा हो: क्वेरी उन्नयन बिना चुपचाप अगाडि बढ्नुको सट्टा असफल हुन्छ। त्यो लाइनका नाम र खाताहरू उदाहरण हुन्। OpenLDAP TLS कागजात ले यसको पछाडिका ट्रस्ट सेटिङहरू समेट्छ।

LDAP क्लाइन्टले कुन ट्रस्ट स्टोर पढ्छ?

OpenLDAP क्लाइन्ट लाइब्रेरीले आफ्नै ट्रस्ट कन्फिगरेसन पढ्छ, चाहे प्रणाली फाइलबाट होस् वा प्लगइन-विशिष्ट सेटिङबाट। VPN को CA निर्देश VPN सहकर्मीहरूलाई लागू हुन्छ र LDAP लाइब्रेरीले त्यही फाइल पढ्छ भन्ने प्रमाण होइन। प्रमाणपत्रले वास्तवमै समेट्ने निर्देशिका होस्टनाम प्रयोग गर्नुहोस्, साथै लाइब्रेरीले विश्वास गर्ने जारीकर्ता श्रृंखला। Active Directory मा प्रदर्शन नामबाट अनुमान गर्नुको सट्टा सही सर्भर-प्रमाणीकरण प्रयोगसहित निर्देशिका-सेवा प्रमाणपत्र तैनाथ गर्नुहोस्।

प्रत्येक फेलओभर गन्तव्यले उही पहिचान नीति पूरा गर्नुपर्छ। जुन वातावरणमा प्राथमिक प्रमाणित छ र द्वितीयक छैन, त्यो फेलओभर नभएको भन्दा नराम्रो हुन्छ, किनकि कमजोर मार्ग अवरोधको समयमा मात्र थाहा हुन्छ।

bind खाता छुट्टै समस्या रहन्छ

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

प्रमाणपत्रमा अमिलता देखिँदा सही प्रमाणपत्र वा श्रृंखला तैनाथ गर्नुहोस्। प्रमाणीकरण बन्द गर्नाले देखिने अमिलतालाई अदृश्य बनाउँछ र दोस्रो विश्वास सम्बन्धलाई अपरीक्षित छोड्छ।

दुई जडान, दुई मालिक, दुई नवीकरण मिति। कागजातमा तिनलाई अलग राख्नु नै लगइनलाई इमानदार राख्छ।