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