daabm

Warum sollte da jemand Schindluder treiben können? Wir haben ein Multimandaten-AD mit über 1000 Mandanten, die können da natürlich auch per dsa.msc/gpmc.msc zugreifen. Jeder sieht nur, was er sehen soll, und er kann nur ändern, was er ändern können soll. Wenn ein Nicht-Admin Schreibzugriff auf AD-Objekte hat, dann habt ihr ganz am Anfang schon was falsch gemacht

"Ich habe keine globalen User-GPOs" wäre hier - siehe Jan - eine Aussage, die ich erst mal überprüfen würde. rsop.msc würde ich allerdings nicht verwenden, das ist seit 16 Jahren "deprecated"

Ich kenne das Format Deines Inputs nicht - aber Export-Csv ist nur dann geeignet, wenn es Objekte erhält mit Properties, die "einfache" Inhalte haben. Einfach heißt "keine Arrays, keine embedded Objects" etc. Dazu solltest Du analysieren, was am Ende Deiner Pipe-Rutsche nach "Select-Object -ExpandProperty innerText" herauskommt. Das muß vermutlich erst mal etwas aufbereitet werden.

Wer auf Nummer Sicher gehen will, ändert den DefaultSD für groupPolicyContainer https://sdmsoftware.com/tips-tricks/modifying-default-gpo-permissions-creation-time/

Ich frage mich, ob "Unterordner von Projekt 1 lesen, aber das Projekt 1 selbst nicht" sinnvoll zu begründen ist. "Keep it simple" wäre meine Devise.

Da gibt es so lustige GPO-Einstellungen, die im Ergebnis dafür sorgen, daß das User-Profil immer nur ein Wegwerf-Profil ist und jedesmal neu erstellt wird. Da würde ich auch mal anfangen zu forschen.

Ich bin berühmt und gefürchtet für meine spontan-kurzen, aber meist treffsicheren Minimalhinweise

Ja wenn Du nur das im File haben willst, warum gibst Du dann nicht auch genau das in das File rein? Vergleiche mal Zeile 3 und Zeile 4/5 von deinem Sample Code - vielleicht fällt es Dir ja selber auf (Spoiler: Zeile 3 macht die Bildschirmausgabe)

Bei RDS-Hosts ist das seit Jahrzehnten das selbe. Falsche lokale Security und der Host ist owned. Das gilt grundsätzlich identisch für Clients. Und zwar mit oder ohne Fast User Switching. Security by obscurity ist halt oldschool, Security by design wäre aktuell

Dann finde raus, welches Anmeldeskript da hängen bleibt.

PCs in Gruppen schieben reicht nicht. Die PCs müssen in einem SOM liegen, der von der GPO abgedeckt wird. SOM? Scope of Management - Domäne, Site oder OU. Irgendwo im OU-Pfad nach oben vom PC aus (nicht von der Gruppe aus) muß die GPO verlinkt sein. Und zu "verschiedenste Regularien - nichts weltbewegendes" hab ich eine völlig andere Meinung. Nichts ist schwieriger, als "verschiedenste Regularien" zu erfüllen. Kein Werkzeug ist dafür geeigneter als GPOs - aber "nichts weltbewegendes" ist das auf keinen Fall. Nicht mal für mich.

Made my day

Ich hab mich beim Lesen direkt gefragt, was ein "GPO-Projekt" sein könnte - kannst Du das kurz erklären? In einer OU kann man keine Computer "eintragen", die muß man da reinschieben. Und gpresult hilft immer.

Mir fehlt die konkrete Frage...

Ich hab's jetzt nur mal grob überflogen - und ich bin nicht wirklich zuversichtlich... Da fehlen zu viele Grundlagen nicht nur in Powershell, sondern vor allem in Active Directory. Multi Domain Forest? Kein Problem - kann man sich mit Get-ADForest und Get-ADDomain wunderbar durchhangeln. Beliebig große Umgebung mit Trusts? Auch kein Problem - kann man sich mit Get-ADTrust (oder schneller per LDAP mit Filter auf Trust Objects) durchhangeln. Bei Gruppen und Usern gerne mit -PassThrough arbeiten, damit man mit dem Ergebnis weiterarbeiten kann. Und natürlich immer gegen den PDC der Zieldomäne ( Get-ADDomain -Identity xyz ).PDCEmulator - die meisten Cmdlets nehmen das per -Server als Parameter. Manche wollen (wie z.B. GroupPolicy) auch noch -Domain wissen. Alles kein Hexenwerk, aber dazu braucht's ein Grundverständnis für die Zusammenhänge. Die Cmdlets liefert dann get-command -module activedirctory - oder eine schnelle lmgtfy-Abfrage. Und ohne Testumgebung - das muß ich aufgrund der oben teilweise vorhandenen Hinweise noch mal ausdrücklich betonen - GEHT GAR NICHTS! Nichts löst eine Domäne schneller in Luft auf als ein Skript... Außer einem Abrissbagger, der auf den einzigen DC drischt. Das war das Ergebnis einer Google-Suche, oder? Normalerweise sieht das nämlich so aus: $domain = Get-ADDomain -Current LocalComputer # alternativ -Current LoggedOnUser $domainDN = $Domain.DistinguishedName Da braucht's weder DotNet-Klassen noch Get-ADDomainController (die bei Get-ADDomain ohnehin schon in ReplicadirectoryServers stehen). Das meinte ich mit Grundlagen zum Thema AD - welche Eigenschaften bedeuten was, und in welchen Objekten sind sie zu finden.

