Görünür, mənim karma budur: standart tapşırıqları hər cür qeyri-ciddi üsullarla həyata keçirmək. Əgər kiminsə problemə fərqli baxışı varsa, lütfən müzakirə edin ki, məsələ həll olunsun.
Bir gözəl səhər, sənəd qovluqları olan layihələrin alt qovluqlarını ehtiva edən müxtəlif paylaşımlar üçün istifadəçilər qruplarına hüquqların paylanması üçün maraqlı bir tapşırıq ortaya çıxdı. Hər şey yaxşı idi və qovluqlara hüquqlar təyin etmək üçün bir skript yazılmışdır. Və sonra məlum oldu ki, qruplarda müxtəlif domenlərdən, müxtəlif meşələrdən olan istifadəçilər olmalıdır (). Deyək ki, paylaşımın özü PSI meşəsinin FB domenində qeydiyyatdan keçmiş Synology mediasında yerləşir. Tapşırıq: başqa meşədəki domenlərin istifadəçilərinə bu paylaşımın məzmununa və çox seçici şəkildə daxil olmaq imkanı vermək.
Bir müddət sonra texniki xüsusiyyətlər aşağıdakı formanı aldı:
- 2 meşə: PSI meşəsi, TG meşəsi.
- Hər bir meşənin 3 domeni var: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Meşələr arasında etimad əlaqəsi var; Synology bütün meşələrdə bütün Təhlükəsizlik qruplarını görür.
- Paylaşımlar və qovluqlar/alt qovluqlarda FullControl hüquqlarına malik FB domen administrator hesabları olmalıdır
- Qovluqların adları sistemləşdirilməlidir. Rəhbərlik layihə identifikatorlarını əlaqələndirdi; Mən Təhlükəsizlik qruplarının adını layihə ID-ləri ilə əlaqələndirmək qərarına gəldim.
- Sistem paylaşımlarındakı layihə qovluqlarında müvafiq giriş imtiyazları olan .xlsx faylında əvvəlcədən hazırlanmış struktur olmalıdır (R/RW/NA, burada NA – giriş yoxdur)
- Bir layihənin istifadəçilərinin/qrup üzvlərinin hüquqlarını yalnız həmin layihənin müəyyən kataloqları ilə məhdudlaşdırmaq mümkün olmalıdır. Qrup üzvlüyündən asılı olaraq istifadəçinin digər kataloqlara/layihələrə girişi olmaya bilər.
- Layihə qovluğu yaratarkən qruplar layihə identifikatorlarına uyğun adlarla müvafiq domenlərdə mümkün qədər avtomatik olaraq yaradılmalıdır.
Texniki spesifikasiyalar üçün qeydlər
- Etibar əlaqələrinin qurulması texniki spesifikasiyaların əhatə dairəsinə daxil edilmir
- Layihə ID nömrələri və Latın simvollarını ehtiva edir
- Bütün domenlər üçün layihə istifadəçi rollarının standart adları var
- Qovluqlar və giriş hüquqları (giriş matrisi) olan .xlsx faylı bütün layihə başlamazdan əvvəl hazırlanır.
- Layihələri həyata keçirərkən müvafiq domenlərdə istifadəçi qrupları yaratmaq mümkündür
- Avtomatlaşdırma standart MS Windows idarəetmə vasitələrindən istifadə etməklə əldə edilir
Texniki spesifikasiyaların həyata keçirilməsi
Bu tələblər rəsmiləşdirildikdən sonra kataloqların yaradılması və onlara hüquqların verilməsi üsullarının sınaqdan keçirilməsi üçün taktiki fasilə verildi. Layihəni çətinləşdirməmək üçün yalnız PowerShell-dən istifadə etmək nəzərdə tutulmuşdu. Daha əvvəl yazdığım kimi, skript alqoritmi olduqca sadə görünürdü:
- biz qrupları layihə identifikatorundan (məsələn, KC40587) əldə edilmiş adla və giriş matrisində göstərilən müvafiq rollarla qeyd edirik: KC40587-EN- mühəndis üçün; KC40587-PM – məhsul meneceri üçün və s.
- yaradılmış qrupların SID-lərini alırıq
- layihə qovluğunu və müvafiq qovluq dəstini qeydiyyatdan keçirin (alt qovluqların siyahısı onun yaradıldığı və giriş matrisində müəyyən edildiyi paydan asılıdır)
- giriş matrisinə uyğun olaraq layihənin yeni alt kataloqları üçün qruplara hüquqlar təyin edin.
1-ci mərhələdə qarşıya çıxan çətinliklər:
- skriptdə giriş matrisinin təyin edilməsi metodunun səhv başa düşülməsi (indi çoxölçülü massiv həyata keçirilir, lakin onu doldurmaq üçün yol .xlsx faylının/giriş matrisinin məzmunu əsasında axtarılır)
- PoSH istifadə edərək sinoloji disklərdə SMB paylaşımlarına giriş hüquqlarının təyin edilməsinin mümkünsüzlüyü (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), buna görə çox vaxt itirildi və hər şey mətn və cmd fayllarının aralıq deposunun yaradılmasını tələb edən icacls giriş hüquqlarının redaktə yardım proqramından istifadə edərək skriptlərə uyğunlaşdırılmalı idi.
Cari rejimdə cmd fayllarının icrası layihə üçün qovluğun qeydiyyatdan keçmə ehtiyacından asılı olaraq əl ilə idarə olunur.
Həmçinin məlum oldu ki, skript digər meşələrdəki qrupların qeydiyyatı üçün də icra edilməlidir (Cross-domen termini istifadə olunub) və bu nisbət təkcə 1-ə deyil, həm də 1-ə çox ola bilər.
Bu o deməkdir ki, qonşu meşə də daxil olmaqla digər çarpaz domenlərdən olan qruplar indi istənilən domenin resurslarına giriş iddia edə bilər. Vahidliyə nail olmaq üçün bütün meşələrin (qara şaquli ovallar) xidmət edilən bütün sahələrində OU-da simmetrik struktur yaratmaq qərara alındı. Necə deyərlər, orduda hər şey çirkin, lakin vahid olmalıdır:
Beləliklə, 80XXX layihəsini TG domenində qeydiyyatdan keçirərkən skript yerinə yetirir:
1. bu domendə və çarpaz domenlərdə müvafiq OU-nun (qırmızı üfüqi ovallar) yaradılması, yəni işçilərin bu resursa çıxışı olmalıdır.
2. kimi adları olan qruplarla OU-nu doldurmaq -, Harada:
- SRC_ domeni – işçiləri DST domen resurslarına çıxış əldə edəcək çarpaz domen
- DST_domain - resurslarına, əslində, giriş təmin edilməli olan, yəni hər şeyin başlandığı domen.
- - layihə nömrəsi
- ROLLAR – giriş matrisində sadalanan rolların adları.
3. bütün cəlb edilmiş domenlərin bütün qruplarının SID massivinin oxunması və konkret layihə alt qovluğuna hüquqları müəyyən edən fayla sonradan məlumat ötürülməsi üçün yadda saxlanılması
4. “icacKC “as-nasNNKCProjects” /bərpa C:TempKCKC40XXKC40XX.txt” icra edilə bilən fayl rejimində icacKC yardım proqramı tərəfindən istifadə üçün hüquqlar dəsti ilə mənbə fayllarının yaradılması (parametr /bərpa)
5. bütün layihə qovluqları üçün işə salınmış bütün icacls-ləri birləşdirən CMD faylının yaradılması
Daha əvvəl yazıldığı kimi, icra olunan faylın işə salınması əl ilə həyata keçirilir və icra nəticələrinin qiymətləndirilməsi də əl ilə həyata keçirilir.
Sonda qarşılaşmalı olduğumuz çətinliklər:
- layihə qovluğu artıq çoxlu sayda faylla doludursa, o zaman mövcud həcmlərdə icacls əmrini işə salmaq xeyli vaxt apara bilər və bəzi hallarda uğursuzluğa səbəb ola bilər (məsələn, uzun fayl yolları olduqda);
- /bərpa parametrinə əlavə olaraq, qovluqların yaradılmadığı, lakin kökdən miras hüquqlarının ləğv edildiyi, lakin əvvəllər mövcud qovluqlardan köçürüldüyü halda /reset parametri ilə sətirlər əlavə etməli olduq;
- Qruplar yaratmaq üçün skriptin bir hissəsi hər bir meşənin ixtiyari DC-də icra edilməli idi, problem hər bir ağac üçün inzibati hesablara aiddir.
Ümumi nəticə: çox qəribədir ki, hələ bazarda oxşar funksionallığı olan kommunal proqramlar yoxdur. Analoji funksiyanı Sharepoint portalı əsasında həyata keçirmək mümkün görünür.
Sinologiya cihazlarında qovluq hüquqlarını təyin etmək üçün PoSH utilitlərindən istifadə etmək mümkün olmadığı da anlaşılmazdır.
İstəsəniz, kimlərsə maraqlanarsa, github-da hansısa layihə yaradaraq ssenarini paylaşmağa hazıram.
Mənbə: www.habr.com