विभिन्न जंगलों से डोमेन उपयोगकर्ताओं को अधिकारों का बड़े पैमाने पर असाइनमेंट

जाहिरा तौर पर मेरा कर्म यह है: सभी प्रकार के गैर-तुच्छ तरीकों से मानक कार्यों को लागू करना। यदि किसी के पास समस्या का एक अलग दृष्टिकोण है - मैं इस मुद्दे पर चर्चा करने के लिए चर्चा करने के लिए कहता हूं।

एक ठीक सुबह, एक दिलचस्प कार्य दिखाई दिया: दस्तावेज़ फ़ोल्डर्स के साथ प्रोजेक्ट सबफ़ोल्डर्स वाले विभिन्न गेंदों पर उपयोगकर्ता समूहों को अधिकार वितरित करने के लिए। सब कुछ ठीक था और एक स्क्रिप्ट को फ़ोल्डर्स को अधिकार सौंप दिया गया था। और फिर यह पता चला कि समूहों में अलग-अलग जंगलों के उपयोगकर्ताओं को अलग-अलग जंगलों से होना चाहिए ( उन लोगों के लिए जो यह भूल गए कि यह क्या है )। मान लीजिए कि गेंद खुद PSI वन के FB डोमेन में पंजीकृत Synology मीडिया पर होस्ट की गई है। उद्देश्य: किसी अन्य फ़ॉरेस्ट में डोमेन के उपयोगकर्ताओं को इस बॉल की सामग्री तक पहुंच प्रदान करने के लिए, और बहुत ही चुनिंदा रूप से।

निम्नलिखित फॉर्म में थोड़ी देर के बाद TK:

• 2 वन: पीएसआई वन, टीजी वन।
  
  
• प्रत्येक जंगल में 3 डोमेन होते हैं: PSI (ZG, PSI, FB); टीजी (टीजी, एचयू, केसी)।
• जंगलों के बीच एक भरोसेमंद रिश्ता है, Synology सभी जंगलों में सभी सुरक्षा समूह देखता है।
• गुब्बारे और फ़ोल्डरों / सबफ़ोल्डर्स में फुलकंट्रोल अधिकारों के साथ एफबी डोमेन प्रवेश खाते होने चाहिए
• गुब्बारा फ़ोल्डरों के नामों को व्यवस्थित किया जाना चाहिए। प्रबंधन प्रोजेक्ट आईडी पर बातचीत कर रहा था। मैंने प्रोजेक्ट आईडी में सुरक्षा समूहों के नाम को निर्दिष्ट करने का निर्णय लिया।
• सिस्टम गेंदों में प्रोजेक्ट फ़ोल्डरों में .xlsx फ़ाइल में अग्रिम रूप से तैयार की गई संरचना होनी चाहिए, जिसमें उपयुक्त पहुँच विशेषाधिकार (R / RW / NA, जहाँ NA - कोई पहुँच नहीं है)
  
  
• किसी परियोजना के उपयोगकर्ताओं / समूह के सदस्यों के अधिकारों को इस परियोजना की केवल कुछ निर्देशिकाओं तक सीमित करना संभव होना चाहिए। समूह सदस्यता के अनुसार उपयोगकर्ता के पास अन्य निर्देशिकाओं / परियोजनाओं तक पहुंच नहीं हो सकती है।
• प्रोजेक्ट फ़ोल्डर बनाते समय, संबंधित प्रोजेक्ट आईडी के नाम वाले संबंधित डोमेन में समूहों को यथासंभव स्वचालित रूप से बनाया जाना चाहिए।

टीओआर को नोट्स

• आत्मविश्वास से भरे रिश्ते टीके का हिस्सा नहीं हैं
• प्रोजेक्ट आईडी में नंबर और लैटिन अक्षर होते हैं
• सभी डोमेन के लिए परियोजना उपयोगकर्ता भूमिकाएँ सामान्य नाम हैं
• संपूर्ण प्रोजेक्ट की शुरुआत से पहले फ़ोल्डर्स और अनुमतियों (एक्सेस मैट्रिक्स) के साथ एक .xlsx फ़ाइल तैयार की जाती है
• परियोजनाओं को लागू करते समय, संबंधित डोमेन में उपयोगकर्ता समूह बनाना संभव है
• मानक MS Windows व्यवस्थापन उपकरण का उपयोग करके स्वचालन प्राप्त किया जाता है

