NilsK

Moin, Ja, die Anforderung als solche ist nachvollziehbar und auch nicht exotisch. Die Umsetzung ist aber, wie wir ja schon andeuteten, falsch. Das sollte man korrigieren. Wird auch nicht wild sein, aber man sollte es jetzt schon koordiniert tun. Gruß, Nils

Moin, was Jan sagt. Aber schon mal vorab als Einschätzung: So, wie ihr das gemacht habt, geht das nicht. Gruß, Nils

Moin, das bewirkt zweierlei: Fragt man den Computer nach seinem Hostnamen, dann gibt er sich als Teil der Domäne aus, die durch das Präfix angegeben wird. Und versucht der Computer selbst eine DNS-Namensauflösung, dann fragt er zuerst nach der Präfix-Domäne. Was ist denn der Grund für deine Frage? Gruß, Nils

Moin, Aber du brauchst doch kein Okta, um für 50-100 User OwnCloud bereitzustellen. Gruß, Nils

Moin, du hast dir angesehen, was allein die External Connector License kostet? Ansonsten das, was Norbert sagt. Gruß, Nils

Moin, Der zu lizenzierende Dienst läuft ja auf dem Windows Server, also bräuchtest du einen Connector. Wäre es nicht evtl. schlauer und effizienter, die User in einem Verzeichnis zu verwalten, das auch unter Linux läuft? Gruß, Nils

Moin, Prima, danke für die Rückmeldung. Dann viel Erfolg. Gruß, Nils

Moin, Ein DC ist ein DC und kein Witness. Er hält also auch kein Share. Punkt. Die Abhängigkeit mag gering und leicht aufzulösen sein, aber sie ist ja vorhanden. Schöne Grüße an den Dienstleister, aber auch so ein Share läuft auf einem DC nicht mal eben mit. Welcher eurer DCs jetzt wie lange aus ist, ist der Teil, den ich hier eben nicht einschätzen oder prüfen kann. Vielleicht muss man die Maschinen auch nicht neu machen, wenn weniger Zeit verstrichen ist. Das musst ihr dann selbst prüfen und entscheiden. Ist von der prinzipiellen Seite noch was unklar? Gruß, Nils

Moin, Einen DC zum Witness zu machen, ist ein schwerwiegender Designfehler. Das führt, ohne es weiter analysiert zu haben, dazu, dass du den Cluster so, wie er eingerichtet ist, nicht mehr in Betrieb nehmen kannst. Ohne nähere Analyse müssen wir davon ausgehen, dass alle DCs an den entfernten Standort veraltet sind und nicht mehr online gehen dürfen. Das gilt dann auch für den Witness. Für den Cluster musst du also wenigstens den Witness neu einrichten, dann nicht auf einem DC. Die Tombstone Lifetime betrifft nur DCs, keine anderen Mitglieder der Domäne. Gruß, Nils

Moin, Der geschieht zu großen Teilen automatisch. Aber ja, die Reste muss man noch selbst entsorgen. Also +1. Gruß, Nils

Moin, gut, dass du fragst. Den DC auf dem "entfernten" Cluster erst mal nicht in Betrieb nehmen. Den Cluster selbst würde ich erst dann einschalten, wenn am 2. Standort Netzwerkkontakt zum Zentralstandort besteht und das Routing auch funktioniert. Dann sollten die Anmeldevorgänge funktionieren. Wie lang die Tombstone Lifetime in eurer Domäne ist, musst du nachsehen, das können 60 oder 180 Tage sein (oder ein ganz anderer Wert, aber das wäre unwahrscheinlich). Nachsehen kannst du mit diesem PS-Kommando: (get-adobject "cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=<domain>,DC=<tld>" -properties "tombstonelifetime").tombstonelifetime Den Domänennamen musst du natürlich anpassen. Falls der betreffende DC schon länger aus ist als die Tombstone Lifetime in Tagen, schaltest du ihn nicht an, sondern löschst die VM sowie das Computerobjekt in Active Directory. Dann richtest du einen neuen DC ein. Das ist in dem Fall am einfachsten. Gruß, Nils

Moin, vielen Dank für die Rückmeldung. Gruß, Nils

Moin, der springende Punkt ist, dass "VPN" häufig mit "sicher" gleichgesetzt wird, diese Gleichsetzung aber falsch ist. "Sicher" ist nur der Kommunikationskanal selbst, denn der ist verschlüsselt. Das ist aber heutzutage schon eher uninteressant, weil verschlüsselte Verbindungen (anders als vor 25 Jahren, als es mit dem Thema VPN losging) heute üblich sind. Relevant ist aber ein anderer Aspekt, und der führt dazu, dass viele VPN-Nutzungen eher das Gegenteil von "sicher" sind. VPN legt einen Zugang in das Netzwerk, logisch betrachtet identisch mit einem Netzwerkkabel. Gewähre ich beliebigen Geräten Zugang zum Netzwerk, dann ist zwar vielleicht der Zugang "privat", aber das Netz selbst nicht mehr. Ich erzeuge damit also ein hohes Risiko, denn ich lasse Geräte zu, über die ich nichts weiß und über die ich weder technisch noch rechtlich Kontrolle und Hoheit habe. Daher ist es ein No-Go, per VPN beliebige Geräte einzulassen. Schon deshalb, weil man damit den Schlüssel für den Zugang an ein nicht kontrollierbares Gerät abgibt, von wo aus er dann ebenso beliebig weitergegeben werden kann. Es gibt Sicherheitsberater, die die Existenz von VPN-Zugängen per se als hohes Sicherheitsrisiko einstufen. Gruß, Nils

