MurdocX

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