daabm

Wir zünden eine Kerze an. EINE!

TGIF! Ich hab den Kaffee entsorgt und das Bier kaltgestellt

Ich auch. Wegen 10 Clients benenne ich keine Domäne um...

Brrr - igitt... Und dann womöglich noch feucht

Nimm Dich mal nen Glühwein, der Winter kommt Ich bleib noch beim Bier, hier hats grad kuschelige 5 Grad bei Nieselregen 🍻

Ja, Kaffee holen reicht nicht, Du mußt ihn schon auch benutzen

Robocopy hat für solche Fälle den Schalter /b

Bin jeden Abend hier, aber wenns nix zu sagen gibt, halte ich gern mal die Tastatur still

Wir haben ne Domain Policy mit Kerberos ETypes (AES only). Das Problem ist nur, daß der Client wohl RC4 mitschicken muß, damit der Server das im richtigen Codezweig verarbeitet - oder irgendwas in die Richtung. Das INet ist diesbezüglich noch ziemlich wirr... @cj_berlin hat natürlich Recht - wenn bei uns jetzt plötzlich RC4-Tickets ausgestellt würden, hätte sich unser SOC schon längst gemeldet Und mit System.DirectoryServices werden wir das auch in unserer Produktion machen. Aber nicht mit dem DirectorySearcher, sondern mit Protocols.SearchRequest. Hat den Vorteil, daß wir in den paged Searches über jeweils 1000 Ergebnisse iterieren können und nicht alle Objekte auf einmal in einer Schleife landen. Hab mein Sample von oben mal in einer Testumgebung mit 300k Objekten laufen lassen -> 3 GB RAM. Prod hat bei uns "etwas" mehr Objekte JETZT hab sogar ich es kapiert. Ich war bei "Get-ADUser -Properties DistinguishedName", aber Du meintest beim Select ACK!

Drei Kreuze, wenn morgen vorbei ist... Scheiß Patchday mal wieder 😫 Da hilft nur 🍺🍺🍺 - macht's zwar nicht besser, aber dann ist es einem egal 😂

Wenn Du ganz viel lesen willst: https://www.google.com/search?client=firefox-b-d&q=evilgpo.blogspot.com+loopback Die ganz harte Tour: https://evilgpo.blogspot.com/2014/10/implementieren-von-ordner-nur-auf.html Der zweite Link hat ne Lösung dafür, die komplett universell und variabel ist. Der Anfangsaufwand ist allerdings nicht zu unterschätzen, wenn man damit noch nicht viel gemacht hat

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...