Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Спасибо за статью. Еще бы SAMS добавить
Жмем правой клавишей мыши на корне нашего домена, выбираем Делегирование управления. Появляется мастер настройки. Жмем Далее. Жмем Добавить. Пишем нашего пользователя squid, который будет иметь права чтения из домена. Жмем ОК. Добавился наш пользователь. Жмем Далее. Включаем Чтение информации о всех пользователях и Чтение всей информации для intOrgPerson. Жмем Далее. Жмем Готово.
Зачем? Не хватило стандартного набора прав пользователя? Вполне должно было хватить для описанных в статье действий.
Кстати, стоит не забыть установить созданному пользователю не истекающий пароль.
Авторизацию в squid будем использовать на основе LDAP. Для этого сначала необходимо проверить соединение с Win2008AD механизмом LDAP, который заложен в Squid.
А вот это плохо:
- Вы создаёте лишнюю нагрузку на контроллер домена — при каждой аутентификации пользователя на прокси — squid будет делать авторизацию от его имени в AD. При количестве пользователей более 100 это создаст кучу мусора в журнале безопасности (у вас ведь настроен аудит!). А при более 1000 — нагрузку на контроллер.
- При отказе контроллера имя которого задано в конфигурации squid перестанет работать (в принципе это разрешимо...)
- Пользователю для доступа в интернет придётся вводить пароль --> пользователи будут сохранять свой пароль в хранилищах браузеров --> это не безопасно + пользователей будет лочить после смены пароля и они будут выедать вам мозг
Гораздо:
- безопасней (не будет служебной учётки пользователя с не истекающим паролем, пользователи не будут хранить свои доменные пароли в хранилище браузеров, авторизация будет проходить с использованием более безопасного механизма)
- надёжней (squid будет работать с любым доступным контроллером домена)
- удобней (и для пользователя и для админа)
настроить авторизацию посредством kerberos (что-то как-то так: wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos)
SSO это конечно здорово, но как быть с группами в таком случае? все равно использовать ldap для этого? если есть какой мануал, то ткните носом плиз.
Вот годная статья по настройке аутентификации kerberos с авторизацией по группам ldap www.k-max.name/linux/squid-auth-kerberos-ldap-grupp-active-directory/
К сожалению там архитектурно не получится вытянуть из билета членство в группах…
К сожалению там архитектурно не получится вытянуть из билета членство в группах…
Скорость авторизации из 100-300 юзеров меня устраивает. Ничего не тормозит. Хотел сделать на основе кербероса, но мне это оказалось быстрее и практичнее. Т.к. нужно авторизовать юзера именно по паролю, а потом если надо еще и по мак адресу.
не забудьте сказать что фильтр по MAC будет рабтоать если прокси в одной сети с клиентами
А вот с группами скорее всего придётся использовать ldap… но ldap будет использоваться только для acl:
- будет в 2 раза меньше bind операций (только bind служебного пользователя)
- авторизация пользователя будет работать прозрачно
- можно будет подумать над кэшированием результатов ldap запросов...
У меня одна сеть и группы все в ней, ну это и так должно быть понятно.
Но если никто не понял это можно дописать. Но как я понял основная масса настраивает по своему и это высказывают.
Но если никто не понял это можно дописать. Но как я понял основная масса настраивает по своему и это высказывают.
Работать не будет, ни где не было указано, что надо открыть iptables на порт 3128
Я не указал это в посте, но это следует из потребностей службы squid.
Позанудствую, но вы указали столько команд, которые следуют из потребностей службы сквида, включая yum install, chkconfig, service start, но ни словом не обмолвились про ключевую операцию открытия порта в брандмауэре — думается мне, вы просто забыли это сделать.
Администратор с опытом поймет интуитивно, но новичок, наткнувшийся на ваш мини гайд разобьет себе голову.
Тягу к минусованию бы в наблюдательность.
Администратор с опытом поймет интуитивно, но новичок, наткнувшийся на ваш мини гайд разобьет себе голову.
Тягу к минусованию бы в наблюдательность.
Ужас то какой, блин.
0. Вот у меня есть RDP ферма, где работает 80% сотрудников организации с тонких клиентов — как по Вашему мануалу я им разграничу уровни доступа? Учитывая, что это не VDI, а именно RDP и я не хочу привязывать каждую учётку в AD к каждому серверу и думать про балансировку нагрузки на несколько десятков серверов для нескольких сотен пользователей.
1. Squid прекрасно авторизуется в AD через самбу, которую можно ввести в AD и для этого таки да, понадобится учётка админа или кому там у Вас разрешён join машин в домен.
2. Сквид прекрасно кушает группы пользователей AD для настройки им доступа и ограничения скорости (социалки, реклама, поиск работы, аськи/скайпы), авторизацию по макам -глупо, сейчас нормальные люди делают это исключительно для привязки IP, NAP и в AD, автонастройка порта коммутатора при валидной авторизации юзера.
3. в нормальной инфраструктуре — юзеру должно быть всё равно, с какой рабочей станции работать.
статье минус.
У меня лежит где-то мануал с одной из прошлых работ, как раз по мною описанной настройке прокси сервера, что ли его оформить в статью
0. Вот у меня есть RDP ферма, где работает 80% сотрудников организации с тонких клиентов — как по Вашему мануалу я им разграничу уровни доступа? Учитывая, что это не VDI, а именно RDP и я не хочу привязывать каждую учётку в AD к каждому серверу и думать про балансировку нагрузки на несколько десятков серверов для нескольких сотен пользователей.
1. Squid прекрасно авторизуется в AD через самбу, которую можно ввести в AD и для этого таки да, понадобится учётка админа или кому там у Вас разрешён join машин в домен.
2. Сквид прекрасно кушает группы пользователей AD для настройки им доступа и ограничения скорости (социалки, реклама, поиск работы, аськи/скайпы), авторизацию по макам -глупо, сейчас нормальные люди делают это исключительно для привязки IP, NAP и в AD, автонастройка порта коммутатора при валидной авторизации юзера.
3. в нормальной инфраструктуре — юзеру должно быть всё равно, с какой рабочей станции работать.
статье минус.
У меня лежит где-то мануал с одной из прошлых работ, как раз по мною описанной настройке прокси сервера, что ли его оформить в статью
Оформляйте.
заодно опишите как побороть тормоза winbind при большом количестве пользователей.
0. У меня RDP фермы, и не планируется, сотрудников 200 человек, физические компы, соединения лишние и не планируется далее.
1. Мне зачем нужна Самба на роутере, только для закачки авторизации? Мне не надо.
2. Кушает сейчас, и не спрашивает добавки. Когда денег выделяется выше кармана, то можно рулить и свичами, но тут тупо надо любому юзеру со своим паролем зайти в инет, а привилегированным иметь полные права, но они слабы на передок и могут рассказать пароль другим вот им и установлен мак фильтр…
3. В нормальной да, а у меня все сделано предыдущими через… опу, и приходится применять хоть как то разнообразие, чтобы привести к уму.
п.с. Можно ставить хоть 5ть минусов статье.
1. Мне зачем нужна Самба на роутере, только для закачки авторизации? Мне не надо.
2. Кушает сейчас, и не спрашивает добавки. Когда денег выделяется выше кармана, то можно рулить и свичами, но тут тупо надо любому юзеру со своим паролем зайти в инет, а привилегированным иметь полные права, но они слабы на передок и могут рассказать пароль другим вот им и установлен мак фильтр…
3. В нормальной да, а у меня все сделано предыдущими через… опу, и приходится применять хоть как то разнообразие, чтобы привести к уму.
п.с. Можно ставить хоть 5ть минусов статье.
0. У многих рдп ферм и не планируется, но делать лучше изначально по человечески.
1. Самба? на роутере? извините, по хорошему, прокси сервер стоит отделять от маршрутизатора.
2. Разглашение личного пароля другим элементарно вычисляется по логам, после чего докладная на стол руководству это раз, а а нагромождение лишних сущностей усложняет сложность системы
1. Самба? на роутере? извините, по хорошему, прокси сервер стоит отделять от маршрутизатора.
2. Разглашение личного пароля другим элементарно вычисляется по логам, после чего докладная на стол руководству это раз, а а нагромождение лишних сущностей усложняет сложность системы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CentOS 6.x 64 и Squid с авторизацией из Win2008AD