MurdocX

@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