مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

بظاہر میرا کرما یہ ہے: معیاری کاموں کو ہر طرح کے غیر معمولی طریقوں سے نافذ کرنا۔ اگر کسی کا مسئلہ کے بارے میں مختلف نقطہ نظر ہے تو براہ کرم اس پر بات کریں تاکہ مسئلہ حل ہو سکے۔

ایک اچھی صبح ایک دلچسپ کام سامنے آیا جس میں مختلف شیئرز کے لیے صارفین کے گروپس میں حقوق تقسیم کیے گئے جن میں دستاویزات کے فولڈرز والے پروجیکٹس کے ذیلی فولڈرز شامل تھے۔ سب کچھ ٹھیک تھا اور فولڈرز کے حقوق تفویض کرنے کے لیے ایک اسکرپٹ لکھا گیا تھا۔ اور پھر یہ پتہ چلا کہ گروپوں میں مختلف ڈومینز کے صارفین، مختلف جنگلات سے (ان لوگوں کے لیے جو بھول گئے کہ یہ کیا ہے۔)۔ فرض کریں کہ شیئر خود Synology میڈیا پر واقع ہے، PSI جنگل کے FB ڈومین میں رجسٹرڈ ہے۔ ٹاسک: کسی دوسرے جنگل میں ڈومینز کے صارفین کو اس شیئر کے مواد تک رسائی حاصل کرنے کی اجازت دینے کے لیے، اور بہت منتخب طریقے سے۔

کچھ وقت کے بعد، تکنیکی وضاحتیں مندرجہ ذیل شکل اختیار کر لیں:

  • 2 جنگلات: PSI جنگل، TG جنگل۔

    مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

  • ہر جنگل میں 3 ڈومین ہوتے ہیں: PSI (ZG, PSI, FB)؛ ٹی جی (ٹی جی، ایچ یو، کے سی)۔
  • جنگلات کے درمیان اعتماد کا رشتہ ہے؛ Synology تمام جنگلات میں تمام سیکورٹی گروپوں کو دیکھتی ہے۔
  • شیئرز اور فولڈرز/سب فولڈرز کے پاس FB ڈومین ایڈمنسٹریٹر اکاؤنٹس کے ساتھ FullControl حقوق ہونے چاہئیں
  • فولڈرز کے ناموں کو منظم کیا جانا چاہئے۔ مینجمنٹ نے پروجیکٹ آئی ڈیز کو مربوط کیا؛ میں نے سیکیورٹی گروپس کا نام پروجیکٹ آئی ڈیز سے منسلک کرنے کا فیصلہ کیا۔
  • سسٹم شیئرز میں پروجیکٹ فولڈرز میں ایک .xlsx فائل میں پہلے سے تیار کردہ ڈھانچہ ہونا چاہیے، مناسب رسائی کے مراعات کے ساتھ (R/RW/NA، جہاں NA - کوئی رسائی نہیں ہے)

    مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

  • ایک پروجیکٹ کے صارفین/گروپ ممبران کے حقوق کو صرف اس پروجیکٹ کی مخصوص ڈائریکٹریوں تک محدود کرنا ممکن ہونا چاہیے۔ ہو سکتا ہے کہ صارف کو گروپ کی رکنیت کے لحاظ سے دیگر ڈائریکٹریز/پروجیکٹس تک رسائی حاصل نہ ہو۔
  • پروجیکٹ فولڈر بناتے وقت، گروپس کو جتنا ممکن ہوسکے خودکار طور پر مناسب ڈومینز میں پروجیکٹ IDs کے ناموں کے ساتھ بنایا جائے۔

