Мабыць у мяне карма такая: рэалізоўваць стандартныя задачы ўсякімі нетрывіяльнымі спосабамі. Калі ў кагосьці апынецца іншае бачанне праблемы - прашу ў абмеркаванне, для прапрацоўкі пытання.
Адной выдатнай раніцай з'явілася цікавая задача раздаць правы групам карыстачоў на розныя шары, утрымоўвальныя падтэчкі праектаў з тэчкамі дакументаў. Усё было добра і быў напісаны скрыпт які прызначае правы на тэчкі. А затым высветлілася, што групы павінны змяшчаць карыстальнікаў розных даменаў, з розных лясоў (). Дапушчальны, сама шара, размяшчаецца на носьбіце 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