daabm

Nachdem Ihr jetzt schon viel diskutiert habt, werfe ich noch "scope" in den Raum und [ref]. Ich glaube, jede Suchmaschine liefert passende vertiefende Hinweise @testperson Mein Monk achtet peinlichst darauf, die Pipeline sauber zu halte vor unbeabsichtigtem Inhalt, macht es wie @cj_berlin und gibt einfach das Ergebnis "aus", womit es in ebenjener Pipeline und damit im Return des aufrufenden Scope landet. "Return" hilft da nicht - alles was unbeabsichtigt in der Pipeline gelandet ist, wird ebenso zurückgegeben. @Dukel Das mit dem Scope gilt auch für Funktionen - jede "Hauptfunktion" kann ihre eigene Childversion von "Kind{}" haben. Macht es im Zweifel nicht einfacher, ist aber manchmal durchaus hilfreich, weil importierte Funktionen nicht die eigenen stören können.

seServiceLogonRight, seDenyInteractiveLogonRight und seDenyRemoteInteractiveLogonRight sind die Rechte, auf die es hier ankommt Mit den Accounteinstellungen sollte man da gar nicht erst anfangen. Zum Einlesen: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html Und nein, so eine "Checkbox" gab es nie.

Schön ist relativ Nachdem die Bremsen gepflegt wurden, brauch ich ne neue Frontschürze (selbst verschuldet ein Stück abgerissen). Die spinnen, die Autohersteller...

Zum einen installieren wir alle unsere Server schon seit über 10 Jahren als rein englische Basisinstallation - für Kundensysteme kommt das deutsche LP noch drauf. Zum anderen bin ich in solchen Momenten echt froh, daß wir ein Konzern sind und ich mich auf meine AD-Insel zurückziehen kann. Mit OS-Patches habe ich nichts zu tun (außer privat natürlich... "IT-Admin der Ehefrau" ) @NorbertFe 100% sind doch gut - dachte ich bisher immer 😂

Ich würde es andersherum machen - GPO auf eine Gruppe von Testclients einschränken und SMB dort dann erzwingen. Auf den DCs kann man da nix selektiv machen, entweder man erzwingt es oder halt nicht. SMB Signing hat "eigentlich" nichts mit Account-Sperrungen zu tun. Vielleicht hast Du mehr als nur eine Herausforderung...

