cj_berlin

@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

Ich meine, 5nine wurde in irgendwas hineingekauft.

Moin zusammen, ich glaube, ich habe die Antwort, und sie wird euch - und uns alle - nicht erfreuen. Muss noch abschließend validieren. Aber der erste "dumme" Test mit 2019 war bei mir auch erfolgreich, somit ist es nicht versionsabhängig. Hang on, die Bombe kommt.

Moin, ich habe darüber 2023 einen Vortrag auf der PSConfEU gehalten: https://youtu.be/-aZ2FJL7C5c Seitdem hat Microsoft so ein bisschen das WAC versaut, aber man kann das auch auf dem heutigen Stand stricken.

Ich habe Mittwoch bis Freitag Seminar. Wie cool wäre es, wenn wir es gelöst kriegen und ich live darüber erzählen kann Aber ich schau mal, ob ich morgen ein 2019er Lab schnell hingeworfen kriege. Aber ohne FAST!! Und bei mir ist auch dieses Ticket mit FAST. OK, also wir haben: @mzahneissen 2019 --> funktioniert nur mit Supported @cj_berlin 2022 --> funktioniert mit Enforced @MurdocX 2025 --> funktioniert nur mit Supported Bei 2025 glaube ich inzwischen alles, aber 2019 ist eigentlich gut abgehangen und sollte auf 2022er Niveau funktionieren...

Trust-Einstellungen sind bei mir genau so, es muss auch nichts am Trust extra fürs Armoring gesetzt werden - außer, dass die Client-Policy auch auf DCs gelten muss, aber ich schätze, das ist der Fall, denn sonst würde man sich gar nicht mehr anmelden können. Spannend. Ist es vielleicht doch ein OS-Versionsthema? Ich meine, einer von euch erwähnte 2019er DCs? Schon zu spät, um den Thread nochmal aufmerksam zu lesen...

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...

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...

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...

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.

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*.

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.

OK, wie versprochen: ungehärteter uneingeschränkter bidirektionaler Forest Trust Auf einer Seite: Root + Sub, auf der anderen Seite: Single-Domain Auf allen Members UND DCs gilt: "Kerberos client support for claims etc." = ENABLED, sonst keine Kerberos Client-Einstellungen abweichend von Defaults Auf allen DCs in allen drei Domains gilt: "KDC support for claims etc." = "Fail unarmored authentication requests" Beobachtetes Verhalten: User aus einer beliebigen Domain kann sich interaktiv an einem Member aus einer beliebigen Domain anmelden ("Domain Users" aller drei Domains sind in "Users" und "Remote Desktop Users" auf allen Members) User aus einer beliebigen Domain kann, interaktiv s.o. angemeldet, auf eine File Share aus der jeweils anderen Domain zugreifen. PKI ist keine implementiert, somit auch keine Strict KDC Validation oder Ähnliches. Nun musst Du @mzahneissen schauen, was bei Dir anders ist: Kerberos-Client-Policy doch nicht auf alle DCs angewendet? Trust nur in eine Richtung? Trust gehärtet? Selektive Authentifizierung am Trust? Ich schätze, wenn klist Dir bei "Supported" immer FAST-Tickets zeigt, solltest Du mal auf den DCs mit klist -li 0x3e7 schauen, ob es für die DCs genauso gilt... P.S. Clientseitig ist in meinem Lab "Fail request if armoring not available" nirgends gesetzt.

Ich bin gespannt, ob jemand Ideen hat. Ich bin am Freitag wieder im Lande und kann mir das anschauen, ich habe mindestens ein Labor, wo das funktioniert. (Disclaimer: Funktionierte im Sommer). Es ist in dieser unseren Zeit nicht auszuschließen, dass einer der letzten Patchdays das kaputt gemacht hat, selbst wenn's im Sommer noch funktioniert hat.

Solange das File per HTTP abrufbar ist, kann man den Pfad dazu auch per GPO verteilen. IE Proxy Settings.

Moin, ist auf die DCs auch die Kerberos Client-Policy für Armoring ausgerollt oder nur die KDC-Policy? Das ist der häufigste Fehler

Moin, DFS-N mit ABE. Braucht aber AD, und lokale Gruppen auf dem Fileserver, der die Freigabe tatsächlich hostet, werden schwierig.