daabm

Ist für mich auch naheliegend. Der Verbindungsaufbau aktualisiert Clientname in VolatileEnvironment, und jeder neue Prozess darf den neuen Wert bekommen.

War da nicht was, daß Code von ChatGPT i.d.R. "halbfertig" ist?

...und nebenher das Kerberos-1x1 mit disjoint Namespaces, vielen DNS-Quirks und vielen Keytabs. Ich kann's inzwischen auswendig Vorgestern gelernt: Für Unix (Keytabs) gibt es nur Principal Names. Windows unterscheidet User und Service. Und wenn ein Keytab nur SPNs enthält, bekommt man damit bei einem Windows-KDC kein TGT. Ein Unix-KDC würde das machen, Principal ist Principal. Vor längerem schon gelernt: Nicht alle Anwendungen verwenden bei Kerberos den FQDN, den man konfiguriert. Manche machen "heimlich" DNS-Resolution und hangeln sich bis zum A-Record durch -> SPN muß registriert werden. (Und wir haben nicht nur CName-Records, sondern auch DName 🙈.) Und auch vor längerem schon gelernt: Nicht alle Anwendungen machen SSL-Handshake mit dem FQDN. Manche (wie ldp.exe) machen hier auch DNS-Resolution -> SAN im Cert erforderlich. Es hört nie auf 😂 Und ja, Du hättest Spaß. Aber ok, erst mal Wasser fließen lassen.

Das macht ne andere Truppe, das läuft aus Splunk raus weiter in Graylog/QRadar. Problem für uns ist grad der Eingangskanal Splunk mit Lizensierung auf Events pro Sekunde. Aber da arbeiten wir an einer Alternative.

Großes Wort, gelassen ausgesprochen. Wir haben eh schon Mühe mit den Sec-Eventlogs. Sind überall auf 4 GB konfiguriert, aber wir könnten genauso auch auf 100 MB setzen, hätte den gleichen Nutzen. Mit 100 MB würden sie 5 Minuten Rollover haben, mit den 4 GB sind es etwa 6 Stunden. Objekt-Auditing in AD scheidet völlig aus, das kostet zu viel (Splunk).

Weil das Framework (.NET) nicht weiß, was der Verzeichnisdienst dahinter (AD DS, AD LDS, irgendein LDAP) für Attributanforderungen hat. Du kannst die AD-Cmdlets ja genauso gegen einen AD LDS benutzen, und was dessen Schema so zu Attributen sagt, weiß vorher niemand

Ich hab keine Ahnung von dem BPA oder von HyperV in dem Zusammehang, aber vom Stacktrace her hat da "irgendwas" einen Namen, mit dem XML nicht glücklich ist. Und mit Glück liegt irgendwo jetzt dieses XML rum. Vom Stacktrace her könnte es eine der Properties hier sein: bei Microsoft.BestPractices.CoreInterface.EngineManager.TransformResults(FileInfo tempEngineDetailFile, String engineReport, String modelId, String subModelId, String computerName, String context, String& descriptionMessage)

Ja, der Sammelanschluß kostet etwa die Hälfte der Einzelverträge. Deshalb hat sich unsere Eigentümergemeinschaft auch entschlossen, den Sammelvertrag weiter beizubehalten und den Mietern einzeln anzubieten. Wir gehen davon aus, daß die meisten damit einverstanden sind.

Was soll da passieren, wenn kein Management drum rum auf den Namen angewiesen ist?

Norberts erstes Pixi? 😂

Ihr vergesst glaub alle grad die einfachste Form der MFA: Zweiter Admin, der die zweite Hälfte des Kennworts weiß... Klar ist das unkomfortabel, weil man diesen 2. Admin "zur Hand" haben muß, aber mehr als nix ist es auf jeden Fall.

Dann setz das doch per GPO, dann klappt es ohne manuelle Nacharbeiten... https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn789188(v=ws.11)#environment-extension Geht überhaupt nicht, das ist nur in der aktuellen PS-Session persistent.

