Comments 15
У данного пользователя должно быть право на чтение принадлежности пользователей домена к доменным группам. Поэтому добавим пользователя в группу Organization Managment.
По умолчанию любой пользователь AD имеет право читать содержимое групп. И что именно заставляет пихать учетку сквида в группу, имеющую полный доступ к управлению MS Exchange (и не только) — неясно.
Генерируем keytab-файл на контроллере домена.
Зачем его генерировать на КД, почему не сгенерировать непосредственно на машине, где сквид стоит? А ktpass… -crypto all — это от нежелания разбираться, что там за буковки в алгоритмах шифрования?
По умолчанию любой пользователь AD имеет право читать содержимое групп.
У нас нет. Если у кого-то это так, то данный шаг можно пропустить.
Зачем его генерировать на КД, почему не сгенерировать непосредственно на машине, где сквид стоит?
Да, можно поставить mskutil или samba и генерировать на проксе. Без разницы, результат одинаковый
ktpass… -crypto all — это от нежелания разбираться, что там за буковки в алгоритмах шифрования?
Может я не достаточно проинформирован, но ничего плохого в -crypto all не вижу
У нас нет. Если у кого-то это так, то данный шаг можно пропустить.
Тут не "если у кого-то так", а почти у всех, кто будет читать вашу статью, именно так. Далее, у вас настолько жесткие ограничения по безопасности, что вы вручную ограничиваете права пользователей на чтение AD, но при этом вы советуете помещать учетку сквида в группу, имеющую крайне широкие права в домене и не имеющую вообще никакого отношения к происходящему, вместо того, чтобы просто дать ей права на чтение определенных групп? И всё это — на прокси (т.е. машине, которую обычно напрямую выставлют в инет)? "Всё чудесатее и чудесатее". (с)
Может я не достаточно проинформирован, но ничего плохого в -crypto all не вижу
Если вы абсолютно точно знаете, какой результат выполнения будет в вашей среде, то для вас может и не быть ничего плохого (хотя опять же непонятно, зачем в этом случае использовать all вместо явно заданного алгоритма). Проблема в том, что в случае, когда вы пишете статью для неопределенного круга читатетей, нельзя рассчитывать на то, что установки по умолчанию в их среде будут безопасными. И, соответственно, не стоит подталкивать к их использованию.
Зачем ещё одна?
— HTTP(S) доступ и статистика в одном месте;
— весь остальной доступ (ICMP, UDP, SIP, RTP и т.п.) и статистика в другом месте (и это уже так просто к AD группам не привяжешь);
То получается конструктор, который обеспечивает доступ в Интернет, но не обеспечивает защиту, и который может сопровождать только один человек — создатель (мало кто из нас любит писать подробную документацию, а потом еще и поддерживать ее).
P.S. Если сравнить потери компании от одного криптолокера, то стоимость коммерческого UTM + антивируса на рабочих станциях уже не кажется безумной (особенно при скорости Интернет каналов меньше 10-100 мбит).
На хабре есть несколько статей по этой теме.
P.S. Решения от Cisco или Check Point по возможностям сравнимы, но стоить будут дороже (из личного опыта).
Не думали на squid 5 переписать статью?
не работает по группам, т.к. squid сконфигурирован с поддержкой IPv6, если не выключать IPv6, то для работы потребуется явно указывать IPv4
вот пример
external_acl_type SQUID-INTERNET-FULL_ACCESS ttl=300 negative_ttl=60 ipv4 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -a -m 0 -S srv-m29-dc-03 -g SQUID-INTERNET-FULL_ACCESS -D BALT.LOCAL
Explicit Proxy c авторизацией по AD Group + Interception Proxy с авторизацией по MAC