Изглежда, че имам такава карма: да реализирам стандартни задачи по всякакви непознати начини. Ако някой има друго виждане на проблема, моля, заповядайте в обсъждането, за да работим по въпроса.
Едно прекрасно утро се появи интересна задача да раздам права на групи потребители за различни шари, съдържащи подпапки на проекти с папки с документи. Всичко вървеше добре и беше написан скрипт, който назначаваше права на папките. А след това се оказа, че групите трябва да съдържат потребители от различни домейни, от различни гори (). Да предположим, че самата шари се разполага на носител 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 (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), поради което загубихме много време и се наложи да адаптираме всичко под скриптове с използване на утилита за редактиране на права icacls, което изиска създаването на междинно хранилище от текстови и cmd – файлове.
В текущия режим изпълнението на cmd-файловете се контролира ръчно, при фактическа необходимост от регистрация на папка за проекта.
Също така се оказа, че скриптът трябва да се изпълнява и за регистрация на групи в други гори (използвахме термина Cross-domains), като съотношението може да бъде не само 1 към 1, но и 1 към много.
Това означава, че достъпът до ресурсите на някой домейн вече могат да искат групи от други кросс-домейни, включително съседна гора. За постигане на единство беше прието решение за създаване на симетрична структура в OU на всички обслужвани домейни на всички гори (черни вертикални овални форми). Както се казва, в армията всичко трябва да бъде безобразно, но единно:
При регистрацията на проекта 80XXX в домейна TG, скриптът изпълнява:
1. създаване на съответната OU (червени хоризонтални елипси) в този домейн и крос-домейни, т.е. в тези домейни, служителите на които трябва да имат достъп до този ресурс.
2. попълване на OU с групи с имена от вида <SRC_domain><DST_domain><ID_project>-, където:
- SRC_domain – крос-домейн, служителите на който ще имат достъп до ресурсите на DST домейна
- DST_domain – домейнът, до ресурсите на който, всъщност, трябва да бъде предоставен достъп, т.е. причината за всичко това
- <ID_project> — номер на проекта
- 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
