daabm

Spielt in dem Fall ausnahmsweise keine Rolle, weil Du nicht weiter "runter" kannst als das, was die AD-Cmdlets ohnehin einsammeln. Ansonsten ACK

Oh ja, NTLM-Blocking ist ein echtes Abenteuer. HyperV-Cluster nicht mehr verwaltbar, Authentifizierung an Services nicht mehr möglich, das Identity Management (das mit Service Account und Keytab arbeitet) geht auf die Bretter. Ein Heidenspaß... Unsere Kunden haben btw. nichts davon mitbekommen - die laufen alle noch mit NTLM-Fallback.

Problem: https://www.borncity.com/blog/2022/11/14/microsoft-besttigt-kerberos-authentifizierungsprobleme-nach-nov-2022-updates/ Schnelle kleine Lösung - nur für kleinere Umfelder geeignet, da wenig performant. Aber funktionsfähig $Results = [Collections.Arraylist]::new() $Filter = "(samaccountname=*)" $Results.AddRange( @( Get-ADComputer -LDAPFilter $Filter | Select-Object -Property * ) ) $Results.AddRange( @( Get-ADUser -LDAPFilter $Filter | Select-Object -Property * ) ) $Results.AddRange( @( Get-ADServiceAccount -LDAPFilter $Filter | Select-Object -Property * ) ) Foreach ( $Object in $Results ){ Set-ADObject $Object.DistinguishedName -Replace @{'msds-supportedencryptiontypes'=28} -Verbose } Wer sich über das Select-Object -Property * wundert - Stackoverflow mal durchsuchen, da gibt's ein Issue mit den AD-Cmdlets

Mahlzeit. Wen hat's da denn sonst noch so erwischt? Bei uns hat's unternehmensweit Kerberos zerlegt, bis wir die SupportedEncryptionTypes für alle Computer/User/Service-Accounts auf 28 gesetzt haben (RC4/AES128/AES256)... Und alle Dokus im Netz (dirteam.com und MS KB) passen nicht zu unserem Fehlerbild. Und wir üben grad, wie man das Attribut aktualisiert für etwa 4 Millionen Accounts... (In mehreren Domains, aber trotzdem - #grütze Microsoft).

Bin heute auch spät dran - schönen Feierabend, TGIF! 🍺

Bergfest war gut, jetzt bereiten wir uns aufs Wochenende vor. Feierabend, viel Spaß noch!

Um mal auf den realen Boden der Tatsachen zurückzukommen: Wenn ein User kompromittiert ist, gewinnt Ihr damit gar nichts. Der User braucht Zugriff auf "seine" Dateien, und damit können diese Dateien in seinem Kontext verschlüsselt werden. Wurde ja oben schon genannt: Ihr verliert Kerberos und habt zwangsweise NTLM-Fallback mit allen Nachteilen. Wenn ein Domain Admin (DA) kompromittiert ist, könnte man darauf kommen, das als valide Maßnahme anzusehen. Ist aber denkbar schlecht... Ein DA sollte auf einem Fileserver nichts zu tun haben, idealerweise kann er sich weder lokal anmelden noch remote zugreifen. Ein DA macht nichts anderes als die Domäne zu verwalten. Er verwaltet keine Fileserver und auch keine Shares oder ACLs auf Fileservern. Er kann sich nur auf DCs anmelden.

@testperson Das schaffen wir. Mal sehen, wie das Board reagiert Edit: Gibt es hier ein REST-API? 😂🤣

Was habt Ihr, ist doch ein valider Ansatz: Entziehe den Usern den Zugriff, dann kann in ihrem Kontext kein Trojaner mehr Schaden anrichten... SCNR

Netzwerktrace, da solltest Du recht schnell sehen, wo das Gerät hinwill und es nicht schafft.

/force ist flüssiger als Wasser... Es gibt CSEs, die nur bei der synchronen Vordergrundverarbeitung (aka "Systemstart" und "Anmeldung") ausgeführt werden können. FR gehört dazu. Umd mit /force erzwingst Du (unnötigerweise) die Verarbeitung der FR-Policies außerhalb dieser Vordergrundverarbeitung. Edit: Hättest Du Start-/Anmeldeskripts oder MSI-Installationen per GPO (igitt), würde für die die gleiche Meldung kommen.

Probieren wir hier eigentlich "so nebenher" die Limits der Forensoftware aus? Läuft der Page-Counter bei 2^16 über? Läuft der Post-Counter bei 2^31 über? Beides würde mich wenig überraschen

Notepad hat sich für so was noch nie interessiert - mehr Hintergrundinfos wären hilfreich. Und - Spoiler - die Antwort ist "ja".

Und wir haben nen geplanten Task, der vom Benutzer gestartet werden kann und den Teams-Cache löscht (nachdem er vorher alle Teams-Prozesse gekillt hat). Ist halt Software, die beim Kunden reift...

"Entpacken" wäre ne Idee... Mit ZIP kann Powershell nicht viel anfangen.

Also auf jeden Fall Gemauschel mit Servernamen...

Nein. Wenn die Vererbung deaktiviert ist, kommst Du "von oben" nicht mehr durch, Du mußt die "leafs" anfassen.

Zum Glück ist die Frühschicht wieder fleißig - gestern war hier Feiertag, daher "tote Hose". Jetzt Bergfest 🍺 Pils und Weizen steht schon lange kalt, bedient Euch.

Ich werf mal den AdminSDHolder in den Raum, hast Du das mal kontrolliert? Oder ist bei Deinen User-Objekte die Vererbung evtl. aus "anderen Gründen" deaktiviert?

Man "könnte" jetzt auf die Idee kommen, etc\hosts zu modifizieren Aber was spricht dagegen, daß die Kiste einfach weiter DC1 heißt? Alternativen stehen oben schon - CName, SPN, StrictNameChecking deaktivieren. Es spicht nichts dagegen, daß ein Filer unter mehreren Namen erreichbar ist. Unsere haben bis zu ca. 50 SPNs (aus "Gründen" ).

Also meine Version in Settings - Apps ist 2341. Vielleicht solltest Du Deine Informationen mal aktualisieren

Rückblickend sieht man meistens "die gute alte Zeit, in der alles einfacher war"

Ich hab auch keinen Account, aber in dem Fall würde ich auch sagen "erst mal nen Kaffee holen und dann noch mal nachschauen und -denken".

Nabend an Bord. So, auf geht's - TGIF-Bier steht bereit, Tisch ist gedeckt. Gläser muss sich jeder selber besorgen oder halt (ich bin ein Flaschenkind...) ohne auskommen Fürs Essen gibt es Spiegel oder Rühr, jeweils mit Ei. Heute 19-22°C, viel - sehr viel - zu warm für Ende Oktober. Die Frühschicht möchte ich nicht übernehmen, da bin ich noch zu dappig und nicht sozialtauglich 😂

Wäre mir neu, daß Trusts Schwierigkeiten mit unterschliedlichen DFL/FFL hätten Statt der Conditional Forwarder könntest Du auch Secondar DNS verwenden - aber das hängt vom Gesamtdesign ab (DHCP/DNS). Und wenn da "nur auf bestimmte Ressourcen" zugegriffen werden soll, dann sollte selektive Authentifizierung auf dem Trust aktiviert werden. Sonst sind alle überall "Authentifizierter Benutzer".