ആ 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 പരാജയത്തിന്റെ കാരണം ഗ്രൂപ്പ് പരിശോധനയാകാൻ കഴിയില്ല, ഗ്രൂപ്പ് ആവശ്യകത നീക്കം ചെയ്യുന്നത് അത് പരിഹരിക്കുകയുമില്ല. ലോഗിൻ ഇപ്പോൾ ഗ്രൂപ്പ് ഘട്ടത്തിലെത്തുന്നുവെങ്കിൽ, ബാക്കിയുള്ള പ്രശ്നം അംഗത്വമാണ്, ക്രെഡൻഷ്യലുകളല്ല.
പിശക് അപ്രത്യക്ഷമാകാൻ സേവന അക്കൗണ്ടിന് വിശാലമായ ഡയറക്ടറി അവകാശങ്ങൾ നൽകുന്നത് മുഴുവൻ വിന്യാസത്തിന്റെയും ആക്സസ് നയം മാറ്റുന്നു. അതിനെ സ്വന്തം അവലോകനത്തോടെയുള്ള സുരക്ഷാ തീരുമാനമായി കാണുക, നിങ്ങൾ ഇതുവരെ ഒരു ഐഡന്റിറ്റിക്ക് ആരോപിക്കാത്ത സന്ദേശത്തിനുള്ള പരിഹാരമായി അല്ല.