Явно кармата ми е следната: да изпълнявам стандартни задачи по всевъзможни нетривиални начини. Ако някой има различно виждане за проблема, моля да го обсъди, за да може въпросът да бъде отработен.
Една хубава сутрин възникна интересна задача за раздаване на права на групи потребители за различни споделяния, съдържащи подпапки на проекти с папки с документи. Всичко беше наред и беше написан скрипт за присвояване на права на папките. И тогава се оказа, че групите трябва да съдържат потребители от различни домейни, от различни гори (). Да кажем, че самият дял се намира на носител на Synology, регистриран във FB домейна на PSI гората. Задача: да позволи на потребителите на домейни в друга гора да имат достъп до съдържанието на този дял, и то много избирателно.
След известно време техническите спецификации придобиха следната форма:
- 2 гори: PSI гора, TG гора.
- Всяка гора има 3 домейна: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Има доверителна връзка между горите; Synology вижда всички групи за сигурност във всички гори.
- Споделянията и папките/подпапките трябва да имат администраторски акаунти на FB домейн с FullControl права
- Имената на папките трябва да бъдат систематизирани. Ръководството координира идентификаторите на проекта; реших да свържа името на групите за сигурност с идентификаторите на проекта.
- Папките на проекта в системните споделени файлове трябва да съдържат структура, подготвена предварително в .xlsx файл, с подходящи привилегии за достъп (R/RW/NA, където NA – без достъп)
- Трябва да е възможно да се ограничат правата на потребителите/членовете на групата на един проект само до определени директории на този проект. Потребителят може да няма достъп до други директории/проекти в зависимост от членството в групата.
- Когато създавате папка на проект, групите трябва да се създават възможно най-автоматично в съответните домейни с имена, съответстващи на идентификаторите на проекта.
Бележки към техническите спецификации
- Създаването на доверителни отношения не е включено в обхвата на техническите спецификации
- ID на проекта съдържа цифри и латински букви
- Потребителските роли на проекта за всички домейни имат стандартни имена
- .xlsx файл с папки и права за достъп (матрица за достъп) се подготвя преди началото на целия проект
- При изпълнение на проекти е възможно да се създават потребителски групи в съответните домейни
- Автоматизацията се постига чрез използване на стандартни инструменти за администриране на MS Windows
Изпълнение на технически спецификации
След формализиране на тези изисквания беше направена тактическа пауза за тестване на методи за създаване на директории и присвояване на права за тях. Предвиждаше се да се използва само PowerShell, за да не се усложнява проекта. Както писах по-рано, алгоритъмът на скрипта изглеждаше доста прост:
- регистрираме групи с име, получено от идентификатора на проекта (например 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 към много.
Това означава, че групи от други кръстосани домейни, включително съседна гора, вече могат да претендират за достъп до ресурсите на всеки домейн. За да се постигне еднаквост, беше решено да се създаде симетрична структура в OU на всички обслужвани домейни на всички гори (черни вертикални овали). Както се казва, в армията всичко трябва да е грозно, но еднообразно:
По този начин, когато регистрирате проект 80XXX в TG домейна, скриптът изпълнява:
1. създаване на съответните OU (червени хоризонтални овали) в този домейн и кръстосани домейни, т.е. онези домейни, чиито служители трябва да имат достъп до този ресурс.
2. попълване на OU с групи с имена като -, Където:
- SRC_ домейн – междудомейн, чиито служители ще имат достъп до ресурсите на DST домейна
- DST_domain - домейнът, до чиито ресурси всъщност трябва да се осигури достъп, т.е. заради който е започнато всичко
- — номер на проекта
- ROLES – имена на ролите, изброени в матрицата за достъп.
3. четене на масива от SID на всички групи от всички включени домейни и запазването му за последващо прехвърляне на данни във файл, който дефинира правата върху конкретна подпапка на проекта
4. генериране на изходни файлове (параметър /restore) с набор от права за използване от помощната програма icacKC в режим на изпълним файл „icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. създаване на CMD файл, който комбинира всички стартирани icacls за всички папки на проекта
Както беше написано по-рано, стартирането на изпълнимия файл се извършва ръчно и оценката на резултатите от изпълнението също се извършва ръчно.
Трудности, с които трябваше да се сблъскаме в крайна сметка:
- ако папката на проекта вече е пълна с голям брой файлове, тогава изпълнението на командата icacls на съществуващите томове може да отнеме значително време и в някои случаи да доведе до неуспех (например, когато има дълги файлови пътища);
- в допълнение към параметъра /restore трябваше да добавим редове с параметъра /reset в случай, че папките не са създадени, а са прехвърлени от предишни съществуващи папки, с деактивирани права за наследяване от root;
- Част от скрипта за създаване на групи трябваше да се изпълни на произволен dc на всяка гора, проблемът се отнася до административни акаунти за всяко дърво.
Общо заключение: много е странно, че на пазара все още няма помощни програми с подобна функционалност. Изглежда възможно да се приложи подобна функционалност на базата на портала Sharepoint.
Също така е неразбираемо, че не е възможно да се използват PoSH помощни програми за задаване на права за папки на синологични устройства.
При желание съм готов да споделя скрипта, като създам някакъв проект в github, ако някой се интересува.
Източник: www.habr.com