Alle Aktivitäten

@cj_berlin Danke für deine Vorschläge. Ich setze die Konfig gleich um und poste. Müssen beim Trust noch Konfigurationen für Claims/Amoring gesetzt werden? Um hier eventuell ein Problem mit dem Trust auf die Schliche zu kommen, habe ich die Konfiguration ausgelesen. # DC-BER-ROOT PS C:\Users\Administrator> Get-ADTrust -Identity "muenchen.local" Direction : BiDirectional DisallowTransivity : False DistinguishedName : CN=muenchen.local,CN=System,DC=berlin,DC=local ForestTransitive : True IntraForest : False IsTreeParent : False IsTreeRoot : False Name : muenchen.local ObjectClass : trustedDomain ObjectGUID : 3e9bfdd5-73ab-49f1-bb6b-438038670354 SelectiveAuthentication : False SIDFilteringForestAware : False SIDFilteringQuarantined : False Source : DC=berlin,DC=local Target : muenchen.local TGTDelegation : False TrustAttributes : 8 TrustedPolicy : TrustingPolicy : TrustType : Uplevel UplevelOnly : False UsesAESKeys : False UsesRC4Encryption : False # DC-MUC-ROOT PS C:\Users\Administrator> Get-ADTrust -Identity "berlin.local" Direction : BiDirectional DisallowTransivity : False DistinguishedName : CN=berlin.local,CN=System,DC=muenchen,DC=local ForestTransitive : True IntraForest : False IsTreeParent : False IsTreeRoot : False Name : berlin.local ObjectClass : trustedDomain ObjectGUID : 9ac50009-8284-4ef3-908b-d8d481c6a742 SelectiveAuthentication : False SIDFilteringForestAware : False SIDFilteringQuarantined : False Source : DC=muenchen,DC=local Target : berlin.local TGTDelegation : False TrustAttributes : 8 TrustedPolicy : TrustingPolicy : TrustType : Uplevel UplevelOnly : False UsesAESKeys : False UsesRC4Encryption : False

