MurdocX

Ich fange mal an... ;)

Hi Herbert, laut deinem Screenshot ist die Meldung von Adobe. Vermutlich vom Adobe Acrobat Reader. Ein Versuch wäre: die Anwendung zu entfernen/Neuinstallation oder zu reparieren. VG, Jan

Hi, schau mal hier, dass könnte was für das Thema sein: [ Verwenden des SQLIOSim-Hilfsprogramms zum Simulieren der SQL Server-Aktivität auf einem Datenträgersubsystem ] Das SQLIOSim-Hilfsprogramm simuliert die Datenträgersubsystemaktivität. - SQL Server | Microsoft Learn Selbst habe ich das Tool noch nicht getestet. Mit den richtigen Parametern wirst du sicherlich auch mit DiskSpd weiterkommen, die ich aber nicht kenne. VG, Jan

Gerade die Übermittlungsoptimierung kann viel Upload verursachen. Du könntest sie an lassen und gezielt mit den Leistungsdaten den Dienst überwachen. Dann lassen sich die Vermutungen in Zahlen darstellen. Solltest du hier noch weitere Hilfe benötigen, dann einfach melden. VG, Jan

Hi, mit dem Tool kannst du deine aktuellen Verbindungen messen, wirst aber nicht unbedingt herausbekommen welche Anwendung hier viele Daten schickt. Das Tool ist auch nicht gedacht Stundenweise Daten zu sammeln. PerfMon ist hier das Tool deiner Wahl, um genau an die Informationen zu kommen. Hiermit können Leistungsdaten gemessen werden. Das hat in meinem Test gut funktioniert. Erstelle einen Benutzerdefinierten auf Leistungsindikator basierenden Datensammlersatz. Nimm folgende Leistungsindikatoren: Danach kannst du unter den Berichten eine Auswertung fahren. VG, Jan

Hmm, damit lässt sich nicht viel Anfangen. Lässt sich "service_process" noch etwas detaillierter darstellen? Ohne Daten wäre es pures raten. Hier ist auch nicht mal eine IP ersichtlich. Da brauchen wir schon deutlich mehr, wenn man Rückschlüsse ziehen soll. Log deine Daten mal mit: [ Collect data using Network Monitor ] Collect data using Network Monitor - Windows Client | Microsoft Learn

Hi, Leider sieht man das Bild nicht. Lade doch nochmal hoch oder stelle die Info als Text bereit.

Hallo zusammen, ein neuer Teil der Active Directory Hardening Series von Jerry Devore ist erschienen. Active Directory Hardening Series - Part 8 – Disabling NTLM Active Directory Hardening Series - Part 8 – Disabling NTLM | Microsoft Community Hub Series: Tag:"adhardening" | Microsoft Community Hub Viel Spaß beim Lesen. VG, Jan

@daabm Bei mir in der ISE lief dein Erster - nicht KI-Code - besser Tolle Idee btw! Schöne Weihnachtstage Euch auch. VG, Jan

Vielen Dank! Das wünsche ich uns allen. Als "Dichter und Denker" müsste uns das Nachdenken nicht schwer fallen

In solchen Umgebungen sind Probleme mit dem Abruf der CRL und der dadurch fehlgeschlagenen Zertifikatsprüfung nicht selten.

Wir nutzen auch den Defender. Manche Phänomene hatten sich am nächsten Tag in Luft aufgelöst An sich sind wir zufrieden.

Also ich fasse hier nochmal zusammen: DC demoten, Server umbenennen, DC promoten Server parallel installieren und promoten, alt benamten DC dann demoten Über einen PS Befehl "Rename-Compter" (Habe ich übrigens auch schon im lab erfolgreich durchführt und keine Fehler festgestellt) Alles Möglichkeiten die Umsetzbar sind und eine qualitative Güte bieten.

Hat der 2025-DC einen offenen Internetzugriff? Oben wurde etwas von einem Proxy erwähnt.

Schön.

Ich sehe es auch wie meine Vorredner. Gerne übersehen wird bei Problemen auch: -> SeDenyNetworkLogonRight "Deny access to this computer from the network" VG, Jan

