Kerberos удостоверяване в SQUID, базирано на LDAP Active Directory групи, експериментален блог
Без тези статии и разбиране как squ />
Какво е LDAP в Active Directory (Въведение)
защотоLDAP все още е малка мистерия за мен. Ще ти кажа каквото знам. И така,LDAP е вид директория (буквално - олекотен протокол за достъп до директория, в превод - олекотен протокол за достъп до директория), която съхранява различна информация в дървовидна форма и има структура, в нашия пример (използвайки домейна AD.LOCAL):
Всекизапис в LDAP, независимо дали е обект или контейнер с обекти вътре, имауникално име за цялата LDAP директория (така нареченото английскоотличително име (DN) - отличително име). Това дори не е име, а път, който характеризира пълния път до този запис в цялата йерархия. Уникален път може да изглежда така (на примера на група squ >cn=squid, ou=groups, ou=UNIXs, dc=ad, dc=local ". Уникалното име се състои от едно или повечеОтносително отличително име, разделени със запетая. Относителното уникално име е във формата AttributeName=value (напр. cn=squid) На същото ниво на директория , не могат да съществуват два записа с еднакви относителни уникални имена (обаче има някои допълнителни ограничения в Active Directory, например не може да има потребител с едно и също име в цялото дърво).
Настройване на squid за Kerberos удостоверяване
Конфигурирането на squid за Kerberos удостоверяване трябва да се извърши съгласно статията Negotiate - метод за удостоверяване в squid. Следконфигуриране на Kerberos удостоверяване, определен прокси сървър на squid започва да работи за нас, който удостоверява домейнапотребители. Да предположим, че има някаква конфигурация:
Разбира се, в допълнение към squid.conf, трябва да имаме конфигурирани /etc/krb5.conf и други необходими конфигурации и, разбира се, Active Directory според статията.
Изходни данни
Конфигурацията на мрежата е както следва:
- Локална подмрежа - 10.0.0.0/16
- IP домейн контролер - 10.0.0.1
- Име на домейн - ad.local
- Име на контролера на домейн - dc.ad.local
- IP на хост с squid - 10.0.0.10
Използване на LDAP групи от Active Directory
Всъщност,защо трябва да използваме LDAP групи от Active Directory? Можем просто да създадем необходимите acl списъци с потребители, добавени там, например
. но това е приемливо, когато има 10-30 потребители в мрежата и не се налага често да ги стартирате. Ако имате повече потребители и голямо текучество на персонала, става ужасно неудобно ръчно да добавяте имена към acl и да помните кой трябва да бъде премахнат/сменен. След това рестартирайте/презаредете squid, което също причинява неудобство за работещите в момента потребители. Много по-лесно е да добавите потребител към AD и да го включите в определена група, в резултат на което той автоматично получава достъп до глобалната мрежа с параметрите, посочени за групата, и изобщо не докосва калмари.
За достъп доLDAP Active Directory, в squ. Как да разберете с какви опции е построен squid, написах в първата статия за squid.
Конфигуриране на Active Directory за използване на групи
По подразбиране AD не позволява на анонимни потребители да извличат информация от директорията. За да може squidпомощникът squid_ldap_group да има право на достъп доActive Directory и да извлече част от информацията от структурата на домейна,трябва да предоставите на помощника някои идентификационни данни за достъп до LDAP. За да направя това, създадох акаунт в домейна с минимално необходимите права (членство в групата Domain Users - Domain Users) (. Групата Domain Guests може да е достатъчна.). Името на акаунта в моя пример ще бъде [email protected],Важно задайте настройката за предотвратяване на промяна на паролата и премахнете ограничението за изтичане на паролата, когато създавате акаунта.За удобство създавам всички групи и потребителски и компютърни акаунти, използвани за интегриране на услуги на Linux в Kerberos инфраструктурата в контейнера на UNIX в подконтейнерите групи, потребители, хостове, съответно.
Разбира се, трябва да създадем (например)2 потребителски групи. 1 е група, която има достъп до интернет без ограничения за достъп (нареченаsquid ), 2 е група, която има достъп само до списъка с любими сайтове (нареченаsquid-list ). Можете да създадете колкото искате групи с различни настройки, но 2x ще са достатъчни за пример.
Свързване на помощника squid_ldap_group към Active Directory
Командата по-долу е събрана от различни източници в мрежата, така че някои параметри ще останат без ясно описание (за съжаление).
Нека разгледаме пример за настройка натестова връзка на squid_ldap_group помощник с LDAP директория AD :
Нека да разгледаме какво направихме в тази команда (всички параметри са описани в man squid_ldap_group):
буквално - не следвай реферали. В превод - не знам Работи и без него. Но те казват, че намалява натоварването на AD.
указва филтър за търсене за групата, от която се нуждаем (memberOf=cn=%a), който се намира по пътя ou=groups,ou=UNIXs,dc=ad,dc=local. В този филтър променливата %v се заменя с иметопотребител (без да се указва @AD.LOCAL или AD\ домейн), а променливата %a се заменя с исканата група. защото в LDAP съм почти нула, така че не давам разумно обяснение за този филтър. Съответно, ако вашата група (чието членство трябва да се провери) се намира в някакъв Linux контейнер в домейна primer.domen.local, тогава този филтър ще изглежда така: -f "(&(object >
указва потребителското име, от което се осъществява връзката към AD директорията.
указва пътя до файла, който съхранява паролата на акаунта от опцията -D. Трябва да зададете собственик на този файл - потребителят, под който работи squid (обикновено прокси) и да зададете права за достъп за четене само за собственика.
По-нататък в списъка се опитвам да проверя дали тестът на потребителя на домейна съответства на домейн групата squid-list, към която той наистина принадлежи. По този начин се опитвам да посоча потребителското име в различни формати. Както можете да видите, помощникътsquid_ldap_group правилно приема само името, без да посочва частта на домейна. Какво ни казва линията:
Последният опит се опитвам да проверя дали потребителят ivanov принадлежи към посочената група от squid-list, докато ivanov всъщност не е включен в тази група. Съответно неуспешните опити ни връщат ERR стойността.
Ако на тази стъпка е било възможно да се свърже помощникът с AD и с правилния потребителски и групов вход, помощникът отговаря правилно - OK, тогава нещата се движат в правилната посока и можете да започнете да конфигурирате squid. В противен случай е необходимо да се разберат причините за проблемите.
Ако тази схема се приложи към нашия домейн и нашата задача, получаваме нещо като следната конфигурация:
Нека да разгледаме получената конфигурация. Както можете да видите, параметъръте добавенexternal_acl_type, който принуждава sqiud да получи достъп до LDAP директорията, разположена на домейн контролера dc.ad.local, чрез помощника за удостоверяване на squ >Negotiate Kerberos, получаваме потребителското име във формата user@DOMAIN, а помощникът squid_ldap_group използва имена във формат потребител (тоест без частта за домейна). И така, ключът -K караsquid_ldap_group да "отреже" @DOMAIN частта от името и да сравни правилно потребителското име и групата.
След това виждаме, че има 3 новиacl - потребители, потребителски списък и бял списък, които проверяват дали потребителят принадлежи към група, наречена squid, към група, наречена squid-list, и съответно задава белия списък със сайтове. В същото време би било по-ясно да се каже за първите 2 acl, че те предават във external_acl_type с името ldap_verify името на групата, към която трябва да принадлежи удостовереният потребител.
И последното нещо е появата надва http_access параметъра, които позволяват достъп до acl именувани потребители и acl именувани потребители-списък, когато тези потребители имат достъп до сайтове от acl белия списък. Освен това параметърът http_access enable allusers беше премахнат, което позволи достъп на всички удостоверени потребители.
Можете да сложите край на това в настройката. Рестартираме squid и нашите потребители, които са членове на групите домейни squid и squid-list, могат да работят в Интернет.
При прилагането на тази схема се сблъсках с някои нюанси, които не бива да се пренебрегват:
-
ако потребителят принадлежи към няколко групи, на които е предоставен достъп до интернет в конфигурационния файл squ /> Всеки от OU (Складове, Персонал, Адвокати и други отдели на същото ниво) има свои собствени групи, подчинени на тях, включително потребители, подчинени на тях (отделите).Тоест отделът за покупки има подчинен обект за покупки, който е група, която включва всички потребители на отдела, и ако тази група е включена в група с име squ >Резюме
В тази статия ние, и аз се надявам вие, успяхме да принудим squid, използвайки помощника squid_ldap_group, да извлече информация от Active Directory за принадлежността на потребителя към дадена група и въз основа на тази информация да предостави или не предостави достъп до интернет. В същото време също е възможно групите да задават настройки за скорост чрез пулове за забавяне и много други настройки и ограничения за достъп до Интернет, базирани на управлението на списъците за достъп на acl. До нови статии!