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