Probleme mit New-Adgroup, Set-ACL- und Netzwerkordnern

Question

Ich spiele mit einem PowerShell-Code, um Ad-Security-Gruppen dynamisch zu generieren, und wenden Sie sie dann auf Ordner in einem Netzwerkanteil an, aber Probleme mit der Lösung der neu erstellten Gruppe.

Betrachten Sie dies:

generasacodicetagpre.

das funktioniert gut.

Wenn ich jedoch den Ordner in einen Netzwerkordner ändere, z. B. g: \ temp, oder \\ domain.network \ dfs \ groupshare \ temp, bekomme ich eine "Methode mit einem unerwarteten Fehlercode 1337".

i müde mit setacl.exe und erhielt einen ähnlichen Fehler:

generasacodicetagpre.

Wenn ich warte, sagen Sie 10 bis 20 Sekunden, und führen Sie den Abschnitt SET-ACL (oder Setacl.exe) erneut den Code aus, er ist erfolgreich abgeschlossen.

Zunächst dachte ich, dass dies direkt mit den Domänencontrollern verbunden war (4 von ihnen, die eine Mischung aus 2003 und 2008 R2 sind), aber die Tatsache, dass es in lokalen Ordnern gut funktionierte, war faszinierend (und nervig).

Ich habe während der Ausführung des Codes in einem lokalen Ordner und anschließend einen Netzwerkordner ein WireShark-Trace durchgeführt. Der Hauptunterschied ist, wenn Sie versuchen, die ACLs in den Netzwerkordner anzuwenden, den ich LDAP-Lookups und (unter anderem) die folgende SMB-Antwort sehe:

generasacodicetagpre.

was ich davon ausgreift, ist, was dazu führt, dass mein Set-ACL-Befehl fehlschlägt.

Das zugrunde liegende Netzwerkdateisystem ist EMC Celerra 6.0.xx. Ich bin sehr unbekannt mit dieser Technologie, jedoch von dem, was ich verstehe, dass es eine Art Sid-Cache enthält, die den oben genannten Fehler erklären würde (es kennt die neue Gruppe noch nicht, obwohl AD tut).

Ich denke, es gibt zwei Fragen:

.
1. Gibt es irgendwo um diesen (Powershell / c # ect), das nicht schlafen / warten? Dh die ACL einstellen, obwohl die SID ist ungültig?
2. Wenn EMC Celerra das Problem ist (ich gehe davon aus, dass es ist), gibt es irgendwelche So kann ich es zwingen, seinen "Sid-Cache" oder was auch immer es sein mag?

Ich habe lesen verschiedene Artikel über dieses Problem , aber keiner scheint eine effektive Auflösung zu haben (oder arbeite für mich).

Danke für Ihre Hilfe.

rhys.

Answer 1

hat es herausgefunden!

modifiziert die acl.mappingEroraction auf unserer EMC Celerra NAS.

wurde auf 0 gesetzt, es auf 1 aktualisiert.

server_param server_2 -Facility CIFS -Modify ACL.MappingEroraction -Value 1

Jetzt haben wir keine Probleme beim Einstellen der neu erstellten Sicherheitsgruppe in die ACLs für den Ordner in einem Netzwerkanteil (keine Verzögerungen).

---

info: acl.motingEroraction

Definiert die Regeln für unbekannte Mapping zwischen Sicherheit, Benutzer und Gruppenkennungen (SID / UID / GID) auf ACL-Einstellungen.

Zwei Arten von Fehlern können auftreten: Das in der ACL eingestellte SID ist den verwendeten Domänencontrollern nicht bekannt. Der Benutzername ist noch nicht auf eine UID / GID zugeordnet.

Die Bitliste besteht aus vier binären Bits (Bits 0 bis 3 rechts nach links). Jedes Bit ist 1 beim Set; Ansonsten 0.

generasacodicetagpre.

Werte: 0 - 15 Standardeinstellung: 0

---

scheint jetzt offensichtlich zu sein, da ich mehr über die zugrunde liegenden CIFs / ACL-Einstellungen auf dem NAS verstehe, dann wollte ich jemals wissen.

rhys.

Answer 2

Wenn das Problem nur die Verzögerung ist, die daran beteiligt ist, auf den Cache auf den Cache zu warten, um die Blockierung anderer Arbeiten zu aktualisieren, muss das Skript tun, um das zu tun, dass Sie das an einem Hintergrundjob versenden und Ihr Hauptscript zu anderen Dingen eingehen lässt.

.