# Катенин Владимир - Windows Basic. Занятие 5. Обмен данными в домене и средства мониторинга Windows
[toc]
## Практическая работа №5.1 Обмен данными в домене
### Часть 1. Настройка инстанса обмена данными
1.1 Для начала установим роль DFS на dc1. Перейдём в установку ролей и компонентов. Отметим роли DFS Namespaces и DFS Replication


---
1.2 Установим роли


---
1.3 Выполним аналогичную настройку на dc2


---
1.4 Зайдём в управление DFS и создадим новый namespace. Укажем сервер, являющийся сервером имён для DFS. Это будет dc1


---
1.5 Укажем имя создаваемого пространства и перейдём в Edit Settings


---
1.6 Настроим кастомные права, указав возможность чтения и записи для всех пользователей


---
1.7 Оставим настройки по умолчанию (domain-based namespace)


---
1.8 Создаем пространство имён


---
1.9 Успешное создание


---
1.10 Проверяем, что инстанс создан


---
DFS работает таким образом, что абстрагирует пользователя от прямого пути до папки. Для начала создадим обычные сетевые папки, а потом соотнесём их с DFS путями.

1.11 Создаем папку share


---
1.12 Создаем папки отделов и all_share


---
1.13 Каждую эту папку нужно сделать сетевой. Идём в настройки папки, нажимаем на вкладку sharing, пункт advanced sharing


---
1.14 Активируем галочку шаринга, а в конце имени сетевой папки ставим знак $. Затем идём в permissions


Знак доллара нужен, чтобы скрыть папку от посторонних

---
1.15 Выставляем права на чтение и запись для buhg-sec (права - change, read) и domain admins (права - full control), а группу everyone удаляем. После нажимаем apply


---
1.16 Будет показан относительный dc1 путь до папки по сети. Закрываем меню


---
1.17 Аналогичные действия делаем для остальных папок. Для all_share выдаем доступ на read/write для группы everyone





---
1.18 Папка all_share. Доллар ставить нет необходимости, всё равно группа everyone увидит ресурс


---
1.19 После создания папок они отображаются в сетевом пути до dc1. Теперь создаем папки в DFS. В меню DFS нажмём кнопку "new folder" и указываем имя папки (именно с этим именем она отобразится в dfs-пути)


---
1.20 Добавляем target


---
1.21 Сетевой путь до папки отобразится, можно подтверждать и применять настройки


---
1.22 Делаем аналогичное с другими папками. По сетевому пути видны сетевые папки (например, на Windows 10)


---
У пользователей ещё нет прав на уровне NTFS на редактирование файлов в них. Если пользователь из группы Buhg-sec расположит в папке Buhg файл, то пользователь будет являться его владельцем и сможет сделать с файлом всё, что захочет. Но вот другие пользователи группы Buhg-sec не смогут проводить операции с файлом.

1.23 Изменяем права security у папки Buhg. Нажмём кнопку Edit. Далее нажимаем кнопку Add, чтобы добавить группу Buhg-sec и даем права (в том числе и на modify)


---
1.24 Делаем аналогичное для других папок






---
## Практическая работа №5.2 Средства мониторинга Windows
### Часть 2. Управление средствами мониторинга Windows
Необходимо решить задачу с настройкой логирования удаления файлов с сетевых файловых ресурсов на dc1.

2.1 Заходим в настройки папки share, переходим в Security - Advanced


---
2.2 Заходим во вкладку Auditing и нажимаем Add, чтобы добавить правило аудита


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

2.3 Выбираем Principal - это объект, действия которого нужно логировать и отмечаем группу Domain Users


---
2.4 Ставим type = all, чтобы мониторить как успех, так и отказ. Нажимаем кнопку show advanced permissions


---
2.5 Отмечаем галочкой пункты Delete и нажимаем ОK


---
2.6 Правило создано для папки share, а так же всех её вложенных папок и файлов


---
Создаём в папке all_share папку folder-for-delete для тестирования генерации событий

2.7 На pc1 от имени пользователя Alex удаляем папку folder-for-delete из папки all_share


---
2.8 Проверяем журнал безопасности dc1. Необходимо отфильтровать события. Заходим в меню filter current log и вводим интересующие нас id событий (4656, 4659, 4660, 4663) в поле фильтра


При удалении файла создается набор событий.
Сначала идёт 4656 -- запрос дескриптора объекта. Это проверка прав доступа к файлу. Это событие показывает, что доступ был запрошен и результаты запроса, но не показывает, что операция была выполнена.
Затем 4663 -- это событие указывает на то, что над объектом была выполнена определенная операция. Основное отличие от 4656 является то, что 4663 показывает, что право доступа было использовано вместо только что запрошенного, и 4663 не имеет событий отказа.
После идёт 4660 -- это событие генерируется при удалении объекта. Оно не содержит имени удаляемого объекта, а только handle id.
4659 понадобилось бы, если бы в папке находились файлы. Событие с кодом 4659 регистрируется, когда дескриптор объекта запрашивается с целью его удаления.

