Големо доделување права на корисници на домени од различни шуми

Очигледно мојата карма е ова: да се спроведат стандардни задачи на секакви нетривијални начини. Ако некој има поинаква визија за проблемот, ве молиме разговарајте за тоа за да може да се реши проблемот.

Едно убаво утро се појави интересна задача да се дистрибуираат правата на групи корисници за различни споделувања што содржат подпапки на проекти со папки со документи. Сè беше во ред и беше напишана скрипта за доделување права на папките. И тогаш се покажа дека групите треба да содржат корисници од различни домени, од различни шуми (за оние кои заборавиле што е тоа). Да речеме дека самиот удел се наоѓа на Synology media, регистриран во ФБ доменот на шумата PSI. Задача: да им се овозможи на корисниците на домени во друга шума да имаат пристап до содржината на ова споделување и тоа многу селективно.

По некое време, техничките спецификации ја добија следната форма:

• 2 шуми: PSI шума, TG шума.

  

• Секоја шума има 3 домени: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Постои доверлив однос помеѓу шумите; Synology ги гледа сите безбедносни групи во сите шуми.
• Споделувањата и папките/потпапките мора да имаат администраторски сметки на доменот FB со права на FullControl
• Имињата на папките треба да се систематизираат. Менаџментот ги координираше проектните ID; решив да го поврзам името на безбедносните групи со проектните ID.
• Проектните папки во системските споделувања мора да содржат структура подготвена однапред во датотека .xlsx, со соодветни привилегии за пристап (R/RW/NA, каде што NA – без пристап)

  

• Треба да биде можно да се ограничат правата на корисниците/членовите на групата на еден проект само на одредени директориуми на тој проект. Корисникот може да нема пристап до други директориуми/проекти, во зависност од членството во групата.
• Кога креирате проектна папка, групите треба да се креираат што е можно поавтоматски во соодветните домени со имиња што одговараат на проектните ID.

Забелешки за техничките спецификации

• Поставувањето на доверливи односи не е вклучено во опсегот на техничките спецификации
• ИД на проектот содржи броеви и латински знаци
• Проектните кориснички улоги за сите домени имаат стандардни имиња
• Датотека .xlsx со папки и права за пристап (матрица за пристап) се подготвува пред почетокот на целиот проект
• При спроведување на проекти, можно е да се креираат кориснички групи во соодветните домени
• Автоматизацијата се постигнува со користење на стандардни алатки за администрација на MS Windows

Имплементација на технички спецификации

По формализирањето на овие барања, беше направена тактичка пауза за тестирање на методите за креирање директориуми и доделување права на нив. Беше наменет да се користи само PowerShell, за да не се комплицира проектот. Како што напишав претходно, алгоритмот за скрипта изгледаше прилично едноставен:

• регистрираме групи со име изведено од проектниот проект (на пример KC40587) и соодветните улоги наведени во матрицата за пристап: KC40587-EN- за инженер; KC40587-PM – за менаџер на производи, итн.
• ги добиваме SID на креираните групи
• регистрирајте ја проектната папка и соодветниот сет на директориуми (листата на подпапки зависи од уделот во кој е креиран и дефиниран во матрицата за пристап)
• доделување права на групи за нови поддиректориуми на проектот според матрицата за пристап.

Тешкотии со кои се соочуваат во фаза 1:

• погрешно разбирање на методот за одредување на матрицата за пристап во скриптата (сега е имплементирана повеќедимензионална низа, но патот до нејзино пополнување се бара врз основа на содржината на матрицата за .xlsx датотека/пристап)

  

• неможност за поставување права за пристап во SMB акции на синолошки дискови користејќи 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 спрема многу.

Ова значи дека групи од други вкрстени домени, вклучително и соседна шума, сега можат да бараат пристап до ресурсите на кој било домен. За да се постигне униформност, беше одлучено да се создаде симетрична структура во ОУ на сите сервисирани домени на сите шуми (црни вертикални овали). Како што велат, во армијата сè треба да биде грдо, но униформно:

Така, при регистрирање на проектот 80XXX во доменот TG, скриптата извршува:

1. создавање на соодветните OU (црвени хоризонтални овали) во овој домен и вкрстени домени, односно оние домени чии вработени мора да имаат пристап до овој ресурс.

2. пополнување OU со групи со имиња како -, каде што:

• SRC_ домен – вкрстен домен чии вработени ќе имаат пристап до ресурсите на доменот DST
• DST_domain – домен до чии ресурси, всушност, треба да се обезбеди пристап, односно заради кој сè е започнато
• — број на проектот
• УЛОВИ – имиња на улогите наведени во матрицата за пристап.

3. читање на низата SID од сите групи од сите вклучени домени и зачувување за последователен пренос на податоци во датотека која ги дефинира правата на одредена потпапка на проектот

4. генерирање на изворни датотеки (параметар / обновување) со збир на права за користење од алатката icacKC во режим на извршна датотека „icacKC „as-nasNNKCProjects“ /врати C:TempKCKC40XXKC40XX.txt“

5. создавање на CMD-датотека која ги комбинира сите лансирани icacls за сите проектни папки

Како што беше напишано претходно, стартувањето на извршната датотека се врши рачно, а проценката на резултатите од извршувањето исто така се врши рачно.

Тешкотии со кои моравме да се соочиме на крајот:

• ако проектната папка е веќе исполнета со голем број датотеки, тогаш извршувањето на командата icacls на постоечките томови може да потрае значително време, а во некои случаи ќе доведе до неуспех (на пример, кога има долги патеки за датотеки);
• покрај параметарот /restore, моравме да додадеме линии со параметарот /reset во случај папките да не се креирани, туку да се префрлени од претходно постоечки папки, со оневозможени права на наследување од root;
• Дел од скриптата за создавање групи требаше да се изврши на произволно dc на секоја шума, проблемот се однесува на административните сметки за секое дрво.

Општ заклучок: многу е чудно што сè уште нема комунални услуги со слична функционалност на пазарот. Се чини дека е можно да се имплементира слична функционалност врз основа на порталот Sharepoint.
Неразбирливо е и тоа што не е можно да се користат PoSH утилити за поставување права на папки на синолошки уреди.

По желба, подготвен сум да го споделам сценариото со креирање на некој проект на github доколку некој е заинтересиран.

Извор: www.habr.com