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 रिकामे परत येते ते डिरेक्टरीचे सत्य आहे, प्लगइनचा दोष नाही, आणि निष्क्रिय केल्यानंतरही प्रमाणीकरण करणारे खाते म्हणजे फिल्टरमध्ये खाते-नियंत्रण अट नाही। आधी तो पुरावा दुरुस्त करा, नंतर तीन-खाते चाचणी पुन्हा चालवा। अयशस्वी चरणाचे नाव सांगणारी लॉग ओळ कॉन्फिगरेशन बदलाच्या शेजारी ठेवा, जेणेकरून पुढची व्यक्ती शोध न पुन्हा करता अधिकृतता आणि प्रमाणीकरण वेगळे करू शकेल।

संबंधित लेख