none
GPO для филиалов RRS feed

  • Вопрос

  • Добрый день, коллеги!

    Задача: Имеется центральный офис и есть филиалы где сидят админы. Необходимо предоставить корректные права для администрирования филиалов. Я это вижу и делаю:

    В каждом филиале имеется своя AD, которая помещена  в свой сайт и связанная с subnet, т.е у каждого филиала есть своя под сеть. Я предоставляю права администратора(встроенная запись) на локальной машине  филиала, делаю фильтр  WMI

    Select * FROM Win32_IP4RouteTable WHERE (Mask='255.255.255.0' AND (Destination Like '191.168.10.%'  OR Destination Like '191.168.8.%'  OR Destination Like '191.168.11.%' OR Destination Like '191.168.7.%' OR Destination Like '191.168.3.%' OR Destination Like '191.168.4.%' OR Destination Like '191.168.12.%' OR Destination Like '191.168.9.%'))


    Политика не применяется
    29 сентября 2017 г. 5:16

Все ответы

  • Все таки WMI фильтры не совсем удобный инструмент.

    Правильнее и надежнее было бы создать в AD отдельные OU для каждого филиала, делегировать на них права местным администартороам и привязать политики уже к OU.

    Либо можно прявязать политики к сайтам AD (вот пример)

    29 сентября 2017 г. 5:29
  • Соглашусь с коллегой. В AD есть целая структура для описания площадок, офисов и филиалов - топология (сайты и сервисы). К сайтам привязываются подсети, в них разворачиваются контроллеры с DNS+DHCP, они обслуживают клиентов. В AD всё разносится по разным OU'шкам на которые админам выдаются нужные права. Почему не пользуетесь штатным функционалом?
    • Изменено webDancer 29 сентября 2017 г. 6:28
    29 сентября 2017 г. 6:28
  • Спасибо за советы, конкретно в этом вопросе опыта нету. Переделал политику для сайтов, политика не применяется на клиентах,

    Захожу на клиентские машины в филиале проверяю:

    nltest /dsgetsite - да действительно компьютер принадлежит к указанному сайту

    Обновляю политику gpupdate  /force

    rsop.msc - политик не нахожу

    Вопрос, да OU для филиалов созданы, но там внутри OU(пример Новосибирск) размещены OU отделов где содержатся учетные данные, вы предлагаете внутри OU(город), создать OU для компьютеров  идентифицировать и переместить их туда? тогда сразу вопрос, если какой то скрипт который будет идентифицировать папку default  OU Computers по параметру nltest /dsgetsite и разносить по заданным OU филиалов


    29 сентября 2017 г. 8:07
  • 5 копеек в коробочку:

    >>В каждом филиале имеется своя AD

    поясните что вы имели в виду.

    Во вторых использование рестриктед групп с указанием мембера(очень жесткое условие, в отличии от мембер оф) совместно с ГПП локал юзер анд групс не самая лучая идея имхо, вы иж лучше бы рулили через что нить одно

    про вми фильтры уже сказали

    29 сентября 2017 г. 8:49
  • Есть центральные офис здесь PDC с global catalog, и в удаленных филиалах есть развернутые dc с global catalog

    Да и в Member of нельзя указывать учетные записи



    29 сентября 2017 г. 9:20
  • различие мембер и мембер оф в том смысле что указывая например через мембер группу кпн\локал администрейшн вы принудительно заставляете выкидываеть всех остальных, кроме билтиннного админа(то есть говорите явно что в администраторах никого кроме них быть не должно, в отличии от мембер оф где вы прыто докидываете в группу, не меняя старого членства), а затем в той же политике пытаетесь править группу билтинных администраторов уже через GPP добавляя в группу администраторов пользователя(?) кпн\мейнхелп наперекор только что заданному ограничению через рестриктед групс. Если честно, я уже не помню кто выигрывает в данном случае, надо будет глянуть попобробнее механизм работы. Но по моему  личному мнению нужно уж либо через рестриктед групс все делать или через ГПП настроить тоже самое(либо штаны одеть илбо крестик снять)
    29 сентября 2017 г. 10:18