تکنیکی وضاحتیں کے لئے نوٹس

  • اعتماد کے تعلقات قائم کرنا تکنیکی وضاحتوں کے دائرہ کار میں شامل نہیں ہے۔
  • پروجیکٹ ID نمبرز اور لاطینی حروف پر مشتمل ہے۔
  • تمام ڈومینز کے پروجیکٹ صارف کے کردار کے معیاری نام ہوتے ہیں۔
  • فولڈرز اور رسائی کے حقوق (ایکسیس میٹرکس) کے ساتھ ایک .xlsx فائل پورے پروجیکٹ کے آغاز سے پہلے تیار کی جاتی ہے۔
  • منصوبوں کو لاگو کرتے وقت، متعلقہ ڈومینز میں صارف گروپ بنانا ممکن ہے۔
  • معیاری ایم ایس ونڈوز ایڈمنسٹریشن ٹولز کا استعمال کرکے آٹومیشن حاصل کی جاتی ہے۔

تکنیکی وضاحتیں کا نفاذ

ان تقاضوں کو باضابطہ بنانے کے بعد، ڈائرکٹریز بنانے اور ان کو حقوق تفویض کرنے کے طریقوں کو جانچنے کے لیے ایک حکمت عملی کا وقفہ لیا گیا۔ اس کا مقصد صرف پاور شیل استعمال کرنا تھا، تاکہ پروجیکٹ کو پیچیدہ نہ بنایا جائے۔ جیسا کہ میں نے پہلے لکھا تھا، اسکرپٹ الگورتھم کافی آسان لگ رہا تھا:

  • ہم گروپوں کو پروجیکٹ ID (مثال کے طور پر KC40587) سے اخذ کردہ نام اور رسائی میٹرکس میں بیان کردہ متعلقہ کرداروں کے ساتھ رجسٹر کرتے ہیں: KC40587-EN- انجینئر کے لیے؛ KC40587-PM - پروڈکٹ مینیجر وغیرہ کے لیے۔
  • ہمیں بنائے گئے گروپس کے SID ملتے ہیں۔
  • پروجیکٹ فولڈر اور ڈائرکٹریز کے متعلقہ سیٹ کو رجسٹر کریں (سب فولڈرز کی فہرست اس شیئر پر منحصر ہے جس میں اسے بنایا گیا ہے اور رسائی میٹرکس میں اس کی وضاحت کی گئی ہے)
  • رسائی میٹرکس کے مطابق پروجیکٹ کی نئی ذیلی ڈائریکٹریوں کے لیے گروپوں کو حقوق تفویض کریں۔

مرحلہ 1 میں مشکلات کا سامنا کرنا پڑا:

  • اسکرپٹ میں رسائی میٹرکس کی وضاحت کرنے کے طریقہ کار کی غلط فہمی (ایک کثیر جہتی سرنی اب لاگو کی گئی ہے، لیکن اسے بھرنے کا راستہ .xlsx فائل/ایکسیس میٹرکس کے مواد کی بنیاد پر تلاش کیا جا رہا ہے)

    مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

  • 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 فائلوں کا عمل دستی طور پر کنٹرول کیا جاتا ہے۔

مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

اس سے یہ بھی پتہ چلا کہ اسکرپٹ کو دوسرے جنگلات میں گروپوں کو رجسٹر کرنے کے لیے بھی عمل میں لایا جانا چاہیے (کراس ڈومینز کی اصطلاح استعمال کی گئی تھی)، اور تناسب نہ صرف 1 سے ایک، بلکہ 1 سے بہت سے بھی ہو سکتا ہے۔

مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

اس کا مطلب ہے کہ دوسرے کراس ڈومینز کے گروپس، بشمول پڑوسی جنگل، اب کسی بھی ڈومین کے وسائل تک رسائی کا دعویٰ کر سکتے ہیں۔ یکسانیت حاصل کرنے کے لیے، تمام جنگلات (سیاہ عمودی بیضہ) کے تمام سروسڈ ڈومینز کے OU میں ایک سڈول ڈھانچہ بنانے کا فیصلہ کیا گیا۔ جیسا کہ وہ کہتے ہیں، فوج میں سب کچھ بدصورت ہونا چاہئے، لیکن وردی:

مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

اس طرح، TG ڈومین میں پروجیکٹ 80XXX کو رجسٹر کرتے وقت، اسکرپٹ پر عمل ہوتا ہے:

