Squid и дупликат кориснички имиња во LDAP именици
Дизајнирајте го изборот на именик и кешот за автентикација на Squid заедно кога независни LDAP именици содржат исто кратко корисничко име.
Ако два независни именика и двата содржат alex, на проксито му треба избор на именик пред да провери лозинка. Обидот прво A па B го крие тој избор во неуспехот на автентикацијата и може да збуни недостапен именик со одбиена тајна.
Два распореди можат да го направат идентитетот експлицитен:
- Квалификувана најава. Име како
[email protected]преку диспечер избира фиксен именик определен од администраторот. Зачувајте квалификуваниот идентитет за авторизација и евидентирање. Не претворајте наставка доставена од клиентот во произволна адреса на LDAP сервер. - Стабилен доверлив контекст на барање. Именикот го избира слушател или друг поддржан контекст. Определете што се случува кога човек се движи или користи друг слушател; мрежната локација не е личен идентитет.
Репликите на еден именик се различни: тие делат простор од имиња на идентитети. Неповрзаните именици не стануваат реплики затоа што и двата користат LDAP.
Усогласете го клучот на кешот за акредитиви на Squid со изборот на помошникот. Референцата auth_param го опишува key_extras за пренесување дополнителен контекст и негово вклучување во клучот на кешот, вклучувајќи го случајот на идентични имиња разграничени по портата за слушање. Помошникот мора да го разбере проширениот влез, а избраниот макро мора да биде достапен во таа фаза на автентикација.
Претпочитајте стабилен контекст. Често променливата IP адреса на клиентот може да ги умножи идентитетите во кешот и да ги промени контролите што очекуваат еден кориснички идентитет.
Одделно дефинирајте непознат именик, непозната сметка, одбиена лозинка и недостапен именик. Сметката на North не смее тивко да стане Alex на South кога North е недостапен. Одржете ги тие резултати различливи во евиденциите без запишување лозинки.