ظاهرا کارمای من این است: اجرای وظایف استاندارد به انواع روش های غیر پیش پا افتاده. اگر کسی دیدگاه متفاوتی از مشکل دارد، لطفاً در مورد آن صحبت کنید تا مشکل حل شود.
یک صبح خوب، کار جالبی برای توزیع حقوق بین گروه‌هایی از کاربران برای اشتراک‌گذاری‌های مختلف که حاوی زیرپوشه‌های پروژه‌ها با پوشه‌های اسناد هستند، پیش آمد. همه چیز خوب بود و یک اسکریپت برای اختصاص حقوق به پوشه ها نوشته شد. و سپس معلوم شد که گروه ها باید شامل کاربرانی از دامنه های مختلف، از جنگل های مختلف باشد (). فرض کنید خود سهم در رسانه Synology قرار دارد که در دامنه FB جنگل PSI ثبت شده است. وظیفه: به کاربران دامنه های موجود در جنگل دیگر اجازه می دهد تا به محتویات این اشتراک گذاری دسترسی داشته باشند و بسیار انتخابی.
پس از مدتی مشخصات فنی به شکل زیر درآمد:
- 2 جنگل: جنگل PSI، جنگل TG.
- هر جنگل دارای 3 دامنه است: PSI (ZG، PSI، FB). TG (TG، HU، KC).
- یک رابطه اعتماد بین جنگل ها وجود دارد؛ Synology همه گروه های امنیتی را در همه جنگل ها می بیند.
- اشتراک‌ها و پوشه‌ها/زیرپوشه‌ها باید دارای حساب‌های سرپرست دامنه FB با حقوق FullControl باشند
- نام پوشه ها باید سیستماتیک شود. مدیریت شناسه‌های پروژه را هماهنگ کرد؛ من تصمیم گرفتم نام گروه‌های امنیتی را به شناسه‌های پروژه پیوند دهم.
- پوشه‌های پروژه در اشتراک‌گذاری‌های سیستم باید دارای ساختاری باشند که از قبل در یک فایل xlsx. با امتیازات دسترسی مناسب (R/RW/NA، جایی که NA – بدون دسترسی) آماده شده است.
- باید بتوان حقوق کاربران/اعضای گروه یک پروژه را فقط به دایرکتوری های خاصی از آن پروژه محدود کرد. بسته به عضویت در گروه، کاربر ممکن است به دایرکتوری ها/پروژه های دیگر دسترسی نداشته باشد.
- هنگام ایجاد یک پوشه پروژه، گروه ها باید تا حد امکان به صورت خودکار در دامنه های مناسب با نام های مربوط به شناسه پروژه ایجاد شوند.
نکات مربوط به مشخصات فنی
- ایجاد روابط اعتماد در محدوده مشخصات فنی گنجانده نشده است
- شناسه پروژه شامل اعداد و حروف لاتین است
- نقش های کاربر پروژه برای همه دامنه ها دارای نام های استاندارد هستند
- یک فایل xlsx با پوشه ها و حقوق دسترسی (ماتریس دسترسی) قبل از شروع کل پروژه آماده می شود.
- هنگام اجرای پروژه ها، امکان ایجاد گروه های کاربری در دامنه های مربوطه وجود دارد
- اتوماسیون با استفاده از ابزار استاندارد مدیریت MS Windows به دست می آید
اجرای مشخصات فنی
پس از رسمی‌سازی این الزامات، یک مکث تاکتیکی برای آزمایش روش‌های ایجاد دایرکتوری‌ها و اختصاص حقوق به آنها انجام شد. در نظر گرفته شده بود که فقط از PowerShell استفاده شود تا پروژه را پیچیده نکند. همانطور که قبلا نوشتم، الگوریتم اسکریپت بسیار ساده به نظر می رسید:
- ما گروه ها را با نامی که از شناسه پروژه گرفته شده است (به عنوان مثال KC40587) و نقش های مربوطه مشخص شده در ماتریس دسترسی ثبت می کنیم: KC40587-EN- برای مهندس. KC40587-PM - برای مدیر محصول و غیره
- SID گروه های ایجاد شده را می گیریم
- پوشه پروژه و مجموعه دایرکتوری مربوطه را ثبت کنید (لیست زیرپوشه ها بستگی به سهمی دارد که در آن ایجاد و در ماتریس دسترسی تعریف شده است)
- با توجه به ماتریس دسترسی به گروه ها برای زیر شاخه های جدید پروژه حقوق اختصاص دهید.
مشکلات پیش آمده در مرحله 1:
- سوء تفاهم از روش تعیین ماتریس دسترسی در اسکریپت (اکنون یک آرایه چند بعدی پیاده سازی شده است، اما مسیر پر کردن آن بر اساس محتویات فایل/ماتریس دسترسی .xlsx جستجو می شود)
- عدم امکان تنظیم حقوق دسترسی در اشتراک‌های SMB در درایوهای synology با استفاده از 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 به بسیاری نیز باشد.
این بدان معناست که گروه‌هایی از سایر دامنه‌های متقابل، از جمله جنگل همسایه، اکنون می‌توانند ادعای دسترسی به منابع هر دامنه را داشته باشند. برای دستیابی به یکنواختی، تصمیم گرفته شد که یک ساختار متقارن در OU همه حوزه های سرویس دهی شده همه جنگل ها (بیضی های عمودی سیاه) ایجاد شود. همانطور که می گویند ، در ارتش همه چیز باید زشت ، اما یکنواخت باشد:
بنابراین، هنگام ثبت پروژه 80XXX در دامنه TG، اسکریپت اجرا می شود:
1. ایجاد OU مربوطه (بیضی های افقی قرمز) در این دامنه و دامنه های متقابل، یعنی دامنه هایی که کارکنان آنها باید به این منبع دسترسی داشته باشند.
2. پر کردن OU با گروه هایی با نام هایی مانند -، جایی که:
- دامنه SRC_ - دامنه متقابلی که کارکنان آن به منابع دامنه DST دسترسی خواهند داشت
- DST_domain - دامنه ای که در واقع باید به منابع آن دسترسی داشته باشد، یعنی به خاطر آن همه چیز شروع شده است.
- - شماره پروژه
- ROLES - نام نقش های فهرست شده در ماتریس دسترسی.
3. خواندن آرایه SIDهای همه گروه‌های همه دامنه‌های درگیر و ذخیره آن برای انتقال داده‌های بعدی به فایلی که حقوق یک زیرپوشه پروژه خاص را تعریف می‌کند.
4. تولید فایل های منبع (پارامتر /بازیابی) با مجموعه ای از حقوق برای استفاده توسط ابزار icacKC در حالت فایل اجرایی "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. ایجاد یک فایل CMD که تمام icacl های راه اندازی شده را برای همه پوشه های پروژه ترکیب می کند
همانطور که قبلا نوشته شد، راه اندازی فایل اجرایی به صورت دستی و ارزیابی نتایج اجرا نیز به صورت دستی انجام می شود.
مشکلاتی که در نهایت با آن مواجه شدیم:
- اگر پوشه پروژه از قبل با تعداد زیادی فایل پر شده باشد، اجرای دستور icacls روی حجم های موجود می تواند زمان قابل توجهی را ببرد و در برخی موارد منجر به شکست شود (مثلاً زمانی که مسیرهای فایل طولانی وجود دارد).
- علاوه بر پارامتر /restore، ما مجبور بودیم خطوطی را با پارامتر /reset اضافه کنیم در صورتی که پوشه‌ها ایجاد نشده باشند، اما از پوشه‌های موجود قبلی منتقل شده‌اند، با حقوق ارث بری از ریشه غیرفعال شده است.
- بخشی از اسکریپت برای ایجاد گروه‌ها باید روی یک dc دلخواه هر جنگل اجرا می‌شد، مشکل مربوط به حساب‌های اداری برای هر درخت است.
نتیجه گیری کلی: بسیار عجیب است که هنوز هیچ ابزاری با عملکرد مشابه در بازار وجود ندارد. به نظر می رسد امکان پیاده سازی عملکرد مشابه بر اساس پورتال Sharepoint وجود داشته باشد.
همچنین غیرقابل درک است که نمی توان از ابزارهای PoSH برای تنظیم حقوق پوشه در دستگاه های سینولوژی استفاده کرد.
در صورت تمایل، من آماده هستم تا در صورت تمایل، اسکریپت را با ایجاد پروژه ای در github به اشتراک بگذارم.
منبع: www.habr.com