Ich könnte jetzt noch einwerfen, daß alle Host-Bits = 0 -> Netzadresse und alle Host-Bits = 1 -> Broadcast, aber das führt glaub zu weit Und dann könnte man noch auf die abstruse (und auch nicht vorgesehene) Idee kommen, daß eine Netmask ja - rein technisch - nicht mal zwingend links beginnen und fortlaufend sein muß. Da kommen dann Konstrukte raus, die für Computer total einfach, für Menschen aber absolut nicht nachvollziehbar sind

Aus meiner Sicht spricht wenig dagegen... Der DNS wäre einfach ein Secondary, und Timeserver ist völlig unkritisch, solange der Uplink zum Domain Controller funktioniert. Auch gegen DHCP spricht nix, wenn sauber konfiguriert. Kannst ja (schmutzig, schmutzig) noch mit FW-Regeln dafür sorgen, daß da nix schiefgeht Der nächste Thread kommt, wenn der DHCP aus Versehen mal auf die andere NIC rutscht und der Server beide NICs im DNS registriert. Die Probleme sind absehbar

Grad mal kurz etwas geforscht - https://docs.microsoft.com/de-de/dotnet/api/system.security.accesscontrol.filesystemaccessrule.-ctor?view=dotnet-plat-ext-3.1#System_Security_AccessControl_FileSystemAccessRule__ctor_System_String_System_Security_AccessControl_FileSystemRights_System_Security_AccessControl_InheritanceFlags_System_Security_AccessControl_PropagationFlags_System_Security_AccessControl_AccessControlType_ Zitat: "Mit dem identity-Parameter muss ein gültiges Konto auf dem aktuellen Computer oder der aktuellen Domäne identifiziert werden." Dann dürfte es mit einem User statt einer Gruppe aber auch nicht gehen...

Mehr braucht's eigentlich nicht - wendet der RDS die GPO auch an? Und wegen DFS: Gehst Du auf den FQDN oder nur Netbios als "Server"-Name?

Die Meldung ist doch eindeutig - im Ausführungskontext des Skripts (Computer/User) kann DomB.local\ACC_TNG_Nummer_DL nicht in eine SID aufgelöst werden... warum kann jetzt nur der TO herausfinden. psgetsid wäre ein Ansatz, dsquery ginge auch. Oder get-adgroup oder sonstwas, was sich AD-Objekte holt.

Das ist kein Microsoft-VPN, oder? Da geht das problemlos... Bei Anyconnect kann man es IMHO irgendwie einstellen, daß lokale Verbindungen weiter funktionieren, da bin ich im Detail aber überfragt. Hab nur vor kurzem zufällig nen Screenshot gesehen (nur gesehen, deshalb kann ich's hier nicht zeigen), aus dem das ersichtlich war. Anyconnect kann bei bestehender VPN-Verbindung lokale IP-Netze entweder weiterhin zulassen oder alles in den Tunnel zwingen.

Da wurde schon wieder alles gesagt - und um während des Migrationszeitraums GANZ sicher zu gehen, deaktiviere VORHER die Änderung von Computerkennwörtern in der Domäne - nur so kannst Du halbwegs sicher die alten W7-Images wieder in Betrieb nehmen. Da sind wir aber an der Grenze zu paranoid

Ok, das stimmt. Aber dann wäre jemand mit ordentlich Wissen und ebenso ordentlich fehlender Voraussicht am Werk gewesen - das bezweifle ich hier mal. Und wenn es beide Einträge nicht gibt - was ist dann mit den restlichen Bestandteilen des Filters? Und IMHO müßte das dann sowieso angewendet werden - aber ohne das reale XML zu sehen, sag ich jetzt besser nichts mehr

Doch, die gibt es. Wenn nicht, schaust Du nicht in das, was wir erwarten würden

https://gpsearch.azurewebsites.net/#2812 Geht so schon seit laaanger Zeit