Die haben ein 64-stelliges Zufallskennwort, auf jedem Member anders. Wozu sollte ich das wechseln?

Es reicht, den Pfad zu entfernen. Die Verbindung zum lokalen Profil funktioniert weiter über die User-SID in ProfileList.

Gern geschehen. Lösung des gMSA-Fehlers übrigens: Es gibt pro Benutzerdatenbank einen eigenen Account. Soll heißen: Alle DCs nutzen gemeinsam einen gMSA, und auf allen Membern ist es ein computerlokaler Account mit individuellem Zufallskennwort, das niemand kennt. Wird bei der Agent-Installation ausgewürfelt, auf dem Account gesetzt und in der Service-Konfig eingetragen, dann weggeworfen. (g)MSA pro Member wäre auch noch ok, ein gMSA für eine große Gruppe von Membern schon nicht mehr (lateral movement...).

Erinnert mich an das Steuergeräte-Problem, das Fahrer der ersten EFI-Fahrzeuge haben. Corvette-Besitzer von C3 ab BJ 81 und frühe C4 kennen das. Die Steuergeräte gibt es quasi nicht mehr (neu eh nicht, aber auch gebraucht nicht), und wer (wie die meisten) nicht ein frei programmierbares adaptieren kann, der kann dann entweder auf Vergaser umrüsten mit allen Konsequenzen bei der HU. Oder das Auto für 1,- bei ebay einstellen. Da kommt noch viel Elend mit "Mechanik top, Elektronik EOL" auf uns zu...

Es gibt nicht "den" häufigsten Fehler, aber ganz vorne dabei: Fehlerhafte ACLs auf höher berechtigten Konten (gMSA - das ist uns bspw passiert...), lateral Movement, vertical Movement. Und fehlende Koordination zwischen verschiedenen Teams und auch innerhalb eines Teams. Das mit dem gMSA war ein echter Anfängerfehler - Teammember, die überwiegend den operativen Teil abdecken, haben den gMSA etabliert für Splunk. Und dabei die Tier-Trennung übersehen - allowedToRetrievePassword: Domain Computers. b***d dabei nur: Der wurde auch für Domain Controller genutzt. Zack bist Du pwned. "Selber suchen" ist IMHO übrigens sinnlos - man ist da leider betriebsblind und hat weder einen strukturierten Angriffsplan noch ausreichend ungestörte Zeit.

Ignorier's einfach. Steht ja auch in der Meldung: "seit dem letzten Neustart nicht erfolgreich" - dann warten wir halt, bis es erfolgreich war

Hilft beides nix beim Ursprungsproblem - Prozesse erben ihre Umgebung, wenn sie erstellt werden. Danach ändert sich daran nichts mehr. Gibt nur einen "Frickel-Workaround": Variable nicht nur global setzen, sondern auch im aktuellen Prozess. Hilft aber allen anderen Prozessen natürlich nichts

Zwei Doofe, ein Gedanke

Hier...

Der Pfad der Gerechten ist zu beiden Seiten gesäumt mit Freveleien der Selbstsüchtigen und der Tyrannei böser Männer.

Ein Prozess bekommt seine Umgebung beim Start. Was auch immer Du jetzt in der (übergeordneten) Umgebung änderst, kommt im Prozess nicht an. War schon immer so, Du mußt auf andere Weise prüfen oder so wie @BOfH_666 vorschlägt.

Ich schütte den Kaffee mal weg, schmeckt nicht mehr und braucht auch niemand jetzt 🍺

Ja, ich konnte auch mal TCP-Header dekodieren. Das sind Grundlagen, von denen man Jahrzehnte leben kann. Nicht daß ich das heute noch auswendig könnte, aber ich weiß, daß es geht und ungefähr wie. Und damit finde ich dann den Rest der Infos, um es zu tun. "Handwerkszeug" hieß das mal.