Назад | Перейти на главную страницу

Ограничение доступа к веб-сайтам на основе членства в группах LDAP / Active Directory

Я пытаюсь настроить детальный контроль внешних веб-сайтов на основе членства наших пользователей и компьютеров в группах AD.

Обычно мы блокируем такие сайты, как YouTube, Facebook, MySpace и др., Но нашему отделу видео необходим доступ к YouTube; отделу маркетинга нужен доступ к Facebook и так далее. У нас также есть несколько компьютеров, на которых должен быть неограниченный доступ в Интернет. В настоящее время это администрируется с использованием статических IP-адресов, введенных в конфигурацию нашего брандмауэра, что отнимает много времени и подвержено ошибкам, и было бы намного проще сделать это через членство в группе AD, и оказалось, что наш существующий аппаратный брандмауэр не поддерживает этот сценарий :(

Итак, наши требования:

  1. Управляйте доступом НА УРОВНЕ ПОЛЬЗОВАТЕЛЯ к определенным веб-сайтам через членство в группе Active Directory. Пользователи, которые являются членами группы «Пользователи Facebook» в Active Directory, могут получить доступ к Facebook в рабочее время, независимо от того, какой компьютер они используют, а пользователи, которые НЕ являются членами «Пользователи Facebook», не должны иметь доступ к этому сайту в рабочее время. Мы хотим повторить это для 5-6 различных веб-сайтов и полностью управлять доступом через членство в группах AD.

  2. Контроль доступа на УРОВНЕ КОМПЬЮТЕРА к определенным веб-сайтам - т.е. я хотел бы иметь возможность сделать определенный компьютер домена членом группы «Пользователи Facebook», чтобы любой пользователь, использующий этот компьютер, имел доступ к Facebook, независимо от членства пользователя в группах AD.

В идеале все это полностью прозрачно для конечного пользователя - ему не нужно снова вводить свои сетевые учетные данные. Кроме того, настройка локального прокси-сервера и т. Д. Прекрасна, если им можно управлять через групповую политику.

Спасибо,

Дилан

MIcrosoft ForeFront TMG может сделать это с помощью локально установленного клиента межсетевого экрана или прозрачного прокси. Поскольку клиент знает личность компьютера И (!) Личность пользователя, для них могут быть определены правила.

Мы делаем это с Веб-фильтр Barracuda Network, который можно интегрировать с Active Directory. Вы также можете назначить определенные разрешения для определенных IP-адресов - достаточно легко убедиться, что один и тот же компьютер всегда имеет один и тот же IP-адрес в вашей сети с помощью DHCP или простой старой статической конфигурации. Мы выбрали это, потому что нам понравился отчет, и мы получили хорошую сделку.

Существует множество конкурирующих решений веб-фильтров, оборудования, программного обеспечения, программного обеспечения с открытым исходным кодом и даже облачных решений «Программное обеспечение как услуга», которые интегрируются с Active Directory - если они это сделают, они почти на 100% сделают то, что вам нужно.

Microsoft ISA Server сделает все это за вас, и он будет отлично работать как локальный прокси.

Это требует, чтобы клиент брандмауэра Microsoft был настроен на клиентских компьютерах для максимально прозрачной работы, но это легко сделать с помощью групповой политики.

Взгляните на Palo Alto Networks.

У нас есть один из их боксов, и он может делать почти то же самое, что вы только что описали, и делать это на уровне приложения, а не указывать URL-адреса для каждого веб-сайта.

Слово из толпы разработчиков ПО с открытым исходным кодом: я призываю использовать Squid Cache для выполнения того, что вы ищете.

Здесь вы можете увидеть некоторые документы по настройке и более старой версии Squid (которые все еще применимы к последним версиям Squid для Win32): http://www.papercut.com/kb/Main/InstallingAndConfiguringSquidNTProxy

На самом деле довольно легко настроить Squid для аутентификации в домене AD в Windows. После этого он просто настраивает файл squid.conf с желаемыми элементами управления доступом. Сначала это немного сбивает с толку, но как только вы сосредоточитесь на модели ACL Squid, вы обнаружите, что с ней можно делать некоторые действительно дикие вещи. Возможно смешивание списков ACL на основе IP-адреса источника (или имени DNS) с пользовательскими и временными ACL. Система ACL действительно очень мощная.

Internet Explorer поддерживает прозрачную аутентификацию NTLM для Squid (как, я полагаю, Chrome тоже). Я не верю, что Firefox или Safari еще сумели интегрировать эту функциональность. Однако для присоединенных к домену клиентов Windows, использующих IE, он «просто работает» прозрачно.

Я бы использовал скрипты автонастройки прокси вместо того, чтобы пытаться распространять настройки прокси с помощью групповой политики, сценариев и т. д. Сценарии автоматической конфигурации прокси очень удобны.

Если вы собираетесь ограничить доступ на основе членства в группах, вы можете убедиться, что эти группы обновляются динамически. В противном случае у вас все равно останутся билеты службы поддержки и ваши пользователи без надлежащего доступа.