1. اس ڈومین اور کراس ڈومینز میں متعلقہ OU (سرخ افقی بیضہ) کی تخلیق، یعنی وہ ڈومین جن کے ملازمین کو اس وسائل تک رسائی حاصل ہونی چاہیے۔

2. OU کو ناموں کے ساتھ گروپوں سے بھرنا -، کہاں:

  • SRC_ ڈومین - کراس ڈومین جس کے ملازمین کو DST ڈومین وسائل تک رسائی حاصل ہوگی۔
  • DST_domain - وہ ڈومین جس کے وسائل تک، درحقیقت، رسائی فراہم کی جانی چاہیے، یعنی جس کی خاطر سب کچھ شروع کیا گیا تھا۔
  • - پروجیکٹ نمبر
  • رولز - رسائی میٹرکس میں درج کرداروں کے نام۔

3. تمام شامل ڈومینز کے تمام گروپس کے SIDs کو پڑھنا اور اسے بعد میں ڈیٹا کی منتقلی کے لیے فائل میں محفوظ کرنا جو ایک مخصوص پروجیکٹ سب فولڈر کے حقوق کی وضاحت کرتا ہے۔

4. ایگزیکیوٹیبل فائل موڈ "icacKC" as-nasNNKCprojects" /restore C:TempKCKC40XXKC40XX.txt" میں icacKC یوٹیلیٹی کے استعمال کے لیے حقوق کے ایک سیٹ کے ساتھ سورس فائلوں کی نسل (پیرامیٹر /بحال)

5. ایک CMD فائل بنانا جو تمام پروجیکٹ فولڈرز کے لیے لانچ کیے گئے تمام icacls کو یکجا کرے۔

مختلف جنگلات سے ڈومین صارفین کو حقوق کی بڑے پیمانے پر تفویض

جیسا کہ پہلے لکھا گیا تھا، قابل عمل فائل کو لانچ کرنا دستی طور پر کیا جاتا ہے اور عملدرآمد کے نتائج کی تشخیص بھی دستی طور پر کی جاتی ہے۔

آخر میں ہمیں جن مشکلات کا سامنا کرنا پڑا:

  • اگر پروجیکٹ فولڈر پہلے ہی بڑی تعداد میں فائلوں سے بھرا ہوا ہے، تو موجودہ والیومز پر icacls کمانڈ کو چلانے میں کافی وقت لگ سکتا ہے، اور بعض صورتوں میں ناکامی کا باعث بنتا ہے (مثال کے طور پر، جب فائل کے لمبے راستے ہوں)؛
  • /restore پیرامیٹر کے علاوہ، ہمیں /reset پیرامیٹر کے ساتھ لائنیں شامل کرنا پڑتی ہیں اگر فولڈرز نہیں بنائے گئے تھے، لیکن پہلے سے موجود فولڈرز سے منتقل کیے گئے تھے، جڑ سے وراثت کے حقوق کو غیر فعال کر دیا گیا تھا۔
  • گروپس بنانے کے لیے اسکرپٹ کے حصے کو ہر جنگل کے من مانی ڈی سی پر عمل میں لانا تھا، مسئلہ ہر درخت کے انتظامی اکاؤنٹس سے متعلق ہے۔

عمومی نتیجہ: یہ بہت ہی عجیب بات ہے کہ ابھی تک مارکیٹ میں ایسی کوئی افادیت موجود نہیں ہے۔ ایسا لگتا ہے کہ شیئرپوائنٹ پورٹل کی بنیاد پر اسی طرح کی فعالیت کو نافذ کرنا ممکن ہے۔
یہ بات بھی سمجھ سے باہر ہے کہ سائنولوجی ڈیوائسز پر فولڈر کے حقوق ترتیب دینے کے لیے PoSH یوٹیلیٹیز کا استعمال ممکن نہیں ہے۔

اگر چاہیں تو، اگر کوئی دلچسپی رکھتا ہے تو میں گیتھب پر کچھ پروجیکٹ بنا کر اسکرپٹ شیئر کرنے کے لیے تیار ہوں۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں