ეს 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-ის ჩავარდნის მიზეზი და ჯგუფის მოთხოვნის მოხსნა ვერ გამოასწორებს მას. თუ შესვლა ახლა ჯგუფის ეტაპს აღწევს, დარჩენილი პრობლემა წევრობაა და არა სერთიფიკატები.
სერვისის ანგარიშისთვის ფართო დირექტორიის უფლებების მიცემა, რათა შეცდომა გაქრეს, ცვლის მთელი განლაგების წვდომის პოლიტიკას. მოეკიდეთ ამას, როგორც უსაფრთხოების გადაწყვეტილებას საკუთარი მიმოხილვით და არა როგორც შეტყობინების შესწორებას, რომელიც ჯერ იდენტობას არ მიგიწერიათ.