टीके कार्यान्वयन

इन आवश्यकताओं को औपचारिक रूप देने के बाद, निर्देशिका बनाने और उन्हें अधिकार प्रदान करने के तरीकों का परीक्षण करने के लिए एक सामरिक विराम लिया गया। यह केवल PowerShell का उपयोग करने वाला था, ताकि परियोजना को जटिल न बनाया जा सके। जैसा कि मैंने पहले लिखा था, स्क्रिप्ट एल्गोरिथ्म काफी सरल लग रहा था:

• प्रोजेक्ट आईडी से प्राप्त नाम के साथ समूह रजिस्टर करें (उदाहरण के लिए, KC40587) और एक्सेस मैट्रिक्स में निर्दिष्ट संबंधित भूमिकाएँ: KC40587-EN- इंजीनियर के लिए; KC40587-PM - उत्पाद प्रबंधक के लिए, आदि।
• निर्मित समूहों की SID प्राप्त करें
• प्रोजेक्ट फ़ोल्डर और निर्देशिकाओं के संगत सेट को पंजीकृत करें (सबफ़ोल्डर्स की सूची उन गेंदों पर निर्भर करती है जिसमें इसे बनाया गया है और एक्सेस मैट्रिक्स में परिभाषित किया गया है)
• प्रोजेक्ट की नई उपनिर्देशिकाओं तक पहुंच मैट्रिक्स के अनुसार समूहों को अधिकार सौंपें।

चरण 1 में कठिनाइयों का सामना करना पड़ा:

• स्क्रिप्ट में एक्सेस मैट्रिक्स सेट करने के तरीके की समझ की कमी (एक बहुआयामी सरणी अब लागू की जाती है, लेकिन इसे भरने का एक तरीका .xlsx फ़ाइल / एक्सेस मैट्रिक्स की सामग्री के आधार पर मांगा गया है।
  
  
• PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9f10-89256cf07e65/error-using-setacl-on-nas- का उपयोग करके एसएनबी गेंदों में एक्सेस अधिकार स्थापित करने की असंभवता -share? फोरम = winserverpowershell), जिसके कारण बहुत समय खो गया था और मुझे आइकॉल्स की अनुमति संपादन उपयोगिता का उपयोग करके स्क्रिप्ट के लिए सब कुछ अनुकूल करना पड़ा, जिसके लिए पाठ और cmd फ़ाइलों के मध्यवर्ती भंडार के निर्माण की आवश्यकता थी।

वर्तमान मोड में, प्रोजेक्ट के लिए फ़ोल्डर रजिस्टर करने की आवश्यकता के तथ्य पर, cmd-files का निष्पादन मैन्युअल रूप से नियंत्रित किया जाता है।



यह भी पता चला कि स्क्रिप्ट को निष्पादित किया जाना चाहिए, जिसमें अन्य जंगलों में समूहों को पंजीकृत करना (क्रॉस-डोमेन शब्द का उपयोग करना) शामिल है, और अनुपात न केवल 1 से एक हो सकता है, बल्कि कई के लिए 1 भी हो सकता है।



इसका मतलब यह है कि पड़ोसी जंगल सहित अन्य क्रॉस-डोमेन के समूह अब डोमेन के संसाधनों तक पहुंच का दावा कर सकते हैं। एकरूपता प्राप्त करने के लिए, सभी वनों (काले ऊर्ध्वाधर अंडाकार) के सभी सेवा वाले डोमेन के OU में एक सममित संरचना बनाने का निर्णय लिया गया। जैसा कि वे कहते हैं, सेना में सब कुछ बदसूरत होना चाहिए, लेकिन वर्दी:



इस प्रकार, TG डोमेन में 80XXX प्रोजेक्ट को पंजीकृत करते समय, स्क्रिप्ट निष्पादित होती है:

