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

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

Теперь по теме. Вроде время есть. Итак, у Вас домен и доменная же группа в нем. Назовем ее локальная группа, хоть и неправильно, но в качестве условности сойдет (так писать проще). Так же назовем и их контейнер и их политику - локальными.

Задача. Все доменные пользователи должны иметь доступ ко всему, что им положено видеть, кроме доступа к локальной группе. Локальная группа должна иметь доступ только внутри себя и к необходимым внешним сервисам (инет, почта и т.п.), оставаясь при этом в домене, то есть быть полностью централизованно администрируемой.
Способ реализации: Доменные политики. Сразу оговорюсь, что при таком способе локальная группа будет видна в сети.
Копнем в сторону запрета доступа по сети.
Инфраструктура. Создается локальный контейнер. В нем создается группа безопасности. Для контейнера создается политика безопасности. Все локальные пользователи и их компьютеры помещаются в этот контейнер и приписываются (member of...) локальной группе безопасности.
I. Очевидно, что доступ к локальной группе надо запретить всем пользователям, то есть Domain Users. И запретить надо в локальной политике безопасности локального контейнера.
Что произойдет? К локальной группе не получит доступа вообще ни кто, потому как все входят в группу безопасности Domain Users. Способы обхода:
1. Включить всех пользователей, кроме локальных в любую вновь созданную группу безопасности в домене, и именно ей запретить вышеозначенный доступ, а не Domain Usres. Минус - высокая трудоемкость на начальном этапе, необходимость включения в эту группу любого вновь созданного пользователя в дальнейшем.
2. Запретить применение доменной политики локальной группе безопасности. Минус - доменная политика перестает применяться к локальным пользователям\компам, необходимо дублировать пункты, требующие применения.
Итак, доменные пользователи, при попытке получить доступ к локальной группе получат отлуп. Тут надо не забыть про себя любимого и вообще Domain Admins.
II. Запрещаем локальной группе доступ к остальным компам.
1. При всей кажущейся простоте, а именно в доменной политике заперщаем доступ по сети локальной группе и всё, тут есть кучка нюансов.
2. Как это повлияет на доступность SYSVOL и NETLOGON? И вообще конроолллеры домена не отбрыкнут ли? Придется разруливать, ковыряя новые группы, политики, запреты. Как поведет себя почтарь? Прокси? И т.д. Да, все это можно разрулить, насоздавав групп и расставив разрешения.

Но, смотрите сами, сколько действий. И ошибись хоть в одном, либо не учти, маленький нюанс (например, политика паролей применяется только с корня домена, что ты там не напиши в OU, хоть обпишись, но политика паролей берется с корня домена) применяется "Назначение прав пользователя" с домена или с контейнера? Я не знаю. И, даже если все выстроить, то потом еще придется докручивать и докручивать винтики, ко всяким сервисам, необходимым локальной группе.
И главный минус. Выстроив такую монстроподобную поитику политик, всегда можно гадко напакостить самому себе или вообще потерять работоспособность домена.

Даже написать все это - требуется время. А реализовать?

В тоже время, разнесение по подсетям - плевое дело. И в сети компы светиться не будут, и локальные юзеры не будут видеть остальную сеть.
Как говорится: "почувствуйте большую разницу". Задача администратора - пройти кратчайшим путем, тихо и незаметно. А не валить буреломы героически.
Надеюсь, что после такого развернутого ответа понятно, почему я не советую реализовывать это политиками. Впрочем, может здесь есть более короткий путь, я таки не гуру.

Цитата:

возможно ли реализовать две подсети под контролем одного контроллера домена с одной сетевой картой?

Возможно. Майкрософт даже фишку придумал, сайты называется. Копните туда.
Цитата:

Например простым добавлением второго IP-адреса в свойствах TCP/IP на контроллере домена.

Можно и так. Но я бы маской сыграл: основная сеть 192.168.1.0\24 локальная 192.168.100.0\24 контроллер и общедоступные сервисы 192.168.0.0\16. Или вообще шлюзы организовать. Лучше VLAN конечно.
Цитата:

И всё-таки, почему параметры дефолтной политики могут не работать?

Работают они, если политика не отключена и не запрещена к применению. Ну и репликацию надо держать в уме.

Модерирует : lynx, Crash_Master, dg, emx, ShriEkeR
Версия для печати • Подписаться • Добавить в закладки