त्यो LDAP पासवर्ड त्रुटि प्रयोगकर्ताको पासवर्ड नै नहुन सक्छ
bind असफलता सेवा खाता वा खोज क्षेत्रबाट आउन सक्छ, प्रयोगकर्ताबाट होइन। कसैको पासवर्ड रिसेट गर्नुअघि bind अलग गर्नुहोस्।
लगले bind अस्वीकार भयो भनेर मात्र भन्छ भने प्रयोगकर्ताको पासवर्ड रिसेट गर्नु गलत पहिलो कदम हो। डाइरेक्टरी प्लगइनसँग एउटै लगइनमा एकभन्दा बढी bind हुन्छन्, र अस्वीकृति खोज गर्ने सेवा खाताको हुन सक्छ। त्यस अवस्थामा प्रयोगकर्ताको प्रमाणहरू रिसेट गर्दा केही पनि बदलिँदैन। यसले कहिल्यै समस्या नभएको व्यक्तिलाई पनि बाहिर राख्छ।
एउटा लगइन, धेरै bind
समर्पित डाइरेक्टरी खाता भएको कन्फिगरेसनले सामान्यतया क्रममा चार चरण गर्छ, र तीमध्ये कुनैले पनि लगइन अन्त्य गर्न सक्छ।
connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groupsप्लगइनले आफ्नो प्रयोगकर्ता प्रमाणीकरण जडान पहिलो जडान सम्हाल्ने त्यही सहायकमार्फत बनाउँछ, त्यसैले त्यो सहायक जडान गर्दा, TLS वार्तामा वा सेवा खाताको रूपमा bind गर्दा असफल हुन सक्छ। पासवर्डबारे उच्च-स्तरीय सन्देश पछि उत्पन्न हुन्छ, र त्यसमा कुन पहिचान संलग्न थियो भन्ने आउँदैन। त्यसैले त्रुटि पाठ मात्रले प्रयोगकर्ता वा सेवा खाता अस्वीकार भयो भनेर बताउन सक्दैन।
सन्देशअघिका हरफहरू पढ्नुहोस्, र असफलता भएको क्षण नोट गर्नुहोस्। सुरुमा, कुनै प्रयोगकर्ता आउनुअघिको अस्वीकृति कन्फिगर गरिएको खाता वा अन्तिम बिन्दुलाई संकेत गर्छ। सफल खोजपछि एक व्यक्तिलाई मात्र देखिने अस्वीकृति त्यो व्यक्तिको प्रविष्टि वा खाता स्थितिलाई संकेत गर्छ।
त्रुटिलाई पहिचानसँग जोड्नुहोस्
व्यावहारिक नियम तीन कुरा सँगै अभिलेख गर्नु हो: कहिले असफल भयो, कुन अपरेसन चलिरहेको थियो र कुन पहिचान प्रस्तुत गरियो। त्यो त्रिक बिना, अन्तिम वाक्य मात्र राख्ने लगमा दुई धेरै फरक खराबी एउटै देखिन्छन्।
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
कन्फिगर गरिएको खाता असफल भयो भने, कुनै पनि प्रयोगकर्ता रेकर्ड छुनुअघि त्यो खाता र जडान जाँच्नुहोस्। सफल खोजपछि प्रयोगकर्ताको bind असफल भयो भने, खोजले फर्काएको प्रविष्टि जाँच्नुहोस्, तपाईंले अपेक्षा गरेको प्रविष्टि होइन। दुई मार्गले एउटा सन्देश मात्र साझा गर्छन्। तपाईंले कुन बाहिर राख्नुभयो लेख्नुहोस्, किनकि अर्को व्यक्तिले ठ्याक्कै त्यही सोध्नेछ।
विशिष्ट नाम डेटा हो, अनुमान होइन
नामको घटक अपरिचित देखिन्छ भनेर बदल्नु चलिरहेको कन्फिगरेसन तोड्ने सामान्य तरिका हो। Active Directory मा प्रयोगकर्ता वस्तुहरूको पूर्वनिर्धारित स्थान Users नामको कन्टेनर हो, र कन्टेनर समान नामको संगठनात्मक एकाइजस्तै उही प्रकारको वस्तु होइन।
डाइरेक्टरी प्रशासकसँग खाताको वास्तविक विशिष्ट नाम सोध्नुहोस्, वा त्यो वस्तुबाटै पढ्नुहोस्। तलका दुवै आ-आफ्नो डाइरेक्टरीमा सही हुन सक्छन्, त्यसैले कुनै पनि सम्झनाबाट टाइप गर्नु हुँदैन।
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=exampleस्थानान्तरण वा नाम परिवर्तनले त्यो मान बदल्छ जबकि खाता र पासवर्ड वैध रहन्छन्, त्यसैले गत त्रैमासमा चलेको कन्फिगरेसन यो त्रैमासमा कसैले पनि प्रमाण नछोई असफल हुन सक्छ। कुनै पनि पुनर्गठनपछि कन्फिगर गरिएको स्ट्रिङलाई डाइरेक्टरीको हालको विशेषतासँग तुलना गर्नुहोस्। शान्त माइग्रेसनपछि पनि गर्नुहोस्, रिपोर्ट गरिएको अवरोधपछि मात्र होइन।
खोज आधार सेवा खाता होइन
bind पहिचान र खोज आधारले फरक प्रश्नको जवाफ दिन्छन्: प्लगइन कसको रूपमा प्रमाणीकरण गर्छ र मानिसहरूलाई कहाँ खोज्छ। सफल bind पछि कुनै मिल्दो प्रयोगकर्ता नहुनु क्षेत्र, फिल्टर वा पढ्ने अनुमतिको समस्या हो, र खाताको विशिष्ट नामलाई प्रयोगकर्ताहरूको आधारले बदल्दा त्यसमा केही बदलिँदैन।
सेवाले तपाईंले सम्पादन गरेको कन्फिगरेसन लोड गरेको छ र त्यसको अन्तिम बिन्दु, TLS विश्वास र प्रमाणीकरण मोड चलिरहेको प्रशासनिक परीक्षणसँग मिल्छ भनी पुष्टि गर्नुहोस्। अर्को खातासँग वा अर्को डोमेन नियन्त्रकविरुद्ध गरिएको हाते खोज समान प्रयोग होइन।
भण्डारण गरिएको रहस्य जाँच्नुहोस्, र खाता सक्षम, म्याद सकिएको वा लक भएको छ कि जाँच्नुहोस्, पासवर्ड कतै पनि नछापी। म्याद सकिने कुरा छुट्न सजिलो हुन्छ किनकि खाता काम नगर्ने दिनसम्म काम गरिरहन्छ। असम्बन्धित सेवाबाट हस्तान्तरण भएको लक पनि त्यत्तिकै शान्त हुन्छ। यी दुई अवस्थामध्ये कुनैले पनि सेवा खाताको नाम लिने सन्देश बनाउँदैन।
समूह नियम अन्तमा आउँछन्
bind सफल भएपछि अधिकार चल्छ, त्यसैले समूह जाँच bind असफलताको कारण हुन सक्दैन, र समूह आवश्यकता हटाएर त्यो सुधार्न सकिँदैन। लगइन अब समूह चरणमा पुग्छ भने, बाँकी समस्या सदस्यता हो, प्रमाण होइन।
त्रुटि हराउन सेवा खातालाई फराकिलो डाइरेक्टरी अधिकार दिनु सम्पूर्ण तैनाथीको पहुँच नीति बदल्छ। त्यसलाई आफ्नै समीक्षासहितको सुरक्षा निर्णय मान्नुहोस्, तपाईंले अझै पहिचानमा नतोकेको सन्देशको समाधान होइन।