Squid і повторювані імена користувачів у каталогах LDAP

Якщо два незалежні каталоги обидва містять alex, посереднику потрібен вибір каталогу перед перевіркою пароля. Спроба спершу A, а потім B приховує цей вибір усередині збою автентифікації й може сплутати недоступний каталог із відкинутим секретом.

Два впорядкування можуть зробити ідентичність явною:

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

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

Узгодьте ключ кешу облікових даних Squid із вибором помічника. Довідка auth_param описує key_extras для передавання додаткового контексту та включення його до ключа кешу, зокрема випадок однакових імен, розрізнюваних портом прослуховування. Помічник має розуміти розширене введення, а вибраний макрос має бути доступним на цьому етапі автентифікації.

Надавайте перевагу стабільному контексту. Часто змінювана IP-адреса клієнта може розмножити ідентичності в кеші та змінити елементи керування, які очікують однієї ідентичності користувача.

Визначте окремо невідомий каталог, невідомий обліковий запис, відкинутий пароль і недоступний каталог. Обліковий запис North не повинен тихо ставати Alex із South, коли North недоступний. Тримайте ці результати розрізнюваними в журналах, не записуючи паролів.