Squid en dubbele gebruikersname oor LDAP-gidse

As twee onafhanklike gidse albei alex bevat, het die proxy 'n gidskeuse nodig voordat dit 'n wagwoord nagaan. Om eers A en dan B te probeer, versteek daardie keuse in die verifikasiefout en kan 'n onbeskikbare gids met 'n verkeerde wagwoord verwar.

Twee reëlings kan die identiteit eksplisiet maak:

• Gekwalifiseerde aanmelding. 'n Naam soos [email protected] kies deur 'n verspreider 'n vaste gids wat deur die administrateur bepaal is. Behou die gekwalifiseerde identiteit vir magtiging en logboeke. Moenie 'n kliëntverskaffde agtervoegsel in 'n willekeurige LDAP-bedieneradres verander nie.
• Stabiele vertroude versoekkonteks. 'n Luisteraar of 'n ander ondersteunde konteks kies die gids. Definieer wat gebeur wanneer iemand rondbeweeg of 'n ander luisteraar gebruik; netwerklokasie is nie persoonlike identiteit nie.

Replikas van een gids is anders: hulle deel 'n identiteitsnaamruimte. Onverwante gidse word nie replikas omdat albei LDAP gebruik nie.

Laat die sleutel van Squid se getuigskrifkas met die helper se keuse ooreenstem. Die auth_param-verwysing beskryf key_extras vir die deurgee van ekstra konteks en die insluiting daarvan in die kassleutel, insluitend die geval van identiese name wat deur die luisterpoort onderskei word. Die helper moet die uitgebreide invoer verstaan, en die gekose makro moet in daardie verifikasiefase beskikbaar wees.

Verkies stabiele konteks. 'n Kliënt-IP wat dikwels verander, kan kas-identiteite vermeerder en beheer verander wat een gebruikersidentiteit verwag.

Definieer onbekende gids, onbekende rekening, verkeerde wagwoord en onbeskikbare gids afsonderlik. Noord se rekening moet nie stilweg Suid se Alex word wanneer Noord onbeskikbaar is nie. Hou daardie uitkomste onderskeibaar in logboeke sonder om wagwoorde aan te teken.