daabm

Das weiß von uns niemand, da wir nicht wissen, wie Deine Domäne aussieht. Hier werden alle (!) lokalen Benutzerrechte (47 Stück, in der Tat) und Gruppenmitgliedschaften per GPO durchgesetzt, lokale Änderungen sind durch lokale Admins zwar möglich (geht auch nicht zu verhindern, Admin ist Admin), aber nicht persistent. Ob das bei Dir auch so ist? Warum sollte ein Domain Admin bei Dir in den lokalen Admins drin sein - oder warum sollte er das nicht? Ich kann es nicht sagen. Ja, Klassiker. Ameisenlöwe - Loch graben, reinlegen, auf Beute warten Sofortige Minimalprävention: Cached Credentials auf 1 runtersetzen. Aber halt nur minimal. Besser siehe oben, Deny logon locally.

Ja, steht ja schon oben: 1. "Deny logon locally" per GPO auf allen Clients für "Domain\Domain Admins" und "Domain\Administrators" 2. Neue AD-Gruppe "Client-Admins" 3. Group Policy Preferences - Local Users and Groups - Administrators: Neue Domänengruppe hinzufügen (mehr dazu: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html ) 4. Neue AD-Gruppe mit Accounts füllen PS: Punkt 1 als letztes umsetzen, wenn sicher ist, das 2-4 funktioniert

Nö, das verstehen wir schon

Ja, sag ich doch. "whoami" sagt Dir, in welchen Gruppen du EFFEKTIV Mitglied auf dem Client bist. Administratoren fehlt. Und die Domain Admins sind nicht in der "lokalen" Gruppe "Administratoren"; sondern in der "domänenlokalen" Gruppe "Administratoren". Kleiner, aber wesentlicher Unterschied.

Nein, nicht aktiviert. Kein Bedarf aktuell. SafeDLLSearchMode muß reichen

Ja, gerade geprüft. In deinem whomai-Output oben steht aber nichts von "Administratoren"... Und eine Konsole braucht man dafür auch nicht: "net localgroup administratoren" reicht meistens

Naja, da es eh schon wirr ist, hier noch ne ganz wirre Lösung: Scheduled Task, Account "SYSTEM", Trigger "Bei einem Ereignis" Event-ID raussuchen für interaktive Benutzeranmeldung, Delay 15 Sekunden. Action dann ein Skript, das den angemeldeten User findet, dessen Gruppenmitgliedschaften auswertet und ggf. installiert. Besser wird's dadurch aber auch nicht

@SaschaVolk Du bist schon zu sehr auf die von Dir ausgedachte Lösung fixiert. Besser wäre hier im Forum erst mal "klar die Anforderungen definieren" und die Anfrage dann von jeder dafür möglichen Lösung zu befreien. Das führt in der Diskussion erfahrungsgemäß zu den besten Lösungsvorschlägen.

Schlechte leider auch Könnte man jetzt per Reverse NAT lösen, ändert aber nichts daran, daß Du Recht hast und man in produktiven Business-Netzen einen großen Bogen um 192.168/16 machen sollte.

Fehlermeldungen im Wortlaut sind immer hilfreich. Ein "whoami /groups" auf der Commandline sagt Dir schon mal, wer Du eigentlich bist. Und dann sehen wir weiter PS: Warum meldet sich ein Dom-Admin auf einem Client an? Der hat da nichts verloren, dafür erstellt man sinnvollerweise eine AD-Gruppe "Client-Admins".

@tesso hat's schon zweimal erwähnt: Alles, was hinter Invoke-Command steht, findet REMOTE statt. Und dort (auf dem anderen Rechner) existiert diese Variable $UserSID nicht, weil Du sie nicht per -Argumentlist an Invoke-Command übergibts. Da gibt's glaub Millionen von Fragen dazu bei Superuser.com Variante 2 funktioniert, weil Du hier kein Remote-Command ausführst, sondern lokal einfach zu einer Remote Registry verbindest. Die Befehle laufen aber nach wie vor lokal, also da, wo $UserSID existiert. Alles nur eine Frage des Scope

Was genau bedeutet "Zugriff auf die Dateien"? Wenn Du sie lesen kannst, kannst Du sie auch woanders hin kopieren. Was genau geht schief? Falls Du Dateien auf den C$-Shares in andere Ordner auf den gleichen C$-Shares kopieren/verschieben willst, scheiterst Du an UAC. Suchbegriffe: EnableLinkedConnections und UnfilterAdministratorToken. Und natürlich auch prüfen, wie sich das gleiche nicht im Explorer verhält (der mit UAC überhaupt nicht zurechtkommt), sondern auch auf der Comamndline

