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 कॉन्फिगरेशनसोबत नोंदवा।

प्रमाणपत्रातील विसंगती दिसल्यास योग्य प्रमाणपत्र किंवा साखळी तैनात करा। पडताळणी बंद केल्याने दृश्य विसंगती अदृश्य होते आणि दुसरे विश्वासाचे नाते तपासल्याशिवाय राहते।

दोन कनेक्शन्स, दोन मालक, दोन नूतनीकरण तारखा। दस्तऐवजीकरणात ती वेगळी ठेवणे हेच लॉगिन प्रामाणिक ठेवते।