مشكلات تتعلق بمجلدات ADGroup وSet-ACL ومجلدات الشبكة الجديدة

Question

إنني ألعب باستخدام بعض أكواد PowerShell لإنشاء مجموعات أمان AD ديناميكيًا ثم تطبيقها على المجلدات الموجودة على مشاركة عبر الشبكة، ولكن أواجه مشكلات في حل المجموعة التي تم إنشاؤها حديثًا.

النظر في هذا:

import-module activedirectory

for ($i = 0; $i -lt 10; $i++) {

  $group = New-ADGroup -Path "OU=Groups,OU=Department,DC=Domain,DC=Network" -Name "z-test-group-$i" -GroupScope DomainLocal -GroupCategory Security -PassThru
  $acl = Get-Acl C:\Temp
  $permission = $group.SID,"FullControl","Allow"
  $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
  $acl.SetAccessRule($accessRule)
  $acl | Set-Acl C:\Temp

}

الذي يعمل بشكل جيد.

ومع ذلك، إذا قمت بتغيير المجلد إلى مجلد شبكة، مثل G: emp، أو \\domain.network\DFS\GroupShare emp، أحصل على الرسالة "فشل الأسلوب مع رمز الخطأ غير المتوقع 1337".

لقد تعبت من استخدام SetACL.exe وتلقيت خطأ مشابهًا:

C:\Temp\SetACL.exe -on "\\domani.network\dfs\GroupShare\Temp" -ot file -actn ace -ace "n:$GroupSID;p:full;s:y"

SetACL finished with error(s): 
SetACL error message: The call to SetNamedSecurityInfo () failed
Operating system error message: The security ID structure is invalid.
INFORMATION: Processing ACL of: <\\?\UNC\domain.network\dfs\GroupShare\Temp>

إذا انتظرت من 10 إلى 20 ثانية على سبيل المثال، وقمت بتشغيل جزء Set-ACL (أو SetACL.exe) من التعليمات البرمجية مرة أخرى، فسيتم إكماله بنجاح.

في البداية اعتقدت أن هذا مرتبط مباشرة بوحدات تحكم المجال (4 منها عبارة عن مزيج من 2003 و2008 R2)، ولكن حقيقة أنها تعمل بشكل جيد على المجلدات المحلية كانت مثيرة للاهتمام (ومزعجة).

لقد قمت بتتبع Wireshark أثناء تنفيذ التعليمات البرمجية على مجلد محلي ثم على مجلد شبكة.يتمثل الاختلاف الرئيسي في محاولة تطبيق قوائم ACL على مجلد الشبكة، حيث أرى عمليات بحث LDAP و(من بين أشياء أخرى) استجابة SMB التالية:

NT Trans Response, FID: 0x0040, NT SET SECURITY DESC, Error: STATUS_INVALID_SID

ما أفترضه هو ما يتسبب في فشل أمر Set-ACL.

نظام ملفات الشبكة الأساسي هو EMC Celerra 6.0.xx.أنا غير معتاد على هذه التقنية، ولكن مما أفهمه أنها تحتوي على نوع من ذاكرة التخزين المؤقت لـ SID وهو ما يفسر الخطأ أعلاه (لا يعرف بعد المجموعة الجديدة على الرغم من أن AD يعرفها).

لذلك أعتقد أن هناك سؤالين:

1. هل هناك أي طريقة للتغلب على هذا (PowerShell/C# ECT) لا ينطوي على النوم/الانتظار؟أي ، قم بتعيين ACL على الرغم من أن SID غير صالح؟
2. إذا كانت EMC Celerra هي المشكلة (أفترض أنها) ، هل هناك أي طريقة يمكنني إجبارها على تحديث "ذاكرة التخزين المؤقت SID" أو أي شيء قد يكون؟

أملك يقرأ متنوع مقالات حول هذه المشكلة، ولكن لا يبدو أن أيًا منها لديه حل فعال (أو يعمل لصالحي).

شكرا لمساعدتك.

ريس.

Answer 1

اكتشفه!

تم التعديل acl.mappingErrorAction على EMC Celerra NAS الخاص بنا.

تم ضبطه على 0، وتم تحديثه إلى 1.

server_param server_2 -facility cifs -تعديل acl.mappingErrorAction -القيمة 1

الآن ليس لدينا أية مشكلات في تعيين مجموعة الأمان المنشأة حديثًا في قوائم ACL للمجلد الموجود على مشاركة عبر الشبكة (بدون تأخير).

---

معلومات:acl.mappingErrorAction

يحدد قواعد التعيين غير المعروف بين معرفات الأمان والمستخدم والمجموعة (SID/UID/GID) في إعدادات ACL.

قد يحدث نوعان من الأخطاء:SID المعين في قائمة التحكم بالوصول (ACL) غير معروف لوحدات التحكم بالمجال المستخدمة.لم يتم تعيين اسم المستخدم بعد إلى UID/GID.

تتكون قائمة البت من أربع بتات ثنائية (البتات من 0 إلى 3، من اليمين إلى اليسار).كل بت هو 1 عند ضبطه؛وإلا 0.

Bit 0 (0001 or +1): Store unknown SID.
Bit 1 (0010 or +2): Store SID with no UNIX mapping.
Bit 2 (0100 or +4): Enable debug traces.
Bit 3 (1000 or +8): Do lookup only in cache (secmap or global SID cache or per connection SID cache).

قيم:0 - 15 الافتراضي:0

---

يبدو الأمر واضحًا بدرجة كافية الآن بعد أن فهمت المزيد حول إعدادات CIFS/ACL الأساسية على NAS مما كنت أرغب في معرفته.

ريس.

Answer 2

إذا كانت المشكلة هي مجرد التأخير في انتظار تحديث ذاكرة التخزين المؤقت وحظر الأعمال الأخرى التي يجب على البرنامج النصي القيام بها، فيمكنك إرسال ذلك إلى مهمة في الخلفية والسماح للبرنامج النصي الرئيسي بالانتقال إلى أشياء أخرى.