Hier ist schon der erste Fehler. Den "Hinweg" bekommst Du so hin, den Rückweg aber nicht.... Rest vom Thread muß ich erst noch lesen Und nachdem ich jetzt durch bin: Wenn es nur darum geht, ein zweites Netz zu haben, in dem Geräte sind, die iwie ins Internet kommen - stell da einen eigenen DHCP rein, der passend verteilt. Wenn das aber im Konzern-Netz mitspielen soll, dann scheiterst Du am fehlenden Routing auf dem Rückweg, weil dein "privates" Netz im Konzern-Routing unbekannt ist.

Gerne. Gibt hier so ein lustiges Feature, mit dem man Posts als Antwort oder hilfreich oder so markieren kann

Da kommt IMHO üblicherweise vorher noch eine Abfrage nach der Auflösung. Wenn man die einfach mit Esc wegdrückt, landet man bei der "alten" direkten Verbindung ohne RDP.

Naja, der Eventlog-Name sollte schon korrekt angegeben werden. Tipp: "Applocker" ist falsch Den richtigen Namen findest Du in jedem Applocker-Event, das Dich interessiert. Vermutlich brauchst Du 2 oder 3 Logs (Exe/MSI/Script/AppX/xyz). Edit: Das Skript hängt vermutlich als geplanter Task an einem Event-Trigger. Mit ein wenig Forschung kann man sich das Event dann auch direkt holen, das landet soweit ich weiß in Aufrufparametern des Tasks (und ja, auch ich müßte da erst forschen - hab ich noch nie gemacht, aber wenn ich so was implementieren würde, wäre das auf jeden Fall so möglich). Edit 2: Falsches Forum - hier bist Du richtig https://www.mcseboard.de/forum/71-windows-forum-—-scripting/

Du bist nicht alleine - https://www.giga.de/downloads/windows-10/tipps/loesung-wsus-fehler-0x8024401c-windows-10-updates/ Mehrfach versuchen sollte das irgendwann lösen.

Wir sind zwar keiner Deiner Kunden, aber bei uns könntest das sehen Sieht lustig aus - bei "whoami /groups" bin ich zeitgleich in den Domain Admins von 3 Domänen

Ja, das Homelaufwerk heißt auf deutsch Basisordner. Wenn Du das aktivierst, hat das Auswirkungen auf ein paar Umgebungsvariablen und Standardverzeichnisse. Wenn Du es einfach wie ein gewöhnliches Laufwerk verbindest, nicht.

Die kann seit kurzem übrigens - auch wenn sie noch DHCP macht - nen alternativen DNS ausliefern...

Ideal wäre der Admin-Rechner. Einfacher ist ein Jumpserver, auf dem man sich NICHT mit dem Work-Account anmeldet, sondern mit dem Admin.

Geht nur per Skript. Und über den Sinn von OCX-Registrierungen auf UNC-Pfaden (selbst wenn Du die Berechtigungen noch korrekt hinbekommst) möchte ich nicht diskutieren...

Screenshot wäre hilfreich, und Ihr habt hoffentlich das GPO-Caching abgeschaltet? Edit: Vergiß das mit dem Caching, hab Win7 überlesen - sträflich eigentlich, aber da gab's das noch nicht.

Vergiß "Primäre Gruppe" gleich wieder - das ist eine Krücke aus W2K-Zeiten, als Gruppen noch Limits bei den Mitgliedern hatten... Also hat man ein extra Attribut eingeführt, um Domain Users gescheit nutzen zu können - das waren nämlich oft zu viele für "normale" Gruppen... Und wenn Du das Laufwerk nicht als "Homelaufwerk" im AD-Account eingetragen hast, ist es eh egal, wie Du das verbindest. Idealerweise nur ein Share, immer auf dem gleichen Buchstaben. Und darunter dann Benutzer- oder Gruppenverzeichnisse, die dank ABE nur bei passenden Berechtigungen sichtbar sind. Sich widersprechende Zuordnungen mußt Du _vorher_ organisatorisch lösen, erst dann kommt die technische Umsetzung. Und ansonsten geht's mir wie @MurdocX - zu viel Text, zu wenig "konkretes Doing".

Hm - auch wenn's nicht wirklich hilft: Wir nutzen LDAPS seit Jahren ohne Probleme. Und alle Connect-Fehler waren eigentlich immer Fehler in der Infrastruktur - bevorzugt Firewalls... Nur können wir das immer schlecht beweisen Ein Hinweis auf "Infrastruktur" wäre ein ganz schnell durchzuführender Test - wenn ich das richtig verstanden habe, kannst Du per RDP weiterarbeiten, wenn LDAPS nicht geht? Dann probier in dem Moment mal LDP lokal auf dem DC mit Bind auf sich selbst. Wenn das geht -> Netzwerk...