Создание и публикация личного сетевого диска

[George]

WinSrv 2019 DC
DFS

Появилась задача нескольким пользователям сделать личный сетевой диск. Я на файловом сервере создал второй виртуальный HDD, в корне создал папку PersonalDisks, отключил наследование прав, создал подпапку с логон именем юзерской учётки и дал права только этому пользователю. И через GPO распространил на OU, где находятся куча людей, в том числе и этот пользователь.

Пользователю приехал сетевой диск (конечно с квотой), и ярлык на рабочий стол на этот же диск. Но вопрос, насколько корректно применять эту политику на всю OU "Users", когда сетевой диск нужен только 1-5 пользователям? Если не создавать каталоги пользователей и не давать к ним доступ, то другим пользователям ничего не мапится и не рабочий стол не кладётся. Кто может подсказать более красивое решение? Сейчас прямо чую, что это не тот путь, каким надо давать доступ к сетевому диску нескольким людям.

Что бы примерно было понятно о чём речь, вот примерно так я и сделал: https://habr.com/ru/post/278659/ (только раздел "Создание пользовательской папки" я не делал, т.к. всё руками ибо не надо давать юзерам даже шанса стрелять себе в ногу).

Пока самое красивое решение это Item level targeting (https://bga68.livejournal.com/22020.html), но опять же, я применяю политику на всех юзеров, но в реальности она применяется только на тех, кто в группе. Насколько это красивое и верное решение?

[Уваров А.С.]

Ну а почему бы и не совместить? Добавить нужным пользователям членство в еще одной группе и нацелить на нее политику?

[George]

Уваров А.С., всё так, но GPO приходится линковать всё равно ко всей OU Users (можно и к домену, но пользаки живут только в Юзерах), но применяться она будет только к тем, кто: входит в Target group + человек находится в любой OU на которую действует политика. Но при этом политика всё равно отображается как применённая у людей, которые не соответствуют критериям. Вот и вопрос - зачем нагружать ненужными политиками непричастных? Пусть она и не отрабатывает.

[ival]

Расскажу как подобная система реализована у нас.

Имеем следующую структуру:

• Пользователи одного отдела имеют общую папку отдела
• Пользователи имеют личную папку
• Пользователи имеют папку с общей информацией по компании
• Пользователи имеют папку для обмена информацией между отделами
• Пользователи имеют папку общих проектов

Изначально все было относительно просто, папки отделов, папка обмена и папка общей информации.

Реализовывали следующим образом:

Была группа с названием Map_Resources, в нее включались пользователи которым нужно было мапить ресурсы. Была аналогичная политика Map_Resources в которой были настроены примапленные ресурсы, нацеливание было на группу Map_Resources. Параметры политики "Конфигурация пользователя-Настройки-Конфигурация Windows-Ярлыки", создавали элемент ярлык с параметрами:

Действие "создать"
Имя Ресурсы\<Название отдела>
Тип объекта: Файловая система
Размещение: Рабочий стол
Путь: на шару
Выполнение в контексте безопасности вошедшего пользователя
В нацеливании на уровень элемента указывали группу конкретного отдела (и дополнительные группы/пользователей из числа дирекции)

В итоге у пользователя вошедшего в систему и включенного в группу Map_Resources папка на рабочем столе создается папка "Ресурсы" в котором уже находятся ярлык на расшареную папку отдела.
Аналогично добавлялась папка с общей информацией и папка обмена, но уже для всей группы Map_Resources. Шары как диски не мапим, это опаска осталась из прошлого, когда шифровальшики могли шифровать примапленые диски на нем. Ярлыки они шифровали как объект, все что за ярлыком оставалось целым.

В политике было ярлыков 15, все прекрасно работало до тех пор пока людям не понадобились личные папки и людям с разных отделов не пришлось работать с одним проектом. Часть документов жило в шарике и сотрудники прекрасно с ними работали, но в проектах была статическая или редко меняющаяся часть документации которая занимает десятки и сотни гигабайт. Поэтому было принято решение создать папку "Projects". Создавать и мапить это как раньше не было смысла так как на выходе в политике был бы вагон папок, да и собственно к этому времени мы пришли к обновлению ФС с 2008 на 2019 и созданию FO кластера.

Как это выглядит сейчас:
Группы перекачевали, политика также осталась, просто в нее добавились ярлыки на шару Projects и UserDir, ещё добавились архивные данные (зеркало структуры ФС, но уже не используемое в оперативной работе и имеющее права только для чтения с сохранением модели доступа)

Шары мы создаем c использованием ABE. Папки внутри Progects и UserDir создаются руками админами (конечно не верх кашенрности, но это подконтрольно и всегда знаешь с кого спросить, если беда с правами) Также сейчас назревает проблема с количеством групп доступа к ресурсам, так как их число растет. В будущем надо будет что-то кардинально менять именно со структурой хранения и доступа.

Из опыта могу сказть, что к OU лучше не привязываться, нацеливание делайте всегда на группы, это как минимум удобнее в ориентации. По мапингу диска, тоже весьма спорно, да - для пользователя это удобно, но я не маплю диски с шарами даже себе =))

[ival]

нацеливание делайте всегда на группы, это как минимум удобнее в ориентации

фильтрацию

устал пока писал((

[George]

ival, Вы говорите про раздел Security Filtering в GPO, верно?

UPD: когда добавил в этот раздел нужную группу, всё равно у непричастных, кого в группе нет в gpresult /r в разделе "Примененные объекты групповой политики" указывается, что эта политика применена (хотя, конечно, никаких ярлыков и дисков не подключено). Т.е. у меня нет понимания механизма (на выходных буду пересматривать 20410 модуль 11 и 20411 модуль 4 и 5) работы GPO, может я зря волнуюсь, т.к. политика в реальности-то не применяется, хоть и отображается как применённая.

А! Может у Authenticated users в Security filtering снять чекбокс Apply policy? Удалять, я знаю, нельзя, а вот внутри чекбокс снять вроде можно.

[George]

Жаль, что время редактирования сообщения короткое.

ival, спасибо за наводку - я снял чекбокс у Authenticated users и в разделе Security Filtering, во-первый, пропали Authenticated users, во-вторых я в этот же раздел добавил группу безопасности, куда добавляю людей. И всё стало как и надо - политика не применяется на людей, которых нет в группе (в gpresult /r её нет), а те кто в группе есть - политика применяется.

[ival]

ival, Вы говорите про раздел Security Filtering в GPO, верно?

Именно

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

[George]

Что ж, всё таки раньше, до июня 2016 года, можно было удалять Authenticates users и добавлять конкретную группу/пользователя/машину. Но случилось что случилось и теперь больше этого делать нельзя: https://habr.com/ru/post/304202/

Я сейчас смотрю курс 10969B от 2014 года и там прямо говорится, что убираем Authenticated users и добавляем группу/хост/юзера. Кто знал, что через 2 года это станет ложным утверждением.

ival, ещё раз перечитал Ваш опыт, спасибо что поделились. Касательно WMI - у нас пока только есть серверная инфраструктура в ЦОДе, а клиентская состоит из компьютеров в Workgroup. Когда компьютеры форматнём и введем в домен, то да, WMI будет помогать.

Касательно примапливания дисков - я поднял и настроил сервер Kaspersky Security for Windows Server 10.1 и там есть отдельный модуль против шифровальщиков: если файловый антивирус пропустил зловреда, эвристика тоже и он начал шифровать первый файл в любом сетевом каталоге на сервере, на котором установлен KS4WS, то антивирус блокирует конкретного пользователя до момента ручного разбана администратором в консоли. Но один файл всё же пошифровать он успеет, но при наличии теневых копий (не говоря уже о бэкапах) этой небольшой потерей можно пренебречь. Причем блокирует не хост, с которого выполняется шифрование, а именно сессию пользователя, т.к. есть же терминалка, на которой сидят куча людей. В общем я пока не тестировал ещё, т.к. на боевые сервера не хочется ставить AES Crypt, но как введём первую машину в домен сразу попробую проверить как оно работает (на видео курса KL 005.10: Kaspersky Security for Windows Server показывается как этот механизм работает).

[George]

Коллеги, подскажите ещё такой момент: я вешаю политики либо на домен, либо на большую OU, но фильтрую политики по группе и, как писал выше, если пользователь не входит в группу, то на него политика не применяется.
Но! Если я правильно помню, то она в gpresult /r вообще не должна отображаться, во всяком случае раньше она не отображалась как не_применённая, а сейчас заметил, что стала отображаться:

    Следующие политики GPO не были применены, так как они отфильтрованы
    --------------------------------------------------------------------
        Cons_folder1
            Фильтрация:  Отказано (безопасность)

        Cons_folder2
            Фильтрация:  Отказано (безопасность)

Это нормально или нет? Я точно помню, что раньше политики, которые не применяются - не отображались в gpresult /r. Подскажите, может я чего упустил.

[Уваров А.С.]

На мой взгляд - нормально, будет время - посмотрю на объекте.

[George]

Уваров А.С., спасибо! Я точно помню, что у меня не отображались политики, которые не применимы к тем или иным пользователям из-за Security filtering. Возможно, перетрудился, и что-то перепутал, но тем не менее...

[George]

Уваров А.С., подскажите, не посмотрели?

[ival]

Нормальное это поведение.

Если на OU (домен), то все кто в OU (домен) входят ее читаю, а потом смотрят по фильтрам причинять или отменять. Если бы не было отображения отклоненных как бы Вы диагностировали почему она отфильтрована??

[George]

ival, спасибо за ответ, теперь спокоен что всё верно сделал, спасибо!