Мабуть, у мене карма така: реалізовувати стандартні завдання будь-якими нетривіальними способами. Якщо у когось виявиться інше бачення проблеми — прошу в обговорення для опрацювання питання.
Одного чудового ранку з'явилося цікаве завдання роздати права групам користувачів на різні кулі, що містять підпапки проектів з папками документів. Все було добре і був написаний скрипт, який призначає права на папки. А потім з'ясувалося, що групи мають утримувати користувачів різних доменів, із різних лісів (). Допустимо, сама куля, розміщена на носії Synology, зареєстрованому в домені FB, лісу PSI. Завдання: дозволити користувачам доменів іншого лісу мати доступ до вмісту цієї кулі, причому дуже вибірково.
ТЗ через деякий час вимальовувалося у такому вигляді:
- 2 ліси: Ліс PSI, ліс TG.
- У кожному лісі по 3 домени: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Між лісами – довірчі стосунки, Synology бачить усі групи Security, у всіх лісах.
- На кулях та папках/підпапках обов'язково повинні бути облікові записи адмінів домену FB з правами FullControl
- Назви папок куля повинні бути систематизовані. Узгодженням ID проектів займалося керівництво, я вирішив назву груп Security прив'язати до ID проектів.
- Папки проектів у системних кулях повинні містити заздалегідь підготовлену в файлі .xlsx структуру, з відповідними привілеями доступу (R/RW/NA, де NA – доступ відсутній)
- Має можливість обмежити права користувачів/членів групи одного проекту лише певними каталогами даного проекту. До інших каталогів/проектів користувач може не мати доступу згідно членства в групах.
- При закладенні папки проекту максимально автоматично повинні створюватись групи у відповідних доменах з назвами відповідними ID проектів.
Примітки до ТЗ
- Налаштування довірчих відносин не входить до рамок ТЗ
- ID проекту містить цифри та латиницю
- Ролі користувачів проектів для всіх доменів мають типові назви
- Файл .xlsx з папками та правами доступу (матриця доступу) готується до початку реалізації всього проекту
- При реалізації проектів можливе створення груп користувачів у відповідних доменах
- Автоматизація досягається шляхом використання штатних засобів адміністрування MS Windows
Реалізація ТЗ
Після формалізації даних вимог було взято тактичну паузу на випробування методів створення каталогів та призначення прав на них. Використовувати передбачалося лише PowerShell, щоб не ускладнювати проект. Як я і писав раніше, алгоритм скрипту видавався досить простим:
- реєструємо групи з назвою похідною від ID проекту (наприклад KC40587) та відповідними ролями, зазначеними в матриці доступу: KC40587-EN- для інженера; KC40587-PM – для продакт менеджера тощо.
- отримуємо SID'и створених груп
- реєструємо папку проекту та відповідний набір каталогів (список підпапок залежить від кулі, в якій він створюється та визначений у матриці доступу)
- призначаємо нові підкаталоги проекту права групам відповідно до матриці доступу.
Труднощі, з якими довелося зіткнутися на 1 етапі:
- нерозуміння способу завдання матриці доступу в скрипті (зараз реалізовано багатовимірний масив, але шукається шлях до його заповнення на основі вмісту .xlsx файлу/матриці доступу)
- неможливість завдання прав доступу в SMB кулях на накопичувачах synology засобами PoSH -share?forum=winserverpowershell), через що було втрачено багато часу і довелося адаптувати все під скрипти з використанням утиліти редагування прав доступу icacls, що зажадало створення проміжного харнилища текстових і cmd – файлів.
У поточному режимі виконання cmd-файлів контролюється вручну за фактом необхідності реєстрації папки для проекту.
Також виявилося, що виконуватися скрипт повинен у тому числі і для реєстрації груп в інших лісах (використовували термін Cross-domains), причому співвідношення може бути не лише 1 до одного, а й 1 до багатьох.
Це означає, що доступ до ресурсів будь-якого домену тепер можуть претендувати групи з інших крос-доменів, у тому числі сусіднього лісу. Для реалізації однаковості було прийнято рішення про створення симетричної структури в OU всіх доменів всіх лісів, що обслуговуються (чорні вертикальні овали). Як кажуть, в армії має бути все потворно, але однаково:
Таким чином, при реєстрації проекту 80XXX в домені TG, скриптом виконується:
1. створення відповідної OU (червоні горизонтальні овали) у цьому домені та cross-доменах, тобто тих доменах, співробітники яких повинні мати доступ до даного ресурсу.
2. наповнення OU групами з назвами виду -, де:
- SRC_ domain – cross-домен, співробітники якого матимуть доступ до ресурсів DST домену
- DST_domain – домен, до ресурсів якого, власне, і має бути надано доступ, тобто заради чого все й починалося
- - номер проекту
- ROLES – назви ролей, перелічених у матриці доступу.
3. зчитування масиву SID всіх груп всіх задіяних доменів та збереження його для подальшої передачі даних у файл, що визначає права на конкретну підпапку проекту
4. генерація файлів-джерел (параметр /restore) з набором прав для використання утилітою icacKC в режимі файлу «icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt»
5. створення файлу CMD, що об'єднує в собі всі icacls, що запускаються, для всіх папок проекту
Як було написано раніше, запуск виконуваного файлу проводиться вручну та оцінка результатів виконання – також виконується вручну.
Проблеми з якими довелося зіштовхнутися у результаті:
- якщо папка проекту вже наповнена великою кількістю файлів, то відпрацювання команди icacls на наявних обсягах може займати значний час, а в ряді випадків призводило до відмови (наприклад, за наявності довгих шляхів файлів);
- крім параметра /restore довелося додати рядки з параметром /reset на випадок, якщо папки не створювалися, а переносилися з уже існуючих папок, з вимкненими правами успадкування з кореня;
- виконувати частину скрипту на створення груп довелося на довільному DC кожного лісу, проблема стосується облікових адміністративних записів для кожного дерева.
Загальний висновок: дуже дивно, що на ринку поки що немає утиліт з подібним функціоналом. Можлива реалізація такого функціоналу на базі порталу Sharepoint.
Також надається незрозумілим факт відсутності можливості використання PoSH утиліт завдання прав на папку на пристроях sinology.
За бажанням готовий поділитися скриптом, створивши якийсь проект на github, якщо це буде комусь цікаво.
Джерело: habr.com