Moin, soweit war der TO im ersten Post doch schon, oder? Die Frage scheint doch eher zu sein, ob Windows 11 seit 23H1 Kerberos erzwingt. Gruß, Nils

Moin, grundsätzlich: Das ist eine sehr kleine Umgebung. Das ist völlig okay und soll nicht abfällig klingen. Aber behalte das eben im Hinterkopf, wenn du Know-how aufbaust. Viel von dem, was du liest, orientiert sich an großen oder sehr großen Umgebungen, und dadurch sind viele "Optimierungen" und scheinbare "Best Practices" für kleine Umgebungen oft übertrieben. Das gilt z.B. fast immer für die "Performance" bei Live Migration: Klar ist es toll, wenn auch riesige VMs in Sekundenbruchteilen von Host zu Host wechseln, aber wann braucht man das wirklich? Der Einordnung von @mwiederkehr schließe ich mich an. Damit solltest du eine gute Basis haben. Ach, und: ein dediziertes "VM-Netz" gibt es in Hyper-V nicht. Jede VM hat ihren eigenen vNIC, die bilden dann sozusagen alle zusammen das VM-Netzwerk. Ein vSwitch in Hyper-V hat immer so viele Ports, wie es tatsächlich vNICs gibt, die mit ihm verbunden sind. Mehr Logik ist da nicht drin. (Finden viele nicht gut, ist aber so und stört auch nur selten.) Gruß, Nils

Moin, es fehlt die entscheidende Angabe, wie viele physische NICs die Hosts denn haben. Und natürlich ist auch wichtig, wie hoch denn die Last auf den Systemen sein wird, also am Ende, wie viele VMs in welchem Sizing dort laufen. Die generelle Antwort ist "kommt drauf an", und worauf es ankommt, hängt insbesondere an den beiden genannten Faktoren. Eine 2-Node-Umgebung ist ja sehr klein, aber das muss erst mal nix heißen. Von "bei dem Szenario egal, mach einfach irgendwas" bis hin zu "nimm x mit viel y und schalte z ab" ist alles drin. Gruß, Nils

Moin, Ja, Vorschläge dieser Art gibt es ja auch immer mal wieder. Die setzen aber natürlich auch einiges an Infrastruktur voraus, damit man nicht einfach mit 150 Dollar und einer Briefkastenfirma das System für sich ausnutzt. Erschütternder finde ich den anderen Punkt, auf den du hinweist. Es ist ja durchaus wahrscheinlich, dass an anderen Komponenten und Entwicklern auch solche Leute dran sind, die nur darauf warten, dass sie ihr unbemerktes Tun in etwas umsetzen können, was ihnen nutzt. Gruß, Nils

Moin, ja, auf heise.de gibt es eine ganz gute Übersicht der bisherigen Erkenntnisse. Sieht schon ziemlich "state-sponsored" aus bei dem Aufwand. Gruß, Nils

Moin, es ist ja auch aufgefallen, aber eben erst hinterher. Vermutlich nicht so wild wie damals bei Heartbleed, aber schon eine harte Nummer. Am Ende ist der Punkt, dass moderne Software so komplex ist, dass man solche Angriffe gar nicht wirksam verhindern kann. Weder durch Closed noch durch Open Source. Mir schwant, dass das "mit KI" nicht besser wird, aber das würde dann jetzt wohl den Stammtisch eröffnen (hicks). Gruß, Nils

Moin, es klingt wie "ätsch", aber bei solchen Meldungen stelle ich immer wieder fest, wie wenig das typische Open-Source-Argument zutrifft, dass der offene Entwicklungsprozess ja automatisch für Sicherheit sorge, weil niemand unbemerkt eine Beckdorf einschleusen könne. Abgesehen davon - schätze ich es richtig ein, dass das nur Linux betrifft? Gruß, Nils PS. ich lasse die Autokorrektur Mai gewähren.

Moin, für ein "Zweitangebot" würde ich mich ohnehin nicht hergeben. Der 365-Teil ist trivial, die "Datenübernahme" ist trivial, wenn man sie schlecht macht, und aufwändig, wenn sie sinnvoll sein soll. Ehemals lokal selbst betriebene Anwendungen in VMs in der Cloud zu übertragen, ist in erster Linie teuer. Entweder lokal weiter betreiben oder durch SaaS ersetzen. Wenn man als Dienstleister sich damit nicht auskennt, dann verbrennt man sich die Finger dran. Das Know-how aufzubauen, ist machbar, aber das sollte man nicht mit einem Kunden machen, mit dem man gegenseitig gar nicht mehr arbeiten will. Gruß, Nils

Moin, Maßeinheit ist eigentlich nicht ganz richtig, es war eher ein Bezugspunkt, so wie "Normalnull". Ein Witz konnte über oder unter Kaczenski sein, wobei "unter" sehr selten vorkam. Gruß, Nils

Moin, zwei DCs ist Minimum, mehr nur bei Bedarf. Das ist primär eine Frage des Gesamtdesigns. In mittelständischen Umgebungen ist das normalerweise keine Ressourcenfrage. Gruß, Nils

Moin, früher an der Uni gab es eine Maßeinheit für die Flachheit von Witzen. Sie hieß "Kaczenski". Gruß, Nils

Moin, oh, da befürchte ich rechtliche Probleme ... Gruß, Nils