Görünüşe göre benim karmam şu: standart görevleri önemsiz olmayan her türlü yolla uygulamak. Birisinin sorunla ilgili farklı bir vizyonu varsa, lütfen konuyu tartışın ki sorun çözülebilsin.
Güzel bir sabah, belge klasörleri içeren projelerin alt klasörlerini içeren farklı paylaşımlar için hakları kullanıcı gruplarına dağıtmak gibi ilginç bir görev ortaya çıktı. Her şey yolundaydı ve klasörlere hak atamak için bir komut dosyası yazıldı. Ve sonra grupların farklı ormanlardan, farklı alanlardan kullanıcıları içermesi gerektiği ortaya çıktı (). Paylaşımın PSI ormanının FB etki alanında kayıtlı Synology ortamında bulunduğunu varsayalım. Görev: Başka bir ormandaki etki alanlarının kullanıcılarının bu paylaşımın içeriğine çok seçici bir şekilde erişmesine izin vermek.
Bir süre sonra teknik özellikler şu şekli aldı:
- 2 orman: PSI ormanı, TG ormanı.
- Her ormanın 3 alanı vardır: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Ormanlar arasında bir güven ilişkisi vardır; Synology, tüm ormanlardaki tüm Güvenlik gruplarını görür.
- Paylaşımlar ve klasörler/alt klasörler, FullControl haklarına sahip FB etki alanı yönetici hesaplarına sahip olmalıdır
- Klasörlerin adları sistematize edilmelidir. Yönetim proje kimliklerini koordine etti; Güvenlik gruplarının adını proje kimliklerine bağlamaya karar verdim.
- Sistem paylaşımlarındaki proje klasörleri, uygun erişim ayrıcalıklarına (R/RW/NA, burada NA - erişim yok) sahip, .xlsx dosyasında önceden hazırlanmış bir yapı içermelidir.
- Bir projedeki kullanıcıların/grup üyelerinin haklarını o projenin yalnızca belirli dizinleriyle sınırlamak mümkün olmalıdır. Kullanıcı, grup üyeliğine bağlı olarak diğer dizinlere/projelere erişim sağlayamayabilir.
- Bir proje klasörü oluştururken, uygun alanlarda proje kimliklerine karşılık gelen adlarla gruplar mümkün olduğunca otomatik olarak oluşturulmalıdır.
Teknik spesifikasyonlara ilişkin notlar
- Güven ilişkisi kurmak teknik şartname kapsamına dahil değildir
- Proje kimliği sayıları ve Latin karakterlerini içerir
- Tüm etki alanları için proje kullanıcı rollerinin standart adları vardır
- Tüm projenin başlamasından önce klasörleri ve erişim haklarını (erişim matrisi) içeren bir .xlsx dosyası hazırlanır
- Projeleri uygularken ilgili alanlarda kullanıcı grupları oluşturmak mümkündür.
- Otomasyon, standart MS Windows yönetim araçları kullanılarak gerçekleştirilir
Teknik şartnamelerin uygulanması
Bu gereklilikleri resmileştirdikten sonra, dizin oluşturma ve bunlara hak atama yöntemlerini test etmek için taktiksel bir duraklama yapıldı. Projeyi karmaşıklaştırmamak için yalnızca PowerShell kullanılması amaçlanmıştı. Daha önce yazdığım gibi senaryo algoritması oldukça basit görünüyordu:
- grupları proje kimliğinden türetilen bir adla (örneğin KC40587) ve erişim matrisinde belirtilen ilgili rollerle kaydederiz: mühendis için KC40587-EN-; KC40587-PM – ürün yöneticisi vb. için
- oluşturulan grupların SID'lerini alıyoruz
- proje klasörünü ve karşılık gelen dizin kümesini kaydedin (alt klasörlerin listesi, erişim matrisinde oluşturulduğu ve tanımlandığı paylaşıma bağlıdır)
- erişim matrisine göre projenin yeni alt dizinleri için gruplara haklar atayın.
1. aşamada karşılaşılan zorluklar:
- komut dosyasında erişim matrisini belirleme yönteminin yanlış anlaşılması (şimdi çok boyutlu bir dizi uygulandı, ancak onu doldurmanın yolu .xlsx dosyasının/erişim matrisinin içeriğine göre aranıyor)
- PoSH kullanarak synology sürücülerindeki KOBİ paylaşımlarında erişim haklarını ayarlamanın imkansızlığı (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), bu nedenle çok zaman kaybedildi ve her şeyin, metin ve cmd dosyalarının ara deposunun oluşturulmasını gerektiren icacls erişim hakları düzenleme yardımcı programını kullanarak komut dosyalarına uyarlanması gerekiyordu.
Geçerli modda, proje için bir klasör kaydetme ihtiyacına bağlı olarak cmd dosyalarının yürütülmesi manuel olarak kontrol edilir.
Ayrıca, komut dosyasının diğer ormanlardaki grupları kaydetmek için de yürütülmesi gerektiği (Etki Alanları Arası terimi kullanıldı) ve oranın yalnızca 1'e bir değil, aynı zamanda 1'e çok olabileceği de ortaya çıktı.
Bu, komşu orman da dahil olmak üzere diğer etki alanlarındaki grupların artık herhangi bir etki alanının kaynaklarına erişim talebinde bulunabileceği anlamına gelir. Tekdüzeliği sağlamak için, tüm ormanların hizmet verilen tüm alanlarının OU'sunda simetrik bir yapı (siyah dikey ovaller) oluşturmaya karar verildi. Dedikleri gibi, orduda her şey çirkin ama tek tip olmalı:
Böylece, 80XXX projesini TG etki alanına kaydederken komut dosyası şunları yürütür:
1. Bu etki alanında ve etki alanları arasında, yani çalışanlarının bu kaynağa erişmesi gereken etki alanlarında karşılık gelen kuruluş biriminin (kırmızı yatay ovaller) oluşturulması.
2. OU'yu aşağıdaki gibi adlara sahip gruplarla doldurmak -, Nerede:
- SRC_ alan adı – çalışanlarının DST alan kaynaklarına erişebileceği alanlar arası
- DST_domain - aslında kaynaklara erişim sağlanması gereken, yani her şeyin başlatıldığı alan adı
- - Proje numarası
- ROLLER – erişim matrisinde listelenen rollerin adları.
3. İlgili tüm etki alanlarının tüm gruplarının SID dizisini okumak ve bunu belirli bir proje alt klasörünün haklarını tanımlayan bir dosyaya daha sonra veri aktarımı için kaydetmek
4. “icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt" yürütülebilir dosya modunda icacKC yardımcı programı tarafından kullanılmak üzere bir dizi hakla birlikte kaynak dosyaların oluşturulması (parametre /restore)
5. tüm proje klasörleri için başlatılan tüm icacl'leri birleştiren bir CMD dosyası oluşturmak
Daha önce yazıldığı gibi, yürütülebilir dosyanın başlatılması manuel olarak yapılır ve yürütme sonuçlarının değerlendirilmesi de manuel olarak yapılır.
Sonunda yüzleşmek zorunda kaldığımız zorluklar:
- proje klasörü zaten çok sayıda dosyayla doluysa, mevcut birimlerde icacls komutunu çalıştırmak oldukça zaman alabilir ve bazı durumlarda başarısızlığa yol açabilir (örneğin, uzun dosya yolları olduğunda);
- /restore parametresine ek olarak, klasörlerin oluşturulmaması, ancak daha önce var olan klasörlerden kökten miras hakları devre dışı bırakılarak aktarılması durumunda /reset parametreli satırlar eklemek zorunda kaldık;
- Grup oluşturmaya yönelik komut dosyasının bir kısmının, her ormanın rastgele bir DC'sinde yürütülmesi gerekiyordu; sorun, her ağaç için idari hesaplarla ilgilidir.
Genel sonuç: Piyasada henüz benzer işlevselliğe sahip hiçbir yardımcı programın bulunmaması çok garip. Sharepoint portalına dayalı olarak benzer işlevlerin uygulanması mümkün görünüyor.
Ayrıca sinology cihazlarda klasör haklarını ayarlamak için PoSH yardımcı programlarının kullanılmasının mümkün olmadığı da anlaşılmaz.
İstenirse, ilgilenen olursa github üzerinde bir proje oluşturarak senaryoyu paylaşmaya hazırım.
Kaynak: habr.com