Squid и повтарящи се потребителски имена в LDAP директории

Ако две независими директории съдържат alex, проксито се нуждае от избор на директория, преди да провери парола. Опитването първо на A, после на B скрива този избор в неуспеха на удостоверяването и може да обърка недостъпна директория с отхвърлена тайна.

Две подредби могат да направят идентичността явна:

• Квалифициран вход. Име като [email protected] избира чрез диспечер фиксирана директория, определена от администратора. Запазете квалифицираната идентичност за оторизация и журналиране. Не превръщайте подаден от клиента суфикс в произволен адрес на LDAP сървър.
• Стабилен доверен контекст на заявката. Слушател или друг поддържан контекст избира директорията. Определете какво се случва, когато човек се мести или използва друг слушател; мрежовото местоположение не е лична идентичност.

Репликите на една директория са различни: те споделят пространство от имена на идентичности. Несвързаните директории не стават реплики, защото и двете използват LDAP.

Направете ключа на кеша за идентификационни данни на Squid съгласуван с избора на помощника. Справката auth_param описва key_extras за предаване на допълнителен контекст и включването му в ключа на кеша, включително случая на еднакви имена, разграничени от порта за слушане. Помощникът трябва да разбира разширения вход и избраният макрос трябва да е наличен на този етап на удостоверяване.

Предпочитайте стабилен контекст. Често променящият се IP на клиента може да умножи идентичностите в кеша и да промени контроли, които очакват една потребителска идентичност.

Дефинирайте отделно неизвестна директория, неизвестен акаунт, отхвърлена парола и недостъпна директория. Акаунтът на North не трябва тихо да става Alex на South, когато North е недостъпен. Пазете тези резултати различими в журналите, без да записвате пароли.