Squid i zduplikowane nazwy użytkowników w katalogach LDAP

Jeśli dwa niezależne katalogi zawierają oba alex, serwer pośredniczący potrzebuje wyboru katalogu, zanim sprawdzi hasło. Próba najpierw A, a potem B ukrywa ten wybór w niepowodzeniu uwierzytelniania i może mylić niedostępny katalog z odrzuconym sekretem.

Dwa układy mogą uczynić tożsamość jawną:

• Logowanie kwalifikowane. Nazwa taka jak [email protected] wybiera przez dyspozytor stały katalog zdefiniowany przez administratora. Zachowaj tożsamość kwalifikowaną do autoryzacji i rejestrowania. Nie zamieniaj sufiksu dostarczonego przez klienta w dowolny adres serwera LDAP.
• Stabilny zaufany kontekst żądania. Katalog wybiera nasłuchiwacz lub inny obsługiwany kontekst. Zdefiniuj, co się dzieje, gdy osoba się przemieszcza lub używa innego nasłuchiwacza; położenie sieciowe nie jest tożsamością osobistą.

Repliki jednego katalogu są inne: dzielą jedną przestrzeń nazw tożsamości. Niepowiązane katalogi nie stają się replikami dlatego, że oba używają LDAP.

Dopasuj klucz pamięci podręcznej poświadczeń Squida do wyboru pomocnika. Odwołanie auth_param opisuje key_extras służące do przekazywania dodatkowego kontekstu i uwzględniania go w kluczu pamięci podręcznej, w tym przypadku identycznych nazw rozróżnianych przez port nasłuchu. Pomocnik musi rozumieć rozszerzone wejście, a wybrane makro musi być dostępne na tym etapie uwierzytelniania.

Preferuj stabilny kontekst. Często zmieniający się adres IP klienta może zwielokrotnić tożsamości w pamięci podręcznej i zmienić mechanizmy sterowania oczekujące jednej tożsamości użytkownika.

Zdefiniuj osobno nieznany katalog, nieznane konto, odrzucone hasło i niedostępny katalog. Konto North nie może po cichu stać się Alexem z South, gdy North jest niedostępny. Utrzymuj te wyniki rozróżnialne w dziennikach bez zapisywania haseł.