એ 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 નિષ્ફળતાનું કારણ ન હોઈ શકે, અને જૂથ આવશ્યકતા દૂર કરવાથી તે સુધરી શકતું નથી. જો લોગિન હવે જૂથ તબક્કે પહોંચે છે, તો બાકીની સમસ્યા સભ્યપદ છે, ઓળખપત્ર નહીં.
ભૂલ અદૃશ્ય થાય તે માટે સેવા ખાતાને વિશાળ ડિરેક્ટરી અધિકાર આપવાથી આખા જમાવટની ઍક્સેસ નીતિ બદલાય છે. તેને પોતાની સમીક્ષા સાથેનો સુરક્ષા નિર્ણય ગણો, તમે હજી ઓળખને આભારી ન કરેલા સંદેશ માટેનો ઉપાય નહીં.