Hmm, es fehlt das krbtgt-ST von der Gegenseite, durch diese bestätigt. Du hast: aber nicht (eingerahmt ist mein Äquivalent zu dem o.g. Ticket #0). Somit findet tratsächlich kein Kerberos über den Trust statt. Jetzt wäre spannend, ob dieses Ticket erscheint, wenn Armoring auf "Supported" steht... Falls ja, ist es, glaube ich, ein Fall für Wireshark und sehr hoch aufgedrehtes Diagnostic Logging... ...und wenn das Ticket nicht erscheint und der Zugriff dennoch zu funktionieren scheint - versucht's mal mit einem User, der in "Protected Users" Mitglied ist Nicht, dass doch ein Fallback auf NTLM stattfindet...

@mzahneissen das ist meine Testumgebung. Ich hatte AFAIK mal beim Härten diese Probleme und konnte sie mir nicht erklären. Daher habe ich das jetzt mal nachgestellt. @cj_berlin purge auf allen durchgeführt. Zugriffe getestet danach. Mich würde das Problem auch interessieren. Troubleshooting technisch wäre das mal richtig interessant, wo hier der Fehler liegt. Oder ob man evtl. selbst einen Fehler in der Konfiguration hat. Es ist aktuell nicht möglich von einer Domäne auf die Andere zuzugreifen. Auch nicht mehr für die DCs. Vermutlich lag das an den Tickets, die vorher mittels "Supportet" ausgestellt wurden. Diesmal sind alle DCs neugestartet und "klist purge -li 0x3e7" ausgeführt. # Konfiguration ⚙️ KDC - Kerberos Amoring -> Fail unamored authentication requests ⚙️ Alle DCs sind frisch installiert, default konfiguration, nicht gehärtet, trust transitiv, keine auth Einschränkung. # Domänenübergreifend ❌ DC-MUC-ROOT (muenchen.local) <-> DC-BER-ROOT (berlin.local) // Kein Zugriff möglich // Auth-Fenster erscheint ❌ LAB02-SRV-BER01 <-> LAB02-SRV-MUC01 // Kein Zugriff möglich // Auth-Fenster erscheint # Innerhalb der Domäne ✅ LAB02-SRV-BER01 <-> DC-BER-ROOT ✅ LAB02-SRV-MUC01 <-> DC-MUC-ROOT # DC1 - DC-MUC-ROOT PS C:\Users\Administrator> klist -li 0x3e7 Current LogonId is 0:0x1426900 Targeted LogonId is 0:0x3e7 Cached Tickets: (13) #0> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/BERLIN.LOCAL @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2025 11:50:42 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x240 -> FAST DISABLE-TGT-DELEGATION Kdc Called: DC-MUC-ROOT #1> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/OLCHING.MUENCHEN.LOCAL @ OLCHING.MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2025 11:43:10 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: DC-MUC-SUB.olching.muenchen.local #2> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/OLCHING.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/3/2025 11:43:09 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT #3> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/MUENCHEN.LOCAL @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize Start Time: 11/3/2025 11:40:58 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x42 -> DELEGATION FAST Kdc Called: DC-MUC-ROOT #4> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: krbtgt/MUENCHEN.LOCAL @ MUENCHEN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 11/3/2025 11:39:24 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: DC-MUC-ROOT #5> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: E3514235-4B06-11D1-AB04-00C04FC2DCD2/93a89448-8833-42a3-aec2-b14d9b8c178c/olching.muenchen.local @ OLCHING.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/3/2025 11:50:23 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-SUB.olching.muenchen.local #6> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: DC-MUC-ROOT$ @ 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/3/2025 11:43:20 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT #7> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: cifs/DC-MUC-ROOT.muenchen.local/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/3/2025 11:43:20 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT #8> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: ldap/DC-MUC-ROOT.muenchen.local/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/3/2025 11:43:20 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT #9> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: DNS/dc-muc-sub.olching.muenchen.local @ OLCHING.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/3/2025 11:43:10 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-SUB.olching.muenchen.local #10> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: LDAP/DC-MUC-ROOT @ 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/3/2025 11:43:09 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT #11> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: cifs/DC-MUC-ROOT @ 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/3/2025 11:40:58 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT #12> Client: dc-muc-root$ @ MUENCHEN.LOCAL Server: ldap/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/3/2025 11:39:24 (local) End Time: 11/3/2025 21:39:24 (local) Renew Time: 11/10/2025 11:39:24 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-MUC-ROOT # DC 2 - DC-BER-ROOT PS C:\Users\Administrator> klist -li 0x3e7 Current LogonId is 0:0x4c6bc Targeted LogonId is 0:0x3e7 Cached Tickets: (11) #0> Client: dc-ber-root$ @ BERLIN.LOCAL Server: krbtgt/MUENCHEN.LOCAL @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize Start Time: 11/3/2025 11:51:42 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x240 -> FAST DISABLE-TGT-DELEGATION Kdc Called: DC-BER-ROOT #1> Client: dc-ber-root$ @ BERLIN.LOCAL Server: krbtgt/BERLIN.LOCAL @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize Start Time: 11/3/2025 11:44:53 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x42 -> DELEGATION FAST Kdc Called: DC-BER-ROOT #2> Client: dc-ber-root$ @ BERLIN.LOCAL Server: krbtgt/BERLIN.LOCAL @ BERLIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize Start Time: 11/3/2025 11:44:52 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY Kdc Called: DC-BER-ROOT #3> Client: dc-ber-root$ @ BERLIN.LOCAL Server: cifs/DC-BER-ROOT.berlin.local/berlin.local @ BERLIN.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/3/2025 11:59:53 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #4> Client: dc-ber-root$ @ BERLIN.LOCAL Server: GC/DC-BER-ROOT.berlin.local/berlin.local @ BERLIN.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/3/2025 11:59:22 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #5> Client: dc-ber-root$ @ BERLIN.LOCAL Server: cifs/DC-BER-ROOT @ BERLIN.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/3/2025 11:49:37 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #6> Client: dc-ber-root$ @ BERLIN.LOCAL Server: DC-BER-ROOT$ @ BERLIN.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/3/2025 11:44:53 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #7> Client: dc-ber-root$ @ BERLIN.LOCAL Server: cifs/DC-BER-ROOT.berlin.local @ BERLIN.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/3/2025 11:44:53 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #8> Client: dc-ber-root$ @ BERLIN.LOCAL Server: LDAP/DC-BER-ROOT.berlin.local/berlin.local @ BERLIN.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/3/2025 11:44:53 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #9> Client: dc-ber-root$ @ BERLIN.LOCAL Server: ldap/DC-BER-ROOT.berlin.local @ BERLIN.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/3/2025 11:44:52 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT #10> Client: dc-ber-root$ @ BERLIN.LOCAL Server: LDAP/DC-BER-ROOT @ BERLIN.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/3/2025 11:44:52 (local) End Time: 11/3/2025 21:44:52 (local) Renew Time: 11/10/2025 11:44:52 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC-BER-ROOT

@intellekta Moin Dein von Dir ausgegrabener Themen-Zombie ist sage und schreibe 19 Jahre (!) alt, damit hast Du wahrscheinlich den Boardrekord für den ältesten Wiedergänger gebrochen. Das Board hat Dir vor dem Posten einen Warnhinweis bezüglich des Alters dieser Diskussion angezeigt, damit genau so etwas NICHT passiert. Also bitte in Zukunft beachten. Danke. Hier schließe ich zu, sonst lockt das noch mehr Grabräuber an. VG Damian

Moin, na, dann nimm das doch. Gruß, Nils

Was willst Du? Es funktioniert ja, du musst es nur konfigurieren.

Bei mir sind die DCs und Member alle 2022, gepatcht auf Oktober. "gehärteter Trust" wäre einer, wo dieser Trust User Account mit einer AuthN Policy bewehrt ist, die immer fehlschlägt, so dass er sich nicht authentifizieren kann (gehärtet gegen das Durchbrechen in die falsche Richtung). Wir machen das gern inzwischen auch bei bidirektionalen Trusts, denn wer weiß, ob nicht doch eines Tages auf unidirektional umgestellt wird...

Nichts, ich werde das mal testen. Ich finde es wirklich Schade, dass das nicht geht.

Hallo @cj_berlin, danke für Deine Tests. Was genau meinst Du mit gehärtetem Trust? @MurdocX, danke für Deinen Post, ich dachte schon, wir sind die einzigen mit dem Problem. Welche Version sind Eure DCs?

# Aktive Verbindungen über Get-SmbMapping $smb = Get-SmbMapping | ForEach-Object { [PSCustomObject]@{ Laufwerk = $_.LocalPath ServerFreigabe = $_.RemotePath Benutzer = if ($_.UserName) { $_.UserName } else { $currentUser } } } write "smb" $smb | Format-Table -AutoSize

Jupp! Werde bestimmt dabei sein...

Moin Dann steht ja bald ein großes Jubiläum an. VG Damian

Moin an Board, auf geht’s in eine neue Woche - und den Monat November - ich koche Kaffee Allen einen guten Montag, bleibt gesund! Hier derzeit bewölkt bei 7°C die sich wie 3°C anfühlen. Es bleibt den ganzen Tag bewölkt bis etwa 12°C Freimarkt der 990te ist vorbei, wird sich die Parkplatzsituation entspannen

Moin, das ist natürlich unerfreulich NTLM sollte damit nichts zu tun haben, wenn NTLM zulässig ist. Ich kann die Shares in beliebigen Konstellationen auch über IP (also mit NTLM) erreichen, habe dann auch kein Service-Ticket im Cache. Was sagt denn auf den DCs in dieser Situation klist -li 0x3e7 klist -li 0x3e7 ? Gern auch mal purgen und erneut versuchen...

Ich habe das gleiche Verhalten wie @mzahneissen in meiner Testumgebung. @cj_berlin - sorry, ich hab deine Textbausteine einfach schnell kopiert ;) # Setup ungehärteter uneingeschränkter bidirektionaler Forest Trust (Dom A & Dom B, Dom B1) Auf einer Seite: Root + Sub, auf der anderen Seite: Single-Domain Auf allen Members UND DCs gilt: "Kerberos client support for claims etc." PKI ist keine implementiert, somit auch keine Strict KDC Validation oder Ähnliches Aktueller Updatestand auf allen Domaincontrollern und Servern Credential-Guard auf allen Server ist aktiv # KDC - Kerberos Amoring -> Supportet ✅ Server (Dom A) greift auf DC (Dom A) zu ✅ Server (Dom A) greift auf Share Server (Dom B) - vice versa ✅ DC (Dom A) greift auf Share DC (Dom B) - vice versa ✅ Anmelden mit Benutzern der jeweils anderen Domäne # KDC - Kerberos Amoring -> Fail unamored authentication requests ✅ Server (Dom A) greift auf DC (Dom A) zu ❌ Server (Dom A) greift auf Share Server (Dom B) - vice versa -> Benutzerabfrage, vermutlich NTLM. ✅ DC (Dom A) greift auf Share DC (Dom B) - vice versa ❌ Anmelden mit Benutzern der jeweils anderen Domäne Ich bekomme auf dem Server, wenn ich mit einem User der anderen Domäne anmelden möchte: -> Security, 4625, Failure Reason: An Error occured during Logon, Status: 0xC000006D, Logontype: 2 0xC000006D: The attempted logon is invalid. This is either due to a bad username or authentication information. SubType: 0x0