Problematisch finde ich das hier: Das bleibt mit "Vorhanden, überschreiben? (j/n)" stehen, wenn man's interaktiv ausführt. Was schreiben denn die ganzen Write-Verbose so in die Konsole? Ich habe mir auch erlaubt, den Code etwas lesbarer zu machen $ProfileName = "VPNNAME" # Validate VPN profile Write-Verbose "Searching VPN profiles for `"$ProfileName`"." If ( $AllUserConnection ) { # Get VPN profile running in the user's context $Vpn = Get-VpnConnection -Name $ProfileName -AllUserConnection -ErrorAction SilentlyContinue } Else { # Get VPN profile running in the 'all users' context $Vpn = Get-VpnConnection -Name $ProfileName -ErrorAction SilentlyContinue } If ( $Null -eq $Vpn ) { # Exit if VPN profile does not exist Write-Warning "VPN connection `"$ProfileName`" not found." Return } Else { Write-Verbose "VPN connection `"$ProfileName`" found." } # Use transaction for registry updates Start-Transaction #Create registry REG add "HKLM\System\CurrentControlSet\Services\RasMan\Config\" # Search AutoTriggerDisabledProfilesList for VPN profile $Path = 'HKLM:\System\CurrentControlSet\Services\RasMan\Config\' $Name = 'AutoTriggerDisabledProfilesList' Write-Verbose "Searching $Name in $Path for VPN profile `"$ProfileName`"..." Try { # Get the current registry values as an array of strings [string[]]$DisabledProfiles = Get-ItemPropertyValue -Path $Path -Name $Name -ErrorAction Stop } Catch { Write-Verbose "$Name does not exist in $Path. No action required." Return } If ( $DisabledProfiles ) { # Create ordered hashtable $List = [Ordered]@{} $DisabledProfiles | ForEach-Object { $List.Add("$($_.ToLower())", $_) } # Search hashtable for matching VPN profile and remove if present If ( $List.Contains( $ProfileName )) { Write-Verbose 'Profile found. Removing entry...' $List.Remove( $ProfileName ) Write-Verbose 'Updating the registry...' Set-ItemProperty -Path $Path -Name $Name -Value $List.Values -UseTransaction } } Else { Write-Verbose "No profiles found matching `"$ProfileName`"." Return } # Add user SID to registry If ( $AllUserConnection ) { $SID = 'S-1-1-0' Write-Verbose "Adding SYSTEM SID $SID to registry..." } Else { Try { $SID = [System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value Write-Verbose "Adding user SID $SID to registry..." } Catch { Write-Warning $_.Exception.Message Return } } $Parameters = @{ Path = 'HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\Config\' Name = 'UserSID' PropertyType = 'String' Value = $SID UseTransaction = $True } New-ItemProperty @Parameters -Force | Out-Null # Add VPN profile name to registry $Parameters = @{ Path = 'HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\Config\' Name = 'AutoTriggerProfileEntryName' PropertyType = 'String' Value = $ProfileName UseTransaction = $True } New-ItemProperty @Parameters | Out-Null # Add VPN profile GUID to registry Write-Verbose "Adding VPN GUID $GUID to registry..." [guid]$GUID = $Vpn | Select-Object -ExpandProperty Guid $Binary = $Guid.ToByteArray() $Parameters = @{ Path = 'HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\Config\' Name = 'AutoTriggerProfileGUID' PropertyType = 'Binary' Value = $Binary UseTransaction = $True } New-ItemProperty @Parameters | Out-Null # Add phonebook path to registry If ( $AllUserConnection ) { $Path = Join-Path -Path $env:programdata -ChildPath Microsoft\Network\Connections\Pbk\rasphone.pbk Write-Verbose "RAS phonebook path is $Path." } Else { $Path = Join-Path -Path $env:userprofile -ChildPath AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk Write-Verbose "RAS phonebook path is $Path." } $Parameters = @{ Path = 'HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\Config\' Name = 'AutoTriggerProfilePhonebookPath' PropertyType = 'String' Value = $Path UseTransaction = $True } New-ItemProperty @Parameters | Out-Null # Commit registry changes Complete-Transaction # Disable the "Disconnect" button in VAN UI/Settings > ensuring that "Connect Automatically" cannot be unchecked ( get-content -Path "$env:appdata\Microsoft\Network\Connections\Pbk\rasphone.pbk") | ForEach-Object {$_ -Replace "Options=0", "Options=18"} | Set-Content -Path "$env:appdata\Microsoft\Network\Connections\Pbk\rasphone.pbk"

https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html (Muß echt mal ne aktuelle Version davon schreiben...)

Komplexität halte ich für sinnfrei, lieber länger. Und bei 365 Tagen Gültigkeit kann man auch gleich "nicht ablaufend" verwenden - die Historie ist bei nem Änderungsintervall von nem Jahr auch eher uninteressant. Aber jm2c Ich bin ein erklärter Gegner von erzwungenen Kennwortänderungen. Wie das BSI 😂

Ehm - warum hängt Ihr Euch grad immer am "Befüllen" des Attributs auf? Es geht um das "Auslesen"...

Group Policy Preferences "Umgebungsvariable" mit Zielgruppenadressierung "LDAP-Abfrage".

Nabend wieder an Land Auto war heute mal wieder in der Werkstatt, Bremsenwartung. Das Zeug benutzt man ja quasi nie, das gammelt sonst einfach weg... 🙈

Hier - bis auf die von Microsoft erzwungenen Ausnahmen für SQL- und HyperV-Cluster, die noch nicht ohne können. Frei nach einer meiner bevorzugten Bands: "It's a long way to the top"... Ich weiß inzwischen Dinge über Kerberos in Windows und in krb5.conf, die ich eigentlich nie wissen wollte 😂

Den richtigen DC finden sie ja schon. Kannst sogar einen "preferred" einstellen, falls der PDC hinter einem WAN-Link hängen sollte. Das Problem steckt in GPMC/DFSR. Und um das zu lösen, müssten sie das Anlegen und Importieren komplett nachbauen. Ich kann schon verstehen, daß man das nicht unbedingt will, wenn es doch "offizielle" APIs gibt. "Timing verändern" ist so ein zweischneidiges Schwert - wie lange willst denn warten, bis DFSR auf dem von Dir grad genutzten Referral das Verzeichnis erstellt hat?

Quest behandelt das nicht selbst, warum auch - sie nutzen das GPMC-API, das für das Anlegen von GPH und GPT verantwortlich ist. Da müßte das gefixt werden...

Ok Wir haben ein Drittprodukt (Quest GPOAdmin), das GPOs über Domänengrenzen synchronisieren kann. Ein in der Quelldomäne per GPMC-API erstelltes GPO-Backup im ZIP-Format wird dabei zum Zielserver übertragen. Dort wird von der Ziel-GPO eine tempoärer Kopie erzeugt und dann das entpackte Zip (wieder per GPMC-API) in diese Kopie importiert. Danach wird (wieder GPMC-API) davon ein Backup estellt, die temporäre Kopie gelöscht und das aktuelle Backup in die ursprüngliche "produktive" GPO importiert (noch mal GPMC-API). (Klingt aufwändig mit der temporären Kopie und dem vielen Import/Export, das hängt mit den verfügbaren Workflows zusammen - man kann nicht nur "immediate deployment" machen, sondern auch erst mal "stagen"- das sprengt den Rahmen hier aber.) Das arbeitet also mit ein wenig Zip/Copy, der Rest ist GPMC-API nativ. Dabei fällt der Import in die temporäre Kopie regelmäßig auf die Nase, wenn der jeweilige Server mehr als einen DC sieht. In AD wird das GPC-Objekt immer auf dem PDC angelegt (das kriegt das GPMC-API noch hin). Der GPT-Sysvol-Ordner entsteht dabei ebenfalls "initial" - aber nicht auf dem PDC, sondern "irgendwo". Der folgende Import per GPMC-API greift AD-seitig auch nur auf den PDC zu und findet den GPC-Container. Der Dateiimport in den GPT-Sysvol-Ordner läuft über DFSR aber wieder gegen "irgendeinen" DC. Und DFSR hat auch innerhalb einer Site Latenzen -> Sysvol-Ordner nicht vorhanden -> "Path not found". Macht man das von Hand, ist es i.d.R. kein Problem, weil man von Hand nicht so schnell klicken kann (DFSR-Latenzen intra-site sind im Sekundenbereich). Das ganze läuft hier aber programmatisch: Neue temporäre Kopie erstellen und "sofort" importieren. Ich hoffe, das ist soweit verständlich ausgedrückt Workasround: In jeder Domäne eine Site, in der nur der PDC und der jeweilge Server stehen. Dann ist nicht nur AD zufrieden, sondern auch DFSR - das findet dann auch nur noch "the one" Das WLAN-Snapin war diesbezüglich auch speziell. Das hatte den Bug, daß es die DC-Auswahl in GPMC, die von GPMC an GPEdit (korrekt eigentlich: GPME.MSC) beim Aufruf weitergegeben wird, ignoriert hat und auch "irgendeinen" DC auswählte. Ergebnis: Klickte man in GPEdit auf "neue WLAN-Policy", wurde von GPEdit auf dem PDC im GPO-Container ein "Machine"-Container erstellt. Das Snapin selbst erstellt darin dann ein WLAN-Objekt, bei Bedarf aber auch den zugehörigen Container. Ging das nicht gegen den PDC -> Replikationskonflikt (CNF:) für den "Machine"-Container, wenn es den nicht vorher "aus Gründen" schon gab -> GPO kaputt.

Eventlogs kennst Du und hast Du geprüft auf Client und Druckserver?

..das ist nur die AD-Verbindung von GPMC selbst und - in der Theorie - GPEdit. Sysvol geht über DFSR und hat leider andere Mechanismen. Wenn in der aktuellen Site mehr als ein DC steht, ist der Sysvol-Zugriff undefiniert. Frag mich per PN, woher ich das weiß Oder wenn allgemein von Interesse, dann auch hier. Und auch bei der AD-Verbindung haben manche Snapins immer wieder Probleme - WLAN war eines davon, das hat den DC aus GPMC/GPEdit schlicht ignoriert, Folge Replikationskonflikte in AD. (WLAN speichert seine Settings nicht in Sysvol, sondern in AD.)

Womit Du natürlich Recht hast Warten wir mal entspannt auf den TO...

Kennt die Windows-FW eine "Reihenfolge"? Wenn ich das richtig verstehe, ist die Regel-Rangfolge nicht ganz so einfach: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules (die Formulierung "more specific rules take precedence" finde ich herzerfrischend. Wie ist das, wenn bei einer ein Set von IP-Ranges steht und bei der anderen ein Set von Ports?) Eine explizite Block-Regel gewinnt wohl immer, daher müsste man grundsätzlich für Inbound _und_ Outbound "Block" als Standard einstellen und dann per Allow gezielt wieder öffnen.

Stimmt alles. Was aber auch stimmt: Wir tendieren dazu, die "Last" und damit das Sizing eines DC an der Größe der Physik festzumachen. Das ist aber nur die halbe Wahrheit. Die Menge an Objekten in AD hat mit der Physik zwar "regelmäßig" direkt zu tun, aber nicht zwingend. Beispiel? Gerne Ich hab irgendwann spaßeshalber in einer Umgebung mit 2 DCs, 2 Membern und 5 Usern 15.000 Sites und 50.000 Subnetze angelegt. Ergebnis: Domäne nahezu unbedienbar. Die reale Umgebung hat sich dabei nicht verändert, nur der Inhalt von AD. Netlogon/LSASS 100% CPU, KCC/ISTG werden nicht mehr fertig. Wenn ich damit in ein Forum gehe, weil meine dsa.msc fast unbedienbar ist: "Die Umgebung ist klein, nur 2 DCs und ne Handvoll Computer und User". Vielleicht lief mal ein Skript Amok und hat 2 Mio. User angelegt? Vielleicht gibt es endlose Gruppenverschachtelungen? "Etwas aus dem Lot" @NilsK ist da die zutreffende Formulierung, aber bisher kam vom TO nichts dazu. Und damit verweise ich wieder auf meinen Post oben: GPMC Debug Logging könnte helfen. Korrekte AV-Exceptions könnten helfen. Prüfen der DFS-Replikation (nicht dcdiag/repadmin!) könnte helfen. Und wenn man wüßte, welche Prozesse die 30% CPU verursachen, könnte das auch helfen. "Virenschutz" ist mir da zu pauschal - ist es ein bestimmtes Modul?

Ehm... https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services Unsere größte Domäne hat knapp 200.000 User -> direkt mal 16 GB RAM als unteres Limit.

GPOs sind zweiköpfige Monster. Der eine Kopf steckt in Active Directory, der andere in Sysvol. Und die zwei haben unterschiedliche Replikationsmechanismen... AD-Replikation vs. DFSR. "Replikation anschubsen" ist fast immer nur AD und nicht DFSR - und beim Bearbeiten der Inhalte ist immer DFSR relevant, fast nie AD. repadmin kannst Du Dir in dem Fall also sparen, der ist flüssiger als Wasser BTW: In GPMC kann man ein Debug Log aktivieren, das bei so was erstaunlich hilfreich ist - https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc737379(v=ws.10)?redirectedfrom=MSDN (gilt immer noch, auch wenn da 2003 im Link steht ) PS: Für AV-Exceptions auf DCs gibt es fertige Listen bei Microsoft - https://support.microsoft.com/en-au/topic/virus-scanning-recommendations-for-enterprise-computers-that-are-running-windows-or-windows-server-kb822158-c067a732-f24a-9079-d240-3733e39b40bc - die würde ich dringend empfehlen umzusetzen. PPS: Die SIDs S-1-5-80-... sind Service-SIDs. Die werden nicht aufgelöst, weil es den entsprechend benamsten Service auf dem jeweiligen Computer nicht gibt. Ich würde empfehlen, die drin zu lassen, wenn es keine untergeordneten GPOs gibt, die das "offiziell" setzen. Und S-1-5-32-549 sind die Server-Operatoren, die es nur auf Servern gibt, nicht auf Clients.

Zeit vergeht linear - das Erleben ist exponentiell in beide Richtungen

Ein Account für CyberArk und individuelle Tresore mit den Zielaccounts.

Kennt IEM schon TLS1.2? "gpresult durchsucht" - welche Art von Report und wie durchsucht? Und was passiert, wenn man das manuell ändert und gpupdate aufruft - dann auch wieder falsch?