Тази грешка с паролата за LDAP може изобщо да не е паролата на потребителя
Неуспешно свързване може да идва от служебния акаунт или от обхвата на търсенето, а не от потребителя. Разделете свързванията, преди някой да си смени паролата.
Нулирането на паролата на потребител е грешният първи ход, когато журналът казва само, че свързване е било отказано. При плъгин за директория в едно влизане има повече от едно свързване и отказът може да принадлежи на служебния акаунт, който извършва търсенето. Нулирането на идентификационните данни на потребителя в този случай не променя нищо. Освен това заключва човек, който никога не е бил проблемът.
Едно влизане, няколко свързвания
Конфигурация с отделен акаунт за директория обикновено изпълнява четири стъпки по ред и всяка от тях може да прекрати влизането.
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 или при свързване като служебния акаунт. Съобщението от високо ниво за парола се генерира по-късно и не носи информация коя самоличност е участвала. Затова текстът на грешката сам по себе си не може да ви каже дали е отказан потребителят, или служебният акаунт.
Прочетете редовете преди съобщението и отбележете момента, в който е настъпил отказът. Отказ при стартиране, преди да е пристигнал някой потребител, сочи към конфигурирания акаунт или към крайната точка. Отказ, който се появява само за един човек след успешно търсене, сочи към записа на този човек или състоянието на акаунта му.
Свържете грешката със самоличност
Практическото правило е да записвате три неща заедно: кога се е провалило, коя операция е текла и коя самоличност е била представена. Без тази тройка две много различни повреди изглеждат еднакво в журнал, който пази само последното изречение.
| 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 |
Ако конфигурираният акаунт се провали, прегледайте този акаунт и връзката, преди да докоснете какъвто и да е потребителски запис. Ако свързването на потребителя се провали след успешно търсене, разгледайте записа, който търсенето е върнало, а не този, който сте предполагали, че ще върне. Двата пътя споделят съобщение и нищо друго. Запишете кой от тях сте изключили, защото следващият човек ще попита точно това.
Отличителното име е данни, а не догадка
Промяната на компонент от името, защото изглежда непознат, е често срещан начин да се счупи работеща конфигурация. Подразбиращото се място за потребителски обекти в Active Directory е контейнер с име Users и контейнерът не е същият вид обект като организационна единица с подобно име.
Попитайте администратора на директорията за действителното отличително име на акаунта или го прочетете от самия обект. И двете от следните могат да бъдат правилни в собствената си директория, затова нито едно от тях не бива да се въвежда по памет.
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example
Преместването или преименуването променя тази стойност, докато акаунтът и паролата остават валидни, така че конфигурация, работила предишното тримесечие, може да се провали в това, без някой да е докоснал идентификационни данни. Сравнете конфигурирания низ с текущия атрибут на директорията след всяка реорганизация. Направете го и след тиха миграция, не само след докладван прекъс.
Обхватът на търсене не е служебен акаунт
Самоличността за свързване и обхватът на търсене отговарят на различни въпроси: като кого се удостоверява плъгинът и къде търси хора. Успешно свързване, след което няма съответстващ потребител, е проблем с обхвата, филтъра или правата за четене и замяната на отличителното име на акаунта с базата на потребителите не променя нищо в това отношение.
Потвърдете, че услугата е заредила конфигурацията, която сте редактирали, и че нейните крайна точка, доверие в TLS и режим на удостоверяване съвпадат с работещ административен тест. Ръчна проверка с друг акаунт или срещу друг контролер на домейн не е равностойен експеримент.
Проверете запазената тайна и проверете дали акаунтът е включен, изтекъл или заключен, без да отпечатвате паролата никъде. Изтичането се пропуска лесно, защото акаунтът продължава да работи до деня, в който вече не. Заключване, наследено от несвързана услуга, е също толкова тихо. Нито едно от двете условия не създава съобщение, което да назове служебния акаунт.
Правилата за групи идват последни
Оторизацията се изпълнява след успешните свързвания, така че проверка на група не може да е причина за неуспешно свързване и премахването на изискването за група не може да го поправи. Ако влизането вече стига до етапа на групите, останалият проблем е членство, а не идентификационни данни.
Даването на широки права в директорията на служебния акаунт, за да изчезне грешката, променя политиката за достъп на цялото разгръщане. Третирайте това като решение за сигурност със собствен преглед, а не като поправка на съобщение, което още не сте приписали на самоличност.