Squid en dubbele gebruikersnamen over LDAP-directory's

Als twee onafhankelijke directory's beide alex bevatten, heeft de proxy een directorykeuze nodig voordat hij een wachtwoord controleert. Eerst A en dan B proberen verbergt die keuze in de authenticatiefout en kan een niet-beschikbare directory verwarren met een geweigerd geheim.

Twee regelingen kunnen de identiteit expliciet maken:

• Gekwalificeerde aanmelding. Een naam zoals [email protected] selecteert via een dispatcher een vaste, door de beheerder gedefinieerde directory. Behoud de gekwalificeerde identiteit voor autorisatie en logging. Maak van een door de client aangeleverde suffix geen willekeurig LDAP-serveradres.
• Stabiele vertrouwde verzoekcontext. Een listener of een andere ondersteunde context selecteert de directory. Definieer wat er gebeurt als iemand rondreist of een andere listener gebruikt; netwerklocatie is geen persoonlijke identiteit.

Replica's van één directory zijn anders: ze delen één identiteitsnaamruimte. Onverwante directory's worden geen replica's omdat beide LDAP gebruiken.

Laat de cachesleutel van Squids inloggegevens overeenkomen met de keuze van de helper. De auth_param-referentie beschrijft key_extras voor het doorgeven van extra context en het opnemen daarvan in de cachesleutel, inclusief het geval van identieke namen die door de luisterpoort worden onderscheiden. De helper moet de uitgebreide invoer begrijpen, en de gekozen macro moet in die authenticatiefase beschikbaar zijn.

Geef de voorkeur aan stabiele context. Een vaak wisselend client-IP kan cache-identiteiten vermenigvuldigen en besturingen wijzigen die één gebruikersidentiteit verwachten.

Definieer onbekende directory, onbekend account, geweigerd wachtwoord en niet-beschikbare directory afzonderlijk. Het account van North mag niet stilzwijgend het Alex van South worden wanneer North niet beschikbaar is. Houd die uitkomsten onderscheidbaar in logboeken zonder wachtwoorden vast te leggen.