cj_berlin

Update (weil die ganze Welt ja drauf wartet): Nach diversen eigenen Tests und einer abendlichen gemeinsamen Session mit @MurdocX kristallisiert sich das folgende Bild heraus: es funktioniert (und ja, ich weiß, das wurde von @mzahneissen anders gemeldet) mit Server 2019 und 2022 bei SMB-Zugriff von Member zu Member und Cross-Forest-Anmeldung auf einem Member (alles Server) es funktioniert NICHT (genau wie von @mzahneissen und @MurdocX beschrieben) in einem Lab, das komplett aus Server 2025-Maschinen besteht (DCs und Member). es funktioniert auch der Zugriff von einem Server 2025 oder Windows 11 Member auf einen Server 2022 Member in einem Lab, das 2022er DCs hat das Problem hat augenscheinlich NICHT mit der Site-Bestimmung und DCLocator zu tun (war kurz mal eine Idee) das Problem hat augenscheinlich auch NICHT mit dem November-Patchday zu tun. Soweit es also Dinge betrifft, die ich mit eigenen Augen gesehen habe, ist es mal wieder ein "Server 2025 als DC"-Problem. Bleiben also Meldungen in diesem Thread, die darauf hinweisen, dass das Phänomen ggfls. auch mit 2019 oder 2022 besteht, aber das kann ich beim besten Willen nicht nachstellen. Ich habe das an die PG gegeben, da aber Cliff Fischer gerade das Weite gesucht hat (nein, ich weiß nicht, ob er zu Semperis kommen wird ) sind sie gerade im Schock und mit verminderter Mannstärke und Motivation unterwegs. Jetzt wo ich ein Lab habe, wo es nicht funktioniert, werde ich mal ein paar Traces ziehen und weiter schauen.

Moin, was sagt denn das LAPS-Eventlog auf einer betroffenen Maschine dazu?

Moin, ist denn der alte User beim migrieren Postfach ordentlich als Master eingetragen (das wäre dann eine Linked Mailbox)? Falls ja, noch ein paar Stunden warten oder den Informationsspeicher an der Quelle durchtreten, damit Autodiscover auch weiß, dass das Postfach migriert wurde...

Wir können uns am Dienstag gern zusammenTeamViewern, schick mir ne PM.

Das ist lustig und traurig zugleich, denn in meinem Lab führt das, was Du beschreibst, zum gegenteiligen Ergebnis...

https://smsagent.blog/2025/09/05/checking-for-updated-secure-boot-certificates/

@MurdocX nein, keine AuthN Policies hier.

Ja, das sind die Tickets, und Du müsstest auch ein TGT von BERLIN ausgestellt im 0x3e7 Kontext auf lab02-srv-muc01 finden. Ist es schon im Enforced-Modus oder noch Supported? Denn wenn es schon im Enforced ist, bist Du ja so weit wie ich

Der Typ ist 'ne Maschine. Jetzt hat er noch Adam Driscoll gekauft...

Ich meine, es gibt nach wie vor https://www.hv-manager.org/ , aber das Ding speichert Passwörter im Klartext und so ...

Der gezeigte Code ist unter https://github.com/psconfeu/2023/tree/main/EvgenijSmirnov/JEAonHyperV für alle Ewigkeit zu finden. Das Projekt-Repo habe uich dann beerdigt, weil sie WAC kaputt gemacht haben. Aber wenn es nur um Funktionalität geht ("sie sollen nur VMs starten/stoppen können, aber alle, die auf dem Host registriert sind"), ist es einfachstes JEA. Allerdings gibt es eine Funktionalität, die man auf die Weise nicht bekommt, und das ist der Zugriff auf die Konsole der VMs. Da muss der User mindestens Hyper-V Admin sein.

Moin, hast Du eine bestimmte Anleitung befolgt? (nur damit wir nicht jeden Schritt einzeln abfragen müssen...)

@MurdocX übrigens ist der Test "auf \\domain.name als PU-Member zugreifen" kein guter, der wird immer scheitern, denn es ist ja nicht möglich, den von Dir zitierten SPN auf mehr als einem DC zu registrieren. Wir hatten vor ein paar Monaten einen Thread dazu, den ich gerade nicht finde. \\domain.name\SYSVOL ist kein Thema, denn dann ist der DFS-N-Zauber erledigt und die Verbindung geht auf \\einer-der-dcs.domain.name\SYSVOL, wo der SPN dann existiert. Explorer-Zugriff auf \\domain.name ist nur mit NTLM möglich - es sei denn, die Domäne hat nur einen DC, auf dem man dann den SPN cifs/domain.name zusätzlich registriert - dann geht auch Kerberos.

I spoke too soon :-( Bei systematischem Testen, auf 2022, konnte ich die Situation nicht herbeiführen, dass sich ein User aus BRAVO, der dort in Protected Users ist, nicht in ALPHA interaktiv anmelden oder auf dortige Fileserver über SMB zugreifen könnte. Funktioniert alles einwandfrei. Meine Ideen waren: in dem Lab ist standardmäßig die Windows-Firewall auf "aktiv, aber offen" gesetzt --> das Rückführen auf Default-Regeln hat keine Änderung bewirkt in dem Lab ist (aus Performance- und Mimikatz-Gründen) Defender deaktiviert --> das Aktivieren inkl. Runtime-Protection hat keine Änderung gebracht alle VMs sind mit der gleichen unattend.inf gesysprepped, somit ist das Admin-Passwort bei allen gleich --> das Ändern des Admin-Passworts in allen Domänen und auf allen Members auf jeweils unterschiedliche Werte hat keine Änderung gebracht auf allen DCs war das DSRM-Kennwort ursprünglich identisch gesetzt (das schien die Bombe zu sein) --> das Ändern auf jeweils unterschiedliche Werte inkl. Reboot, Ticket Purge, Reboot hat keine Änderung gebracht Jetzt bleibt (euch) tatsächlich nur Loggen und Sniffen, denn ich kann's nach bestem Bemühen NICHT nachstellen.

Moin, es ist pro Datenbank. Allerdings ist es nicht die einzige Limitierung. Je nachdem, was in den Datenbanken so passiert, kann auch das Limit von 1 Socket (oder 4 Cores) einschränkend werden. Der Buffer Pool von 1,5 MB ist auch nicht riesig. Editions and Supported Features of SQL Server 2022 - SQL Server | Microsoft Learn