Windows — Групповая политика — Многочисленные общие диски с таргетингом на уровне элементов

Обзор

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

Системная информация

Операционная система: Windows Server 2016

Следующее относится к четырем машинам на двух контроллерах домена.

Контроллеры домена (GPO, Active Directory)

Операционная система: NetApp, которая в ближайшем будущем будет заменена на Nutanix Files.

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

Структура

Мы сопоставляем диск с нашими пользователями, который подключается к нашему устройству NetApp. Устройство NetApp имеет вложенные папки для каждого имени сайта, которые, в свою очередь, содержат все, что пользователи помещают в эти папки. Структура выглядит примерно так:

Акции NetApp
✓ Сайт 1
✓ Сайт 2
✓ Сайт 3
✓ Сайт 4
✓ Сайт 5

У нас есть несколько групп безопасности, например следующие:

Site1-ShareDrive
Site2-ShareDrive
Site3-ShareDrive
Site4-ShareDrive
Site5-ShareDrive

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

Пример:

Site1-ShareDrive
✨Пользователь 13
✓ Пользователь 20
ââ Пользователь33
✨Пользователь 42
✨Пользователь 51

Site4-ShareDrive
✨Пользователь 13
✨Пользователь 22
ââ Пользователь 23
ââ Пользователь 1
ââ Пользователь5
âââ Пользователь3
✓ Пользователь 100

Site9-ShareDrive
✨Пользователь 13
✨Пользователь 22
ââ Пользователь 23
ââ Пользователь 1
✨Пользователь 53
✨Пользователь 54
✓ Пользователь 545

Структура объявления:

Все сайты
✓ ✓ Дивизион-1
| ✓ Сайт 1
| ✓ Сайт 2

✓ ✓ Дивизион-2
| ✓ Сайт 3
| ✓ Сайт 4
| ✓ Сайт 5

✓ ✓ Дивизион-3
| ✓ Сайт 6
| ✓ Сайт 7
| ✓ Сайт 8

✓ ✓ Дивизион-4
| ✓ Сайт 9
| ✓ Сайт 10

Для групповой политики мы хотели бы разместить политики на уровне «Все сайты», чтобы теоретически просачиваться на всю структуру, но применять их только в зависимости от того, входят ли пользователи в целевую группу безопасности.

Проблема

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

Например:

Пользователь 1 принадлежит к следующим группам:

Менеджеры
Site1-ShareDrive
Site9-ShareDrive

Пользователь 13 принадлежит к следующим группам:

Партнер
Site1-ShareDrive
Site4-ShareDrive
Site9-ShareDrive

По логике наша установка должна быть следующей:

• Пользователь1 должен иметь доступ только к \example.com\Shares\Site1 и \site9
• Пользователь13 должен иметь доступ только к \example.com\Shares\Site1, \site4 и \site9

К сожалению, эта проблема возникает в гораздо большем масштабе, если вы добавите тот факт, что некоторым пользователям, которые могут быть менеджерами, нужен только один сайт, в то время как другим менеджерам может потребоваться больше сайтов и доступ партнеров к их подразделениям, за которые они отвечают. Другая проблема, с которой мы сталкиваемся, заключается в том, что некоторые сайты являются совместными подразделениями, поэтому некоторым пользователям за пределами их подразделения OU требуется доступ к другим сайтам с общими дисками. Помимо добавления их в эти группы безопасности, переход на уровень файлов для разрешений NTFS в настоящее время будет кошмаром, поскольку мы используем старое устройство NetApp, которое на самом деле скоро будет EOL нашим поставщиком. У нас пока нет сроков перехода на новую платформу.

Кроме того

Мы бы предпочли скрыть все папки, к которым у пользователей нет доступа. Например, в приведенном выше примере User1 даже не знал бы о существовании \example.com\Shares\Site8, поскольку пользователь не принадлежит к соответствующим группам безопасности.

Мы хотели бы иметь возможность применять некоторые группы безопасности в соответствии с сайтом, который нужен пользователю. Наряду с размещением целевого уровня элемента в этой группе безопасности. Наша текущая структура OU выглядит следующим образом:

Пример структуры OU

Все сайты
    Сайт 1
      Пользователь13
    Сайт 4
      Пользователь1
    Сайт 9
      Пользователь545

Вопросы

