Jump to content

daabm

Expert Member
  • Posts

    5,249
  • Joined

  • Last visited

7 Followers

About daabm

  • Birthday 01/16/1967

Profile Fields

  • Member Title
    Expert Member

Webseite

Recent Profile Visitors

9,115 profile views

daabm's Achievements

Grand Master

Grand Master (14/14)

  • Ten Years In
  • Dedicated Rare
  • Posting Machine Rare
  • Collaborator
  • First Post

Recent Badges

1.2k

Reputation

78

Community Answers

  1. Was soll da passieren, wenn kein Management drum rum auf den Namen angewiesen ist?
  2. 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.
  3. 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.
  4. Die haben ein 64-stelliges Zufallskennwort, auf jedem Member anders. Wozu sollte ich das wechseln?
  5. Es reicht, den Pfad zu entfernen. Die Verbindung zum lokalen Profil funktioniert weiter über die User-SID in ProfileList.
  6. 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...).
  7. 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...
  8. 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.
  9. Ignorier's einfach. Steht ja auch in der Meldung: "seit dem letzten Neustart nicht erfolgreich" - dann warten wir halt, bis es erfolgreich war
  10. 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
  11. Der Pfad der Gerechten ist zu beiden Seiten gesäumt mit Freveleien der Selbstsüchtigen und der Tyrannei böser Männer.
  12. 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.
×
×
  • Create New...