Moin, und willkommen im Forum! das regelst Du im AD: Abgebildet sind die Default-Einstellungen, d.h. wenn Du das ganze z.B. pro Gruppe regeln möchtest, baust Du einen NPS-Server und regelst das ganze dort mit CAP/RAP. Würde ich auch immer empfehlen, sofern man überhaupt RRAS als VPN-Konzentrator einsetzen möchte.

Hallo zusammen, ich bekomme unter Windows Server 2022 den Routing und RAS Dienst, nur VPN nicht zum Laufen. Folgendes habe ich bisher gemacht: Routing und RAS installiert VPN ausgewählt IP Adressbereich konfiguriert Wo lege ich die berechtigten Benutzer fest?

Das hat niemand vorgeschlagen, und schon gar nicht ich. Server, die Dienste an User bereitstellen, sollen natürlich ins AD, um reibungslose Authentifizierung und Autorisierung zu ermöglichen. Hier reden wir hingegen von Infrastruktur, auf die nur Admins direkten Zugriff haben dürfen. Vollkommen andere Schicht. VMware --> das Security-Handbuch empfiehlt seit 7 oder 6.7, vSphere nicht mehr zum AD zu joinen und auch keine AD-Autorisierung mehr zu betreiben. Veeam --> empfiehlt seit geraumer Zeit, keine Backup-Infrastruktur zum AD zu joinen Microsoft --> für Azure Local wird AD zwar empfohlen, weil Windows-Cluster mit AD nun mal besser zu managen sind als ohne, aber ein *separates von Produktion*.