Es müssen nur die "DNS Client Events" aktiviert werden (Enable Log). Keine Debugging Logs hier nötig. In dem Zuge nicht vergessen auch auf allen Domaincontrollern nachzusehen. Denn die Anfragen wirst du nur auf dem angefragten finden. * Enable Log * LogName: Microsoft-Windows-DNS Client Events/Operational, Source: Microsoft-Windows-DNS-Client, ID: 3010 $domain = "my.domain.de" Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-DNS-Client";ID=3010} | Where-Object {$_.Properties[0].Value -like $domain}

Es gibt nur noch 2 Möglichkeiten: Ich stelle mich einfach zu doof an 🤯 @cj_berlin ist ein Magier 🧙‍♂️ Ich hab noch 4x Server 2019 hochgezogen. Keine Updates Netzwerkkonfig gesetzt Domäne hochgezogen Trust erstellt (2-Way forest, keine einschränkung bei der auth.) Gegenseitiges Anmelden an den anderen Servern Kerberos-Tickets enthalten "FAST" Leider keinen Erfolg, sobald es restricted wird. Innerhalb der Domain alles kein Thema. Reboot tut gut. Danach hat es einwandfrei geklappt. Mit 2019 gibts keine Probleme.

Ja leider. Normalerweise würde ich jetzt mit der Suche wieder vorne bei der Einrichtung/Konfiguration beginnen. Die Systeme sind sogar in englisch installiert, um hier sonderlocken Fehler vorzubeugen. Ich bin durchaus bereit eine Teamviewer-Session bereitzustellen, falls sich jemand das antuen möchte Sollte kein Interesse bestehen, kann ich das auch verstehen.

Also ich bin langsam mit meinem Latein am Ende. Ich habe noch etwas mit den Gruppenrichtlinien auf KDC und Kerberos gespielt aber leider keinen Erfolg gehabt. Mir ist der Handshake der Server klar, aber der Vergleich der Wireshark Ergebnisse macht mich leider nicht schlauer. Sobald die Konfiguration im Trust auf beiden Seiten auf "Fail unamored authentication requests" steht, funktioniert die Kommunikation nicht mehr. Getestet ist jeweils mit einer frischen Installation und den aktuellen Oktober-Updates. Sollte noch jemand eine Idee haben, dann bin ich offen das zu testen. VG, Jan

@cj_berlin hast du zufällig bei Dir in der Testumgebung Authenication Policies und Silos? Laut meiner Recherche scheint sich zu verdichten, dass Cross-Forest-Referral ohne Claims/Compound kein FAST enthalten. Kannst du das evtl. gegenprüfen? Ich bin bzgl. Claims/Compound nicht mit festem Schuhwerk unterwegs, um eine valide Aussage treffen zu können.

@cj_berlin Das Ergebnis habe ich bekommen, also ich vom Member in berlin.local auf den Member in muenchen.local zugegriffen habe. Anderst herum, wurde es mit einem Fehler quittiert. Leider bisher nur die halbe Miete. So langsam gehen mir die Ideen aus. Ich werde mal das KDC-Logging auf den DCs einschalten. @daabm alles Beides doch "legacy" Konfiguration ⚙️(Domäne berlin.local) KDC - Kerberos Amoring -> Fail unamored authentication requests ⚙️(Domäne muenchen.local) KDC - Kerberos Amoring -> Supportet berlin.local -> muenchen.local ✅ muenchen.local -> berlin.local ❌ * muenchen.local -> berlin.local klist get cifs/lab02-srv-ber01.berlin.local Current LogonId is 0:0x673703 Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x52e klist failed with 0xc000006d/-1073741715: The attempted logon is invalid. This is either due to a bad username or authentication information. * Screenshots Member muenchen.local * Screenshots Member muenchen.local

@daabm ich hab gerade kurz drübergelesen und gleich wieder aufgehört ... 2 Themen bekomme ich abends nicht mehr gebacken. Wenn du dich hier anschließt, dann bist du auf jeden Fall für das NEXT LEVEL auch gerüstet, wenn´s bei euch los geht @cj_berlin gehen die Tickets in die gewollte Richtung? #2> Client: adm-weis-ber @ BERLIN.LOCAL Server: cifs/lab02-srv-muc01.muenchen.local @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/5/2025 10:24:02 (local) End Time: 11/5/2025 20:24:02 (local) Renew Time: 11/12/2025 10:22:11 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x240 -> FAST DISABLE-TGT-DELEGATION Kdc Called: DC-MUC-ROOT.muenchen.local #3> Client: adm-weis-ber @ BERLIN.LOCAL Server: cifs/DC-MUC-ROOT.muenchen.local @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize Start Time: 11/5/2025 10:22:39 (local) End Time: 11/5/2025 20:22:39 (local) Renew Time: 11/12/2025 10:22:11 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x240 -> FAST DISABLE-TGT-DELEGATION Kdc Called: DC-MUC-ROOT.muenchen.local