1. Как мы можем гарантировать, что наша структура работает с таргетингом на уровне элементов? (т.е.GP: «Доступ к Site1-ShareDrive» будет иметь диск «\example.com\shares\Site1», отображаемый с помощью «Обновления» и «Повторного подключения», а также «Выполнять в контексте безопасности пользователя» и «Цель на уровне элемента». на «Site1-ShareDrive» со ссылкой на «Все сайты»)?
2. Если что-то из вышеперечисленного невозможно, как мы можем обеспечить простоту использования для наших пользователей при одновременном повышении производительности ИТ?

Несколько вещей:

Скрытие файлов и папок без разрешений:
Чтобы скрыть папки, к которым у пользователей нет доступа, вы можете включить «Перечисление на основе доступа» для общих ресурсов. Тем не менее, не рекомендуется делать это, если у вас нет строгих требований к этому. ABE может привести к значительному увеличению загрузки ЦП в общих файловых ресурсах, поскольку ACL каждого файла необходимо перечислять каждый раз при обходе каталога.

Связывание объектов групповой политики с логическими сайтами AD:
Вы можете сэкономить некоторое время обработки предпочтений групповой политики, применив объект групповой политики для сопоставленных дисков непосредственно к логическим сайтам Active Directory, если у вас есть логический сайт AD, представляющий каждое физическое расположение. (Обратите внимание, что для этого требуется использовать консоль управления сайтами и службами AD или модуль AD PowerShell для сопоставления подсетей с конкретными сайтами.) Единственная проблема с этим подходом — небольшое количество пользователей, которым требуется доступ к общим ресурсам нескольких сайтов, независимо от того, какой сайт они в. Этого можно добиться, создав некоторую избыточность в объектах групповой политики для конкретных сайтов для сопоставления дисков, но опять же... это становится менее эффективным.

Вернуться к настройкам групповой политики:
Похоже, у вас есть хорошее начальное понимание того, как использовать таргетинг на уровне элементов для этой работы. Вот потенциальный макет ILT для гипотетического "Поделиться 1" в "Сайт А":

Отредактируйте объект групповой политики и расширьте Конфигурация пользователя> Настройки> Настройки Windows, а затем щелкните Карты дисков.

1. Настройте общие параметры карты дисков для Поделиться 1 в Сайт А.
2. Перейдите на вкладку «Общие», включите таргетинг на уровне элементов и нажмите кнопку настроек «Таргетинг...».
3. Теперь вы захотите использовать несколько коллекций ILT для группировки условий таргетинга. Из того, что вы описали, я бы создал что-то вроде этого:

Предметы и коллекции ILT

1. Добавить коллекцию, где «эта коллекция верна»

• Добавьте условие, которое гласит пользователь является членом группы безопасности "Сайт А"
• Добавить условие [И] сайт называется "SiteA"

2. Добавьте вторую коллекцию (где эта коллекция истинна) и установите параметры элемента коллекции на ИЛИ ЖЕ

• Во вторую коллекцию добавьте элемент, чтобы включить менеджеров, которым требуется доступ к нескольким общим ресурсам сайта. Используйте группу безопасности и установите для элемента значение «пользователь является членом группы безопасности «Менеджеры сайта» (при условии, что эта группа имеет доступ к нескольким общим ресурсам сайта.

Нажмите OK, чтобы сохранить и закрыть текущий элемент карты дисков. Этот пример может решить вашу задачу.

Динамический контроль доступа
Вы также можете изучить возможность использования функции динамического контроля доступа на вашем файловом сервере. Эта функция делает ACL (списки управления доступом) в файловой системе намного более мощными за счет включения двух новых функций:

• Возможность использовать оба ИЛИ ЖЕ и И операторы в ACL
• Возможность добавлять разрешения на основе утверждений или условия к разрешениям. Утверждения могут быть основаны на 3 типах объектов: атрибутах пользователя, атрибутах устройства или утверждениях преобразования (обычно на основе правил, созданных в политике).

Утверждения пользователей и устройств могут быть основаны на большинстве атрибутов объектов пользователей или устройств в AD, поэтому гипотетически вы можете создать правило DAC, которое гласит: предоставить доступ пользователю, если он находится в «Группе А» и не использует мобильное устройство, и если он использует компьютер, который находится на «Сайте А» (это будет основано на подсети IP-адреса, отображаемой в AD). Кроме того, вы можете использовать политики классификации данных для применения различных правил динамического контроля доступа в зависимости от требований пользователя или устройства... но это уже следующий уровень! Я бы порекомендовал изучить DAC, но просто знайте, что он имеет более сложные зависимости, чем просто работа с хорошей конфигурацией таргетинга на уровне элемента.