Proxmox (das gleiche wie VMware) sind wir am testen. Datacore funktioniert bei uns tadellos (mehrere PB). Nur brauchste dafür halt auch ein SAN um Datacore nutzen zu könnnen. Was meinst Du eigentlich mit "Clusterbetrieb mit hoher Verfügbarkeit"? Wenn es um Verfügbarkeit geht, mußt du auf vieles achtet. erstmal mußt festlegen wie hoch deine Verfügbarkeit sein soll bzw. wie gering deine Downtime sein darf (das muss alles die Firmenleitung festlegen) muss dir klar sein, das Hochverfügbarkeit per se teuer ist, 98,5% = knappe 6 Tage Downtime, 99% = 3,6 Tage, 99,9% = 8,7 Std. je mehr Neunen desto teurer und zwar exponentiell, deine ganze Infrastruktur muss darauf ausgelegt. Server mit mehrerern Netzwerkkarten/Ports, reduntant ausgelegte Switche, Router usw., das SAN muss dafür natürlich auch ausgelegt sein. Also brauchste dafür schon mal beim SAN Storage alles doppelt. die Wiederherstellung liegt ja bei Dir. Du mußt ein Backupkonzept erstellen, deine Bosse müssen sich über RTO und RPO Gedanken machen dann kannst auch was über Wiederherstellungszeiten sagen namhafte Hersteller (z.B. DELL, HPE). Da brauchste mit Wortmann oder Thomas Krenn net anfangen brauchste natürlich einen gscheiten Wartungsvertrag mit dem Hersteller mit entsprechenden Reaktions- bzw. Entstörzeiten wenn du bei einem davon das Sparen anfängst dann kannste deine Hochverfügbarkeit gleich in die Tonne kloppen Interessanter Ansatz: Also am besten keinerlei Server ins AD aufnehmen und somit maximalen Verwaltungsaufwand betreiben. Ziemlich fern jeglicher Realität deine "Idee".