So, jetzt komme ich wieder zu unserem kleinen Projekt. Sehr schade zu hören, dass du nicht erfolgreich warst. Das wäre schon etwas bequem gewesen Die Erwartungen waren groß Das soll das Thema nicht schmälern, sondern gerade das gibt ihm jetzt die nötige Würze. Zugegebener Weise wirds jetzt hackelig. Ich bin auch nicht mehr der Wireshark-Profil. Mit gemeinsamen Kräften bekommen wir das aber hin. Und vielleicht lernen wir - und unsere Leser - auch was dabei Dann sind jetzt meine folgenden Steps: Wireshark installieren Tickets auf den DCs löschen Verbindung (intelligent) Filtern und stöbern @cj_berlin Gibt es deinerseits bestimmte Kerberos Rückmeldungen auf die ich achten sollte? Vielleicht möchten sich noch zusätzlich AD Sepezies anschließen? Ich will ja niemanden beim Namen nennen @daabm

An mir soll es nicht scheitern Vollkommen richtig :/ # Versuch 1 Wie vorgeschlagen habe ich einen DA erstellt und ihn in die Protected Users geschmissen. Am DC angemeldet. Nun bekomme ich eine Fehlermeldung. DC-MUC-ROOT -> "\\berlin.local" (identisch mit dem anderen DC) # Versuch 2 Folgenden Fehler kann ich im Eventlog triggern, wenn ich mich mit DA + Protected-Users versuche vom MUC-DC zum BER-DC "\\berlin.local" auf die Share zu verbinden: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Microsoft-Windows-Security-Kerberos" Guid="{98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1}" /> <EventID>100</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2025-11-03T22:24:02.4441868Z" /> <EventRecordID>181</EventRecordID> <Correlation /> <Execution ProcessID="884" ThreadID="4012" /> <Channel>Microsoft-Windows-Kerberos/Operational</Channel> <Computer>DC-MUC-ROOT.muenchen.local</Computer> <Security UserID="S-1-5-18" /> </System> - <EventData> <Data Name="SPN">cifs/berlin.local@BERLIN.LOCAL</Data> <Data Name="ErrorCode">7</Data> </EventData> </Event> # Abfrage registrierter SPNs auf dem DC-BER-ROOT PS C:\Users\Administrator> setspn.exe -L DC-BER-ROOT Registered ServicePrincipalNames for CN=DC-BER-ROOT,OU=Domain Controllers,DC=berlin,DC=local: Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/DC-BER-ROOT.berlin.local ldap/DC-BER-ROOT.berlin.local/ForestDnsZones.berlin.local ldap/DC-BER-ROOT.berlin.local/DomainDnsZones.berlin.local TERMSRV/DC-BER-ROOT TERMSRV/DC-BER-ROOT.berlin.local DNS/DC-BER-ROOT.berlin.local GC/DC-BER-ROOT.berlin.local/berlin.local RestrictedKrbHost/DC-BER-ROOT.berlin.local RestrictedKrbHost/DC-BER-ROOT RPC/48f0492e-6c55-4aa3-a3d2-7ed973937035._msdcs.berlin.local HOST/DC-BER-ROOT/BERLIN HOST/DC-BER-ROOT.berlin.local/BERLIN HOST/DC-BER-ROOT HOST/DC-BER-ROOT.berlin.local HOST/DC-BER-ROOT.berlin.local/berlin.local E3514235-4B06-11D1-AB04-00C04FC2DCD2/48f0492e-6c55-4aa3-a3d2-7ed973937035/berlin.local ldap/DC-BER-ROOT/BERLIN ldap/48f0492e-6c55-4aa3-a3d2-7ed973937035._msdcs.berlin.local ldap/DC-BER-ROOT.berlin.local/BERLIN ldap/DC-BER-ROOT ldap/DC-BER-ROOT.berlin.local ldap/DC-BER-ROOT.berlin.local/berlin.local