Ограничить доступ к файловой шаре для региональных пользователей [Версия для КПК]

Показать полную графическую версию : Ограничить доступ к файловой шаре для региональных пользователей

Nerian

24-06-2008, 19:55

Всем привет!

Есть домен контролер, на нём же расположена общая файловая шара.
Стоит задача запретить всем пользователям из региональной сети (к примеру 192.168.100.0) обрашаться к файловой шаре.

Загвоздка вот в чём: простым фаерволом, или переписыванием роутинга это сделать неполучается потому как при этом отлетает доступ к sysvol/netlogon - и всё - прошай GPO и тд и тп.

Как быть? Блокировать надо именно по сети, не по пользователям... А денег на новый файловый сервер чтоб туда перенести невыделяют...

Подсобите чем сможите :)

Кстате.. В принципе есть второй домен контролер. И было бы чудно если бы я смог заставить сеть 192.168.100.0 (региональную) использовать его.

Dirk Diggler

24-06-2008, 22:58

топологию сети обрисуйте

Кстате.. В принципе есть второй домен контролер. И было бы чудно если бы я смог заставить сеть 192.168.100.0 (региональную) использовать его. »
а в чем проблема? используйте

Nerian

24-06-2008, 23:46

Топология сети к примеру такая:

192.168.1.0/24 -> серверное оборудование в москве
192.168.2.0/24 -> пользователи в москве
192.168.3.0/24 -> пользователи в москве
192.168.100.0/24 -> пользователи питер
192.168.101.0/24 -> пользователи екатеренбург

В москве находяться к примеру следующие сервера:

192.168.1.2 - dc01 (контролер1, он же файловая шара)
192.168.1.3 - dc02 (контролер2, резервный)
192.168.1.4 - ts01 (терминальный сервер)

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

Задача: запретить региональным пользователям с десктопов обрашаться к файловой шаре на dc01, при этом оставив возможность использовать GPO (sysvol, netlogon)

Вот. В краце топология.

HLT

25-06-2008, 09:16

Всех региональных пользователей - в отдельную группу, например Regional Users
Этой группе - deny на шару

Nerian

25-06-2008, 10:37

Не подходит по ряду причин:

1. У них одинаковый логин что на терминале, что на общих десктопах. (поэтому при запрете группе, мы запретим им доступ из терминала тоже)
2. Во вторых - случаются случае когда сотрудники из москвы приезжают к сотрудникам в регион с ноутбуками - и у них тоже не должно быть доступа к шаре, он должен быть только через терминал.

Какие ещё будут идеи?

madmax24

25-06-2008, 10:46

У них одинаковый логин что на терминале, что на общих десктопах. (поэтому при запрете группе, мы запретим им доступ из терминала тоже) »
У меня и вопрос и предложение: а при логине на терминалку, я полагаю, можно создать ГП, которая открывает права пользователю, при выходе из терминалки - закрывает. Может так подойдет? Правда не представляю насколько это геморойно организовать и насколько глючно это будет отрабатывать.

Nerian

25-06-2008, 10:56

Не... Это воопще не вариант... На терминалках то есть свой GP для пользователей в терминальном окружении.

monkkey

25-06-2008, 11:37

он должен быть только через терминал »
Ну, и дайте права доступа только пользователям терминала (если нет ОУ - создайте его)

Nerian

25-06-2008, 11:59

К пользователю это дело не привяжешь. т.к. приедит туда москвоский который с ноутбуком тут, и получит теже самые права там, без терминала.

Может можно как нибудь указать что для 192.168.100.0/х и 192.168.101.0/х использовать dc02

artem_

26-06-2008, 15:10

В каждую сетку по bdc - и перекрыть файрволами доступ к файлам и папкам в центральном офисе.
Ну а контроллерам разрешить - понятное дело.

Nerian

26-06-2008, 15:27

Всего то делов =))) Купить 20 серверов для 20 регионов, и наверное ещё нанять человека который бы их поддерживал. Супер решиние :) Спасибо. Как я сам к нему не пришёл? )

Gremlin19

26-06-2008, 17:46

http://waynes-world-it.blogspot.com/2008/03/wmi-filter-for-subnet-filtered-group.html
как думаешь? :)

Dirk Diggler

26-06-2008, 19:03

192.168.1.2 - dc01 (контролер1, он же файловая шара)
192.168.1.3 - dc02 (контролер2, резервный)
192.168.1.4 - ts01 (терминальный сервер)

У пользователей в москве - десктопы, которые полноценно используют файловую шару на прямую
У пользователей в питербурке и екатеренбурге терминальные клиенты через которые они используют файловую шару
а так же... есть несколько десктопов, к примеру для локального сканирования.
Задача: запретить региональным пользователям с десктопов обрашаться к файловой шаре на dc01, при этом оставив возможность использовать GPO (sysvol, netlogon)
Вот. В краце топология. »
Навскидку не вспомню, но - закрываем 192.168.1.2 для регионов для любый IP-пакетов, кроме DNS(если он используется в кач-ве DNS).
Далее - либо клиенты автоматически будут использовать второй контроллер, либо для этого понадобятся небольшие пляски, но ничего сложного емнип. Возьмите пару мануалов по AD, например Зубанова, и в путь.

amel27

27-06-2008, 13:13

Купить 20 серверов для 20 регионов »достаточно шару убрать с DC на файл-сервер

до кучи еще один извращенческий вариант :) : создать специальную учетку с доступом только к этой шаре, создать ГПО с WMI-фильтрацией (чтобы определить с какого места вход), создать батник планирующий/удаляющий шару из под этой учетки. Результат: диск спланирован только у терминалов, у десктопов его нет. Один минус - пароль придется хранить почти открыто, но на сервере можно запустить скриптец, который будет его менять хоть каждый час, главное синхронно отражать это в батнике.

Nerian

27-06-2008, 16:43

Всем спасибо за дискусию. Пока решили остановиться на следующем варианте:

1. Фаерволом ни чего не блокируется
2. В скрипте который подключает диск, определяется из какой подсети выполняется подключение, если из региона - диск не подключается
3. Так же в локальных политиках десктоп регионах запрешена сеть на обычном пользовательском уровне или опять же в скрипте в зависимости от подсети:

"NoNetConnectDisconnect"=dword:00000001
"NoEntireNetwork"=dword:00000001
"NoWorkgroupContents"=dword:00000001
"NoNetHood"=dword:00000001

Если будут проблемы тогда ещё NoRun добавится, и тогда воопще нельзя будет обычному человеку зайти на сеть даже зная UNC путь...

Ну и + оптимизация всех скриптов чтоб они не качали/ставили ни чего лишнего для регионов, или если это делали - делали один раз.

Вот.

Если это не прокатит будут расматриваться варианты с созданием сайта, если и это не прокатит - или выделенный файловый сервер или же в виртуальной машине ещё один контролер для нужд регионов...

Такие вот дела. А ведь на самом деле - задачка то банальная, а решение приходится из пальца высасывать