События можно связать по handle id -- если у нескольких событий он одинаков, то это значит, что события относятся к одному объекту.

---
2.10 Видим 3 интересующие нас записи




---
### Часть 3. Управление средствами мониторинга Windows
3.1 Включаем сервис сборщика логов и подтверждаем его автостарт с помощью команды wecutil qc


---
3.2 Настраиваем политику отправки журналов на logcollector. Заходим в редактор групповой политики и создаем новую - log_delivery


---
3.3 Находим пункт включения службы WinRM


Путь до настройки: Computer Configuration/Policies/Windows Setting/Security Setting/System Services

---
3.4 Включаем службу


---
3.5 Находим пункт настройки менеджера подписок


Путь до настройки: Computer Configuration/Policies/Administrative Templates:.../Windows Components/Event Forwarding

---
3.6 Активируем его


---
3.7 Настраиваем путь до логколлектора


Для примера использовалось FQDN dc1. Если ввести ip адрес -- не будет работать инициализация со стороны клиента

Server=http://dc1.pt.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

---
3.8 Сохраняем и закрываем меню редактирования политики. Применяем фильтр безопасности, чтобы политика применилась только к pc1


---
3.9 По умолчанию поиск не происходит среди компьютеров. Изменяем это, выбираем типы объектов для поиска и указываем тип объектов - компьютеры


---
3.10 Проводим поиск по имени PC1 (введем имя и нажмём check names) и подтверждаем


---
3.11 Удаляем группу аутентифицированных пользователей, она не пригодится


---
Для управления компьютерами в домене с помощью WinRM нужно, чтобы брандмауэр windows разрешал подобные подключения. Изменим политику сбора логов так, чтобы правило было прописано на pc1.

3.11 Находим меню создания правил брандмауэра и создадим новое правило inbound


Путь до настройки: Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall …/Windows Firewall …/Inbound rules

---
3.12 Выбираем преднастроенное правило для WinRM


---
3.13 Создаем это правило только для доменной и частной сети (снимем галочку с public)


---
3.14 Разрешаем подключение


---
После применения порт на PC1 откроется и позволит выполнять WinRM команды, с помощью которых собираются логи с windows машин.
Теперь нужно донастроить политику так, чтобы у учетной записи сборщика были права на доступ к журналам, которые мы собираем в коллектор.

3.15 Для настройки политики понадобится дескриптор безопасности журнала. Находим его на PC1


Команда: wevtutil gl security

---
3.16 Настроим доступ УЗ до журнала security


Путь до настройки: Computer Configuration/Policies/Administrative Templates:…/Windows Components/Event Log Service/Security

---
3.17 Активируем политику и вводим параметр channelAccess


В решении этот параметр такой: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

Также в решении указан доп. параметр (A;;0x1;;;S-1-5-20) – для чтения журнала security службой network

---
3.18 Отдельно добавляем учетную запись, которую в дальнейшем будем использовать для чтения журналов, в группу читателей журнала. Заходим в политику локальных групп и добавляем правило для локальной группы. Local Group - Event Log Readers


Путь до настройки: Computer Configuration/Preferences/Control Panel Setting/Local User and Groups

---
3.19 Пользователи - администраторы домена


---
3.20 Применяем настройки


---
3.21 Применяем GPO на домен


---
3.22 Настраиваем приём логов на коллекторе. Проходим в event viewer, заходим в меню подписок и подтверждаем автоматическое включение службы. Создаем новую подписку. Называем её collector-get и отмечаем ПК, с которых коллектор будет собирать логи (select computers)


---
3.23 Проведем донастройку на PC1 с помощью команды winrm qc


---
3.24 Выбираем PC1 и нажимаем кнопку Test, чтобы проверить сетевую связность. Связность присутствует


---
3.25 Далее заходим в меню select events и выбираем нужные журналы


---
3.26 Заходим в меню Advanced, указываем для сбора УЗ администратора


---
3.27 Подтверждаем настройки, видим созданую подписку. Проверяем, нет ли ошибок. Необходимо меню Runtime Status


---
3.28 Отсутствие ошибок


---
3.29 Даем доступ сетевой службе до чтения журнала безопасности, выполняем команду на pc1


Команда: `wevtutil set-log security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)`

Получается, что выдаётся доступ NTAUTHORITY\NETWORKSERVICE (SID S-1-5-20) до журнала security

---
3.30 Видим логи в журнале forwarded events. Логи получены


---
### Часть 4. Настройка сборщика логов при компьютерах-инициаторах
4.1 На сервере-коллекторе выполним команду winrm qc, видим, что служба включена. Выполним команду wecutil qc, согласимся на включение службы сборщика событий Windows


---
4.2 На источниках событий включим службу WinRM. Она уже работает


---
4.3 Создаем подписку, где инициатором будут компьютеры




---