cj_berlin

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.

Ja, und gibt es die konkret bei Dir? Du kannst ja certlm.msc auf einem DC öffnen und schauen, welche Vorlagen für einen DC überhaupt zum Enrollment angeboten werden, um dann zu überprüfen, welche von ihnen auf Autoenroll für DCs, Domain Computers oder Authenticated Users stehen (letzteres sollte es grundsätzlich nicht geben).

In dem von Dir verlinkten Artikel sehe ich nicht, dass man das Recht "Automatisch registrieren" herausnehmen soll - man soll vielmehr verifizieren, DASS es besteht??? Oder was war Deine Frage? Und zur Zeitschiene der Ablösung: Wenn Deine PAM-Software nicht ein bestimmtes Zertifikat auf den DCs erwartet, das man dort händisch hochladen soll, ist es doch kein Problem, wenn lange vor Ablauf ein {vertrauenswürdiges Zertifikat mit korrekten Namen und EKUs} gegen ein anderes {vertrauenswürdiges Zertifikat mit korrekten Namen und EKUs} ausgetauscht wird?

Moin, aber habt ihr auch tatsächlich einen Use Case für LDAPS? Denn nur dann lohnt es sich, den ganzen Aufwand zu betreiben.

Moin, sowas in der Art? https://www.davidpashley.com/articles/automatic-proxy-configuration-with-wpad/

Das hatten wir mal gemacht für Genehmigungen, aber da war ein Reverse Proxy mit Cert Preauth davor.

Moin, das ist alles irgendwie sehr konfus. Wenn nur Clients dieses Programm aus einer Freigabe starten, muss es doch nach dem Umzug lediglich diese Freigabe wieder geben, idealerweise unter demselben Namen. Nun habe ich Foundation nicht mehr so im Kopf, glaube aber mich zu erinnern, dass er zwingend Domain Controller sein muss. Somit hast Du ein Active Directory, in dem (wieder Annahme) die Clients Mitglied sind. Wenn das alles zutrifft, sähe die Migration wie folgt aus: BACKUP!!!!!! Server 2019 wird zur Domäne hinzugefügt und zum DC hochgestuft Datenordner werden per Robocopy kopiert und unter den gleichen Namen freigegeben FSMO-Rollen werden vom 2012R2 auf 2019 verschoben, der 2012R2 heruntergestuft und aus der Domäne entfernt, danach vom Netz getrennt oder zumindest umbenannt. Server 2019 wird gemäß Rename Domain Controller - Der Windows Papst - IT Blog Walter in den Namen des 2012R2 umbenannt Theoretisch müssten die Clients die Anwendung wieder finden und auch aufrufen können. Wenn jetzt auf dem 2012R2 ein Datenbankserver irgendeiner Art läuft (SQL, Firebird, MySQL, was weiß ich), dann lass lieber den Hersteller der Anwendung die Migration machen. Das werden wir hier im Forum nicht gelöst bekommen.

Was wir in solchen Szenarien meistens getan haben, war folgendes: Accounts im Ziel anlegen (wegen mir per PowerShell, insbesondere wenn auch OU-Strukturen stark unterschiedlich sind) Die Attribute, die im Ziel wichtig sind, so konfigurieren, wie im Ziel vorgesehen, und aus der Quest-Sync ausschließen Dann die Sync anschalten (irgendein Attribut muss ja zum Matching vorhanden sein, zu Not benutzerdefiniert) und Kennwort, sidHistory, Gruppenmitgliedschaften, managedBy und den ganzen Beziehungsrotz synchronisieren lassen Wenn euer DL nicht gerade "Facts & Figures" ist (aber die verstehen ihr Handwerk, das wäre euch da nicht passiert) können sie mich gern kontakiteren und die Ideen mal mit einem frischen Satz Augen von jemandem, der jahrelang auf der "PSO Waiver"-Liste für dieses Produkt gestanden hat, begutachten lassen

Du nutzt bei manage-bde den -SkipHardwareTest switch und bei Enable-Bitlocker nicht

ADD: Im Quest Migration Manager kann man die Synchronisierung des "name" anfordern, was einer Umbenennung des Objektes gleichkommt, falls es bereits vorhanden war aber unter einem anderen CN...

https://www.rlmueller.net/Name_Attributes.htm Das sollte es klarer machen. Du kannst name nicht getrennt von CN verwenden.

Das meinte ich auch. Im OP wird die Kerberos-Fehlermeldung zitiert. Diese kann nur auftreten, wenn die Knoten im AD Mitglied sind.

Nee, die fehlt nicht, denn Nicht-Domainmember sprechen bis heute kein Kerberos miteinander, auch wenn das versprochen wurde.