Squid и повторяющиеся имена пользователей в каталогах LDAP

Если два независимых каталога оба содержат alex, прокси нужен выбор каталога до проверки пароля. Попытка сначала A, а затем B скрывает этот выбор внутри сбоя аутентификации и может спутать недоступный каталог с отклонённым секретом.

Два порядка могут сделать идентичность явной:

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

Реплики одного каталога отличаются: они совместно используют пространство имён идентичности. Несвязанные каталоги не становятся репликами из-за того, что оба используют LDAP.

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

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

Определите отдельно неизвестный каталог, неизвестную учётную запись, отклонённый пароль и недоступный каталог. Учётная запись North не должна молча становиться Alex из South, когда North недоступен. Держите эти результаты различимыми в журналах, не записывая пароли.