OpenVPN में LDAP प्रमाणीकरण काम करता है पर समूह जाँच विफल होती है: कहाँ देखें

प्रमाणीकरण पार हो सकता है जबकि समूह जाँच सभी को अस्वीकार कर देती है। Authorization ब्लॉक, सदस्यता विशेषता और निर्देशिका एंडपॉइंट को बारी-बारी देखें।

क्रेडेंशियल पार हो जाते हैं, सुरंग ऊपर उठने लगती है, और फिर सत्र पासवर्ड के बारे में नहीं बल्कि समूह के बारे में संदेश के साथ विफल हो जाता है। यह संयोजन विफलता को LDAP प्लगइन के काम के दूसरे आधे हिस्से में रखता है: बाइंड और पासवर्ड जाँच सफल रही, और उसके बाद आने वाला सदस्यता निर्णय नहीं। दोनों आधे एक ही कॉन्फ़िगरेशन खंड से पढ़ते हैं, इसलिए एक जगह का सुधार दूसरे को अछूता छोड़ सकता है। उस लॉग पंक्ति से शुरू करें जो चरण का नाम लेती है, उस खाते से नहीं जिससे आप संयोगवश परीक्षण कर रहे हैं।

अस्वीकृति को प्राधिकरण का उत्तर मानें

प्लगइन सेवा बाइंड करता है, खाता खोजता है, दिया गया पासवर्ड सत्यापित करता है, और फिर पूछता है कि क्या वह खाता किसी अनुमत समूह का है। ये चार अलग-अलग क्रियाएँ हैं, और केवल अंतिम समूहों के बारे में है। इसलिए सफल बाइंड के बाद आने वाली अस्वीकृति पासवर्ड के बारे में कुछ नहीं कहती, तब भी जब क्लाइंट सामान्य प्रमाणीकरण त्रुटि दिखाता है। कॉन्फ़िगरेशन बदलने से पहले प्लगइन का लॉग स्तर बढ़ाना ही उन चारों को आउटपुट में अलग करता है।

समूह मूल्यांकन को ही खोजें। जब कोई समूह क्वेरी दिखाई ही नहीं देती, तो प्राधिकरण ब्लॉक तक पहुँचा ही नहीं जाता, जिसका अर्थ आम तौर पर यह होता है कि कोई निर्देश उस खंड के बाहर है जो उसका मालिक है या कोई अनिवार्य विकल्प गायब है। जब क्वेरी दिखाई देती है और कुछ लौटाती नहीं, तो एंडपॉइंट या फ़िल्टर आपके इरादे से भिन्न प्रश्न का उत्तर दे रहा है।

तय करें कि सदस्यता फ़िल्टर में रहती है या समूह ब्लॉक में

दो समर्थित रूप हैं, और इन्हें मिलाना ही वह तरीका है जिससे काम करता कॉन्फ़िगरेशन काम करना बंद कर देता है। पहला उपयोगकर्ता ऑब्जेक्ट पर विशेषता माँगकर सदस्यता को उपयोगकर्ता खोज में धकेलता है; दूसरा उपयोगकर्ता खोज को अछूता छोड़ता है और प्लगइन को बाद में समूह ऑब्जेक्ट खोजने देता है। प्रत्येक परिनियोजन के लिए एक चुनें और लिखें कि आपने कौन-सा चुना।

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

उस रूप में फ़िल्टर सब कुछ तय करता है, इसलिए RequireGroup को false होना चाहिए, अन्यथा प्लगइन ऐसे समूह ऑब्जेक्ट की खोज में जाता है जिसका फ़िल्टर ने कभी उल्लेख नहीं किया। फ़िल्टर की विशेषता उपयोगकर्ता ऑब्जेक्ट पर मौजूद और भरी होनी चाहिए, जो समूहों के नेस्टेड होने पर सुनिश्चित नहीं है।

दूसरा रूप खोज को सरल रखता है और उसके बाद समूह खोज जोड़ता है। समूह ऑब्जेक्ट का स्पष्ट नाम दिया जाता है, और प्लगइन उपयोगकर्ता की तुलना उन सदस्यों से करता है जो निर्देशिका उसके लिए लौटाती है। उपयोगकर्ता फ़िल्टर में कुछ नहीं बदलता, जिससे यह रूप दूसरी टीम द्वारा समूह संभालने पर जाँचना आसान हो जाता है।

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

अंधा स्थान साझा है: साधारण सदस्यता तुलना नेस्टेड समूहों का विस्तार नहीं करती, इसलिए जिस खाते तक पहुँच मूल समूह से आती है वह विफल होता है जबकि कंसोल अभी भी सदस्यता दिखाता है। Active Directory समूह पर member उजागर करता है, अन्य स्कीमाएँ uniqueMember उपयोग करती हैं, और गलत विशेषता की ओर इशारा करने पर त्रुटि के बजाय खाली परिणाम आता है।

ऐसा एंडपॉइंट चुनें जो समूह ऑब्जेक्ट रखता हो

URL तय करता है कि प्लगइन किस निर्देशिका से पूछता है, और 389 पोर्ट पर डोमेन नियंत्रक केवल अपने ही नामकरण संदर्भ का उत्तर देता है। 3268 पोर्ट पर वैश्विक कैटलॉग पूरे वन का उत्तर देता है, केवल-पठन और आंशिक विशेषता समुच्चय के साथ। जब खाते एक डोमेन में हों और VPN समूह दूसरे में, तो एक-डोमेन क्वेरी उपयोगकर्ता को ढूँढ भी सकती है और सदस्यता चूक सकती है। यही वह स्थिति है जहाँ URL को कैटलॉग पोर्ट पर ले जाना अस्वीकृति हल करता है, और यही वह स्थिति भी है जहाँ लोग बहुत दूर तक सामान्यीकरण करते हैं।

आंशिक विशेषता समुच्चय ही सीमा है: जिस विशेषता को कैटलॉग नहीं रखता उस पर फ़िल्टर नहीं किया जा सकता, इसलिए वही बदलाव एक परिनियोजन को चला सकता है और दूसरे को कुछ नहीं लौटाने दे सकता। खंड को फिर से लिखने से पहले पुष्टि करें कि एंडपॉइंट वास्तविक उपयोगकर्ता और समूह के लिए वास्तव में क्या लौटाता है। रेफ़रल और TLS फिर अलग विषय हैं, क्योंकि रेफ़रल का अनुसरण करना पड़ता है और TLS माँगने वाले एंडपॉइंट को मेल खाती ट्रस्ट फ़ाइलें चाहिए।

खाता स्थिति और खोज क्षेत्र को उनके अपने फ़ील्ड में रखें

निष्क्रिय ध्वज फ़िल्टर में आता है, समूह जाँच में नहीं। Active Directory में यह userAccountControl का दूसरा बिट है, और उस शर्त के बिना वैध पासवर्ड वाला निष्क्रिय खाता प्रमाणीकरण करता है और फिर समूह चरण पर विफल होता है, जो प्राधिकरण दोष जैसा लगता है। खोज क्षेत्र आधार DN में आता है, क्योंकि डोमेन रूट से शुरू करना धीमा है और उस संगठनात्मक इकाई के बाहर की वस्तुओं से मेल खा सकता है जिसे आप कवर करना चाहते थे।

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

तीन खातों से परिणाम सिद्ध करें

कॉन्फ़िगरेशन को तीन पहचानों पर चलाएँ: एक अनुमत सदस्य, समूह के बाहर का वैध खाता, और एक खाता जिसे निष्क्रिय किया गया है। यदि तीनों अस्वीकार हों, तो बाइंड या समूह क्वेरी टूटी है; यदि तीनों स्वीकार हों, तो कोई समूह शर्त लागू ही नहीं हो रही। मिश्रित परिणाम ही एकमात्र परिणाम है जो सिद्ध करता है कि कॉन्फ़िगरेशन आपके लिए महत्वपूर्ण स्थितियों को अलग करता है।

प्लगइन को दोष देने से पहले वही तीन उत्तर सीधे निर्देशिका से पढ़ें। पहली क्वेरी वह समूह विशेषता दिखाती है जिस पर फ़िल्टर निर्भर है, और दूसरी खाता-नियंत्रण मान दिखाती है। अपना आधार DN, खाता और एंडपॉइंट रखें:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

जिस उपयोगकर्ता का memberOf खाली लौटता है वह निर्देशिका का तथ्य है, प्लगइन का दोष नहीं, और निष्क्रिय किए जाने के बाद भी प्रमाणीकरण करने वाला खाता बताता है कि फ़िल्टर में खाता-नियंत्रण शर्त गायब है। पहले वह प्रमाण ठीक करें, फिर तीन-खाता परीक्षण दोबारा चलाएँ। विफल चरण का नाम लेने वाली लॉग पंक्ति को कॉन्फ़िगरेशन बदलाव के पास रखें, ताकि अगला व्यक्ति खोज दोहराए बिना प्राधिकरण को प्रमाणीकरण से अलग कर सके।

संबंधित लेख