Hi Jan, die Frage war mit Absicht etwas offener .. es ging mir nicht ums Grundwissen, sondern um echte Erfahrungswerte mit Alternativen. Ich kenn den TerraXaler sehr genau, hab jahrelang intensiv und tief damit gearbeitet – wirklich bis runter auf Systemebene. Sagen wir so: Ich weiß, was dahintersteckt, und für mich ist das Verhältnis zwischen Marketing und tatsächlicher Technik schlicht nicht überzeugend. Viele Funktionen, die dort als exklusive Features verkauft werden, stammen im Kern aus kostenlosen Software Features von anderer Hersteller. Das ist legitim, aber für mich kein Grund, so viel Geld auf den Tisch zu legen. Gesucht wird eine Lösung für rund 20 VMs, verteilt auf zwei Brandabschnitte, mit 25G-Verbindung zwischen den Hosts. Ziel ist eine stabile, nachvollziehbare und langfristig wartbare Umgebung. Im Blick hab ich aktuell Proxmox, Datacore, S2D und Nutanix. Mich würde interessieren, was davon bei euch wirklich sauber läuft, vor allem was Wiederherstellungszeiten und Pflege angeht.

Und warum nicht einfach den 2019 runterstufen? alternativ das Konto den alten dc löschen und die frage mit ja beantworten. Dann im DNS die Einträge für die Zone bereinigen und die hosteinträge entfernen. Aber wie gesagt einfach runterstufen und alles ist gut.

Hallo, ich habe vor einiger zeit eine Migration einer Domain von einem Windows 2019 Essentials zu einem Windows 2022 Server gemacht. Noch läuft der Windows 2019 Essential. Abschließend sollte man eigentlich neben Zertifikatsdienst auch die AD Rollen entfernen aber ich habe mal gehört man kann den Server auch einfach ausschalten und auf die neuen Domaincontroller Einträge löschen kann damit der denkt er ist der einzige und kein Replikations Server mehr vorhanden. Gibs das und wenn ja was für Einträge müsste man abändern? Gruß Marcel

Hi, sei mir nicht böse: Wenn man sich damit auskennt, stellt man hier nicht eine solch "oberflächliche" Frage. Was ist dir am Xaler denn zu unsicher und ist somit ein No-Go für die zu findende Lösung? Die Rückfragen von @cj_berlin hätte der Xaler btw. im Gepäck. Den kannst du in zwei Brandabschnitte packen und er bringt ein gehärtetes Active Directory für die Virtualisierungsinfrastruktur mit. Wenn du keine Äpfel mit Birnen vergleichst und dir ähnliche, fertige Lösungen ansiehst, wirst du preislich immer in einer ähnlichen Region landen. Generell wären wirkliche Anforderungen hilfreich. Danach kann man dann das benötigte Budget ermitteln und schraubt dann ggfs. die Anforderungen runter oder das Budget hoch. Da der Xaler genannt wurde, kannst du dir ähnliche Lösungen ansehen wie bspw. Azure Local, S2D, VMware vSAN, HPE VM Essentials, Nutanix, verge.io, Proxmox/Ceph, ... Gruß Jan

Moin, und willkommen im Forum! Die Schrift Deines Posts sieht nach Copy/Paste von woanders aus - ist es ein Cross-Post? Falls ja, bitte verlinken oder zumindest darauf verweisen. Du schreibst nicht, welche Workloads Dein Cluster bedienen soll. Die Erwähnung von TerraXaler lässt virtuelle Maschinen vermuten, aber, wie Reacher zu sagen pflegte, Vermutungen töten. Du schreibst auch nicht, wieviele Knoten Du anstrebst, und ob sie alle untereinander im gleichen Rack hängen oder auf mehrere Brandabschnitte verteilt werden sollen, und falls Zweiteres, ob der Ausfall eines ganzen Brandabschnittes ebenfalls aufgefangen werden soll. Wenn Du mit "in bestehende Windows-Umgebungen integrieren" so etwas wie "zum bestehenden AD joinen" meinst, solltest Du das lieber gleich wieder überdenken. Böse Menschen, die eines Tages Dein System ungefragt administrieren werden, freuen sich immer sehr über AD-gejointe Infrastruktur.

Hey zusammen, ich bin aktuell auf der Suche nach einer stabilen und bezahlbaren Lösung für einen Clusterbetrieb mit hoher Verfügbarkeit – allerdings ohne TerraXaler. Das System ist mir ehrlich gesagt zu unsicher und preislich auch völlig überzogen für das, was man real bekommt. (Wenn man sich damit auskennt) Ziel ist ein Setup mit möglichst wenig Downtime bei Hardwareausfall, idealerweise mit automatischem Failover und zentralem Storage oder Replikation. Interessant wären Lösungen, die sich gut in bestehende Windows Umgebungen integrieren lassen