testperson 1.827 Geschrieben vor 3 Stunden Melden Geschrieben vor 3 Stunden Solange wir nicht über S2D Cluster reden, kann ich gut und gerne aufs WAC verzichten. Ich könnte mir aber vorstellen, dass (früher oder) später auch ein WAC Support für Workgroup Cluster kommt. Welchen ein und anderen Nachteil siehst du / sehen Manfred und Carsten denn noch? Ich könnte mir bei den beiden allerdings auch vorstellen, dass wir über S2D / Azure Local reden. Zitieren
Dukel 466 Geschrieben vor 3 Stunden Melden Geschrieben vor 3 Stunden WAC ist auch mit Workgroup möglich (man muss aber das Powershell Remoting konfigurieren). Was nicht funktioniert, ist den Hyper-V Cluster mittels WAC zu erstellen. Da wird im Wizard ein AD benötigt. Zitieren
Marco31 37 Geschrieben vor 3 Stunden Autor Melden Geschrieben vor 3 Stunden Na ja, kein LAPS zum Beispiel. Logisch. Wieder das leidige Thema des regelmäßigen Passwort änderns auf lokalen Admin-Konten. Und logischerweise auch kein protected Users Gruppe, die ich bei meinen administrativen Konten verwende. Aber ist wie immer, einen Tod muss man sterben Werde mir das ganze nochmal in Ruhe anschauen und testen sobald die Hardware da ist. Zitieren
NilsK 3.025 Geschrieben vor 3 Stunden Melden Geschrieben vor 3 Stunden Moin, das hat jetzt aber schon was davon, das Haar in der Suppe zu suchen. Auf zwei Nicht-AD-Hosts kannst du auf beide genannten "Nachteile" ja gut verzichten. Auch ein lokales Adminkennwort muss man nicht per se regelmäßig wechseln, wenn es ausreichend stark ist. Der Witz an LAPS ist doch primär, dass man von massenweise verwendeten identischen Adminkennwörtern weg will - das kann man für den Use Case doch problemlos organisatorisch sicherstellen. Ähnlich bei Protected Users - die meisten Maßnahmen, die das umsetzt, kommen bei lokalen Systemen ja gar nicht in Betracht, und vom Rest lässt sich ein Großteil organisatorisch abfangen. Wenn ich mir ansehe, wie freimütig die meisten VMware-Systeme in der freien Wildbahn so eingerichtet sind, sehe ich da wirklich keinen grundsätzlichen Nachteil ... Gruß, Nils Zitieren
NorbertFe 2.266 Geschrieben vor 2 Stunden Melden Geschrieben vor 2 Stunden Und hyper-v Hosts mit laps sind auch ein Stolperstein, wenn mal die komplette Umgebung down sein sollte. Und ja alles schon erlebt. Utilman.exe hilft zwar, dauert aber alles in solche Situationen. ;) seitdem sind die hyper-v Hosts bei den Kunden meist ohne laps konfiguriert und haben einfach komplexe lange Kennwörter, die man ja nie eingeben muss, solange die Dinger im ad hängen. Zitieren
Dukel 466 Geschrieben vor 2 Stunden Melden Geschrieben vor 2 Stunden Es gibt auch regelmäßig den Trend, dass man alle Management Maschinen (Hypervisor, egal welcher Hersteller; Server Remote Access (iLo, iDrac,...); Backup Server; etc.) mal ins AD aufnehmen sollte und dann wieder aus dem AD entfernen sollte usw. Hat halt beides vor und Nachteile. Zitieren
Marco31 37 Geschrieben vor 2 Stunden Autor Melden Geschrieben vor 2 Stunden Ok, alles gute Argumente. Habe aber gerade gelesen dass ich für Server 2025 Workgroup Cluster Zertifikate brauche... Keine CA, wird schwierig. Wenn mir da unser Rechenzentrum nicht gnädigerweise Zertifikate ausstellt wird das nix. Mal schauen. Gibt ja jetzt genug für und wieder, muss nur noch sehen welche "Probleme" ich lösen kann und mit welchen Einschränkungen ich leben kann/will. Auf jeden Fall schon mal danke für die Beteiligung! Zitieren
NilsK 3.025 Geschrieben vor 2 Stunden Melden Geschrieben vor 2 Stunden Moin, na, und noch so ein Missverständnis, das wir ausräumen können. Für einzelne Server-Zertifikate brauchst du ja keine CA bzw. PKI. Im Gegenteil, für so einen Zweck würde ich sogar entschieden davon abraten. Es geht normalerweise darum, dass Zertifikate vorliegen, denen die Systeme vertrauen. Das kann man mit minimaler Infrastruktur einrichten, für die man keine komplexen und anfälligen Systeme braucht. Exemplarisch habe ich das hier mal skizziert: [LDAPS in einer Windows-Domäne ohne PKI | faq-o-matic.net] https://www.faq-o-matic.net/2024/06/18/ldaps-in-einer-windows-domne-ohne-pki/ Gruß, Nils PS. PKI ist böse. Zitieren
Marco31 37 Geschrieben vor 2 Stunden Autor Melden Geschrieben vor 2 Stunden vor 7 Minuten schrieb NilsK: Moin, na, und noch so ein Missverständnis, das wir ausräumen können. Für einzelne Server-Zertifikate brauchst du ja keine CA bzw. PKI. Im Gegenteil, für so einen Zweck würde ich sogar entschieden davon abraten. Es geht normalerweise darum, dass Zertifikate vorliegen, denen die Systeme vertrauen. Das kann man mit minimaler Infrastruktur einrichten, für die man keine komplexen und anfälligen Systeme braucht. Exemplarisch habe ich das hier mal skizziert: [LDAPS in einer Windows-Domäne ohne PKI | faq-o-matic.net] https://www.faq-o-matic.net/2024/06/18/ldaps-in-einer-windows-domne-ohne-pki/ Gruß, Nils PS. PKI ist böse. Hmm. Ok. Genau für das habe ich ja bereits von meinem RZ (LDAPS wegen Exchange-Anbindung), Root-CA des RZ in den vertrauenswürdigen Stammzertifizierungsstellen sowie Zertifikate für die DC's jeweils in "Eigene Zertifikate". Ich bin aber ehrlich gesagt gerade zu b***d zu verstehen, wie mir das bei Mitgliedsservern oder dem Workgroup-Cluster weiterhelfen kann...? Zitieren
NilsK 3.025 Geschrieben vor 2 Stunden Melden Geschrieben vor 2 Stunden Moin, dafür müssten wir jetzt sehr weit ausholen, um die Zertifikats-Basics zu diskutieren, fürchte ich. Wäre vielleicht etwas viel für ein Forum. In aller Kürze: statt eine CA einzurichten, erzeugst du auf "irgendeinem" System mit einem lokalen Tool dein Root-Zertifikat. Mit diesem Root-Zertifikat stellst du mit demselben Tool das gewünschte Server-Zertifikat aus. Das Root-Zertifikat importierst du in die "Vertrauenswürdigen Zertifizierungsstellen" auf den beteiligten Systemen. Das Server-Zertifikat bindest du in den Dienst ein, der es nutzen soll. Da du ja nur Zertifikate brauchst und keine PKI, ist das für "kleine" Zwecke erheblich einfacher und sicherer. Gruß, Nils 1 Zitieren
testperson 1.827 Geschrieben vor 1 Stunde Melden Geschrieben vor 1 Stunde Du musst dich doch nur selber um Zertifikate kümmern, sofern du anstelle per NTLM halt zertifikatsbasiert authentifizieren möchtest. Theoretisch sollte "bald" aber auch IAKerb / LocalKDC kommen, um auch lokal Kerberos zu können. Da die Nodes (im WG) Cluster so oder so in einem eigenen Management VLAN hängen (sollten), sollte NTLM "kein Drama" sein. vor 56 Minuten schrieb Marco31: Gibt ja jetzt genug für und wieder, muss nur noch sehen welche "Probleme" ich lösen kann und mit welchen Einschränkungen ich leben kann/will. Das scheint mir aber genau der richtige Weg zu sein. Zitieren
NorbertFe 2.266 Geschrieben vor 1 Stunde Melden Geschrieben vor 1 Stunde vor einer Stunde schrieb Marco31: LDAPS wegen Exchange-Anbindung Exchange funktioniert problemlos ohne Zertifikate auf den dcs. Zitieren
Marco31 37 Geschrieben vor 1 Stunde Autor Melden Geschrieben vor 1 Stunde Gerade eben schrieb NorbertFe: Exchange funktioniert problemlos ohne Zertifikate auf den dcs. Da hast du ohne Frage Recht, ich kann nur sagen dass es vom RZ so eingerichtet wurde Die werden ihre Gründe haben. Zitieren
NorbertFe 2.266 Geschrieben vor 1 Stunde Melden Geschrieben vor 1 Stunde Mag sein, nur ist der Exchange nicht der Grund für das Zertifikat auf dem dc. Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.