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 कॉन्फ़िगरेशन के साथ दर्ज करें।

जब प्रमाणपत्र में असंगति दिखे, तो सही प्रमाणपत्र या श्रृंखला तैनात करें। सत्यापन बंद करना एक दृश्य असंगति को अदृश्य बना देता है और दूसरे भरोसे के संबंध को अपरीक्षित छोड़ देता है।

दो कनेक्शन, दो स्वामी, दो नवीनीकरण तिथियाँ। दस्तावेज़ीकरण में उन्हें अलग रखना ही लॉगिन को ईमानदार रखता है।