1. इस डोमेन और क्रॉस-डोमेन में संबंधित OU (लाल क्षैतिज अंडाकार) का निर्माण, अर्थात, उन डोमेन जिनके कर्मचारियों को इस संसाधन तक पहुंच होना आवश्यक है।

2. फॉर्म के नामों के साथ समूह के साथ OU भरना <SRC_ डोमेन> <DST_domain> <ID_project> -, जहां:

• SRC_ डोमेन - एक क्रॉस-डोमेन जिसके कर्मचारियों के पास डीएसटी डोमेन संसाधनों तक पहुंच होगी
• DST_domain - डोमेन, जिसके संसाधनों के लिए, वास्तव में, पहुँच प्रदान की जानी चाहिए, अर्थात्, जिसके लिए सब कुछ शुरू किया गया था
• <ID_project> - प्रोजेक्ट नंबर
• रोल्स - अभिगम मैट्रिक्स में सूचीबद्ध भूमिकाओं के नाम।

3. सभी शामिल डोमेन के सभी समूहों के SID सरणी को पढ़ना और एक विशेष परियोजना सबफ़ोल्डर के अधिकारों को निर्धारित करने वाली फ़ाइल के लिए बाद में डेटा हस्तांतरण के लिए इसे सहेजना

4. निष्पादन योग्य फाइल मोड "icacKC" \\ as-nasNN \ KC \ परियोजनाओं "में icacKC उपयोगिता का उपयोग करने के लिए अनुमतियों के एक सेट के साथ स्रोत फ़ाइलों (पैरामीटर / पुनर्स्थापना) की पीढ़ी / पुनर्स्थापना C: \ Temp / KC \ KC40XX \ KC40XX.txt"

5. एक सीएमडी फ़ाइल बनाना जो सभी प्रोजेक्ट फ़ोल्डरों के लिए लॉन्च किए गए सभी आइकनों को जोड़ती है



जैसा कि पहले लिखा गया था, निष्पादन योग्य फ़ाइल मैन्युअल रूप से लॉन्च की गई है और निष्पादन के परिणामों का मूल्यांकन भी मैन्युअल रूप से किया जाता है।

अंत में कठिनाइयों का सामना करना पड़ा:

• यदि प्रोजेक्ट फ़ोल्डर पहले से ही बड़ी संख्या में फ़ाइलों से भरा है, तो उपलब्ध संस्करणों पर icacls कमांड को काम करने में काफी समय लग सकता है, और कुछ मामलों में विफलता का कारण बना (उदाहरण के लिए, यदि लंबे फ़ाइल पथ हैं);
• / पुनर्स्थापना विकल्प के अलावा, मुझे उस स्थिति में / रीसेट विकल्प के साथ लाइनों को जोड़ना था, जब फ़ोल्डर बनाए नहीं गए थे, लेकिन पहले से मौजूद फ़ोल्डर से स्थानांतरित किए गए थे, उत्तराधिकार के अधिकार को रूट से बंद कर दिया गया था;
• समूह बनाने के लिए स्क्रिप्ट का हिस्सा प्रत्येक जंगल के एक मनमाने ढंग से डीसी पर निष्पादित किया जाना था, समस्या प्रत्येक पेड़ के लिए प्रशासनिक खातों की चिंता करती है।

सामान्य निष्कर्ष: यह बहुत अजीब है कि बाजार पर समान कार्यक्षमता वाले कोई उपयोगिताओं अभी तक नहीं हैं। शेयरपॉइंट पोर्टल के आधार पर ऐसी कार्यक्षमता को लागू करना संभव लगता है।
यह एक असंगत तथ्य भी प्रदान करता है कि साइनस उपकरणों पर एक फ़ोल्डर में अनुमतियों को स्थापित करने के लिए PoSH उपयोगिताओं का उपयोग करना संभव नहीं है।

यदि किसी के लिए यह दिलचस्प है, तो मैं स्क्रिप्ट को किसी प्रकार का प्रोजेक्ट बनाकर साझा करने के लिए तैयार हूं।