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 खाली फर्किन्छ त्यो प्रयोगकर्ता निर्देशिकाको तथ्य हो, प्लगइनको दोष होइन, र निष्क्रिय गरिसकेपछि पनि प्रमाणीकरण गर्ने खाताले फिल्टरमा खाता-नियन्त्रण सर्त छुटेको देखाउँछ। पहिले त्यो प्रमाण सुधार्नुहोस्, त्यसपछि तीन-खाता परीक्षण फेरि चलाउनुहोस्। असफल चरणको नाम बताउने लग लाइन कन्फिगरेसन परिवर्तनको छेउमा राख्नुहोस्, ताकि अर्को व्यक्तिले खोज दोहोर्याउनुबिना अधिकार र प्रमाणीकरण छुट्याउन सकोस्।

सम्बन्धित लेखहरू