NilsK

Moin, zu der internen PKI: ja, kann man machen - wenn man weiß, wie es geht. Die Aussage, dass die Zertifikate "nicht mit allen Browsern laufen", macht mich skeptisch, ob das der Fall ist. Und: Wenn der Punkt dann kommt, an dem man doch einen Dienst "von außen" zugänglich machen will, dann wird es lustig, wenn man nachträglich das Zertifikat und die Infrastruktur anpassen muss. Daher empfehle ich dringend, zumindest diesen Teil gleich richtig zu machen. Wir reden hier von 150 Euro oder sowas. Gruß, Nils

Moin, oder um es deutlicher zu machen: Für diese Änderung brauchst du keine Zugangsdaten zu den Endgeräten. Bei denen musst du ja nichts umkonfigurieren. Es ist übrigens keine gute Idee, im selben Netzerksegment für längere Zeit mit unterschiedlichen Subnetzmasken zu arbeiten. Sowas sollte man nur so lange tun, wie man zur zügigen Umstellung braucht. Routingfehler, die aus sowas resultieren, können sehr lästig sein. Das mag jetzt im konkreten Fall vielleicht nicht auftreten, aber mach dich künftig lieber schlau, bevor du solche Änderungen wirksam machst. "Ungerade" Subnets sind in der Praxis immer schwierig. Statt jetzt mit einer 23er-Maske zu hantieren, würde ich prüfen, ob ein Umstieg auf /16 nicht sinnvoller wäre, dann vielleicht gleich mit einem 172.16.-Range (den man in solchen Fällen üblicherweise nimmt). Ich prophezeihe, dass sonst der nächste, der in dem /23-Netz was troubleshooten muss, auf die "ungerade" Maske reinfallen wird ... Gruß, Nils

Moin, um es kurz zu machen: Dein Dienstleister hat (wenn es zutrifft, was du hier angibst) weder von PKI noch von ADFS ausreichend Ahnung. Binde ihn da nicht ein, sondern such dir für diese Themen jemand anderen. Das ist alles kein Hexenwerk, wenn man sich auskennt - aber leider befassen sich wenige so weit damit, dass sie sich auskennen. Und dann funktioniert es nicht, nicht sicher oder nicht zuverlässig. Im Fall von ADFS wäre dann "funktioniert nicht" die wahrscheinlichste Variante, im Fall der PKI ist "nicht sicher" am häufigsten. (Ich habe auch eine Vermutung, in welche Kategorie eure vorhandene PKI fällt ...) ADFS betreibt man produktiv nicht mit internen TLS-Zertifikaten, sondern mit "gekauften". Auch Let's Encrypt würde ich für den Zweck nicht nutzen - wenn man es hinbekäme (weiß ich nicht, hab ich dafür noch nie in Erwägung gezogen), wäre es vermutlich viel Aufwand und viel Fehlerquelle. Gruß, Nils

Moin, ihr redet hier wunderbar aneinander vorbei. Der Kunde hat eine Standalone-Lizenz von Office 2019. Deshalb braucht er die Office-365-Apps nicht, sondern nur die Online-Funktion. Also reicht "Basic" aus. OneNote ist in Office 2019 enthalten. OneDrive ist Teil des Betriebssystems. Bleibt noch Teams, aber meines Wissens erfordert der Desktop-Client keine separate Lizenz. Also, @Dukel, sofern dir die Sicherheitsfunktionen von O365 Basic ausreichen, bist du damit passend versorgt. Schau dir vor diesem Hintergrund die verlinkte Produktseite noch mal an, die finde ich eigentlich wirklich aussagekräftig. Gruß, Nils

Moin, indem man recherchiert und prüft und genügend Zeit investiert, damit das nicht Wochen oder Monate dauert. Oder indem man jemanden beauftragt, dem man zutraut, dass er das mit ausreichend geringem Aufwand findet. Wird dich jetzt aber eigentlich nicht überraschen, oder? Gruß, Nils

Moin, was liest du denn da Unterschiedliches? Ich finde die Produktvergleichsseite (siehe Hinweis von winmadness) ziemlich eindeutig. Was ist dir denn da konkret unklar? Gruß, Nils

Moin, weil es Fehlkonfigurationen gibt, die vor einem Update nicht auffallen. Es kommt immer mal wieder vor, dass ein Update etwas "geradezieht" und dadurch Konfigurationen scheinbar "kaputtmacht", die vorher eigentlich auch schon nicht hätten funktionieren dürfen. Gruß, Nils

Moin, dein Kostenvergleich ist für sich schon nachvollziehbar. Aber schau dir mal die absoluten Zahlen an. Das sind doch Kosten, die nicht ernsthaft ins Gewicht fallen. Vor allem würde ich dir aber raten, bei deiner Betrachtung den laufenden Aufwand und das Risiko zu berücksichtigen, das du selbst trägst, wenn du die Dinge selbst machst. Wir reden hier über komplexe und pflegeintensive Systeme. Insbesondere Exchange ist wirklich nicht ohne. Da darf man nicht vordergründig die Lizenzkosten vergleichen. Ein guter eingekaufter Dienst entlastet vor allem vom Eigenbetrieb und vom eigenen Risiko. Gruß, Nils

Moin, Für fünf User würde ich nie eine solche Umgebung aufbauen. Dazu haben die anderen schon alles Wichtige gesagt. Die Lizenzen kannst du verkaufen. Gruß, Nils

Moin, das ist doch an der Stelle egal. Der Traffic verlässt den Host nicht, sondern geht nur durch den VMBus. Das war das, was ich meinte. Gruß, Nils

Moin, was meinst du damit? Gruß, Nils

Moin, das lässt sich sogar recht einfach herstellen: Man erzeuge ein Password Settings Object, verknüpfe dies mit allen Admin-Gruppen und fordere dort ein langes Kennwort ein. Size matters. Gruß, Nils

Moin, zunächst einmal prüft das Skript nicht die Kennwörter im AD. Das kann es auch gar nicht, denn die Kennwörter sind dort gar nicht gespeichert, nur deren Hashes. Das Skript schaut, ob die Accounts in "Breaches" aufgetaucht sind. Wie wahrscheinlich das bei internen AD-Accounts ist, mag man sich selbst zusammenreimen. Die Kennwörter aus der Liste werden herangezogen, wenn ein User sich ein neues Kennwort gibt. Das ist die klassische "Filter"-Funktion. Ich bin grundsätzlich ein Freund von sowas, aber hauptsächlich dann, wenn Standard- und Lulli-Kennwörter vermieden werden sollen. Ob man dazu diese Liste braucht ... man muss sich dabei auch vor Augen führen, dass die übliche Reaktion bei der Zurückweisung eines Kennworts darin besteht, einzelne Zeichen anzuhängen. Die Sicherheit erhöht sich dadurch nicht. Wie vertrauenswürdig das angesprochene Tool ist, weiß ich nicht. Man kann sowas machen, sollte sich aber auch nicht zu viel davon versprechen. Dasselbe gilt für Troy Hunts ganzes "Haveibeenpwned"-Projekt - das ist eher ein Awareness-Tool als eine Hilfe. Die konkreten Informationen, die man dort rausbekommt, sind typischerweise ziemlich nutzlos und oft irreführend (in nahezu allen Stichproben, die ich durchgeführt habe, ließ sich nachweisen, dass dort angeblich "gebreachte" Accounts bei dem "gehackten" Anbieter gar nicht existiert hatten). Gruß, Nils

Moin, Genauer: das ist die Geschwindigkeit, die er anzeigt. Bei internem Traffic gilt das nicht. Gruß, Nils

Moin, ich habe dazu nichts Belastbares - würde aber mal die Frage in die Runde werfen, wieviel Einfluss du bei der CPU in deinem Szenario vermutest. In den allermeisten "General-Use-Szenarien" ist die CPU nicht der Flaschenhals. Daher würde ich da nicht viel rumoptimieren und auch keine Risiken eingehen, sondern die genannten Features, falls möglich, abschalten. Gruß, Nils

Moin, wenn beide VMs auf demselben Host liegen und am selben vSwitch hängen, wird deren direkter Traffic gar nicht erst rausgeschickt, sondern läuft Hyper-V-intern über den virtuellen Switch. Ich würde da also gar nichts weiter einrichten. Wenn du das überhaupt hinbekämst, dann wäre es sehr viel Aufwand - der nichts bringt. Gruß, Nils

Moin, einigen wir uns darauf, dass wir Dritte (z.B. einen externen Anbieter) hier im Forum nicht bewerten, schon gar nicht auf Basis unvollständiger Angaben? Danke. Gruß, Nils

Moin, ja und? Wenn ihr einen eigenen Mailserver wollt, ist das ja nicht teuer, sondern günstig. Sagen wir es so: Nicht nur die Preise haben sich seit Netware ein wenig verändert, sondern auch die Bedrohungslage und die Komplexität der Technik. Gruß, Nils

Moin, das ist zumindest mal seltsam. Findet sich in den Eventlogs etwas, das damit zu tun haben könnte? Mein Schuss ins Blaue wären jetzt Treiberprobleme. Gruß, Nils

Moin, <theatralisch> von Best Practice abweichen? Wiiiiir? </theatralisch> Gruß, Nils

Moin, es geht nicht darum, die Benutzer zu überprüfen, sondern die Anmeldung mit verschiedenen Anmeldearten ... Gruß, Nils

Moin, und ergänzend: ping auf den DC-Kurznamen, nicht auf die IP-Adresse. So prüfst du beides, die Namensauflösung und die Konnektivität. Gruß, Nils

Moin, aha, so wird doch ein Schuh draus. Dann wäre als nächstes das zu prüfen, was Norbert oben schon gesagt hat: Was sagt das Eventlog, wenn die Anmeldung scheitert? Nur zur Sicherheit: Die .15 und die .9 sind beides Domänencontroller? Gruß, Nils

Moin, die Last auf einem DC wird gemeinhin dramatisch überbewertet. Sprechen wir bei dem Netzwerk von hohen vierstelligen Anwenderzahlen oder mehr? Wenn nein, dann ist die Last sehr wahrscheinlich kein Thema. Wenn ja, kann man sich das ansehen, aber das wird man dann in die Breite skalieren. Richtig andere Vorgehensweisen aufgrund der Last wären dann vielleicht im fünfstelligen Bereich zu evaluieren. Wir können jetzt hier noch weiter um den heißen Brei diskutieren. Wenn du magst, sag uns, wie die IP-Konfiguration auf dem "fehlerhaften" Client und einem "funktionierenden" ist. Dann können wir ggf. konkret was dazu sagen. Wenn du nicht magst, ist das auch okay, aber dann haben wir auf der theoretischen Ebene dazu gesagt, was dazu zu sagen ist. Gruß, Nils

Moin, und willkommen an Board. Allgemein halte ich sehr viel von der Plattform "Microsoft Learn". Da findest du auf jeden Fall einen Einstieg und kannst dann schnell selbst beurteilen, welche intensiveren Schulungen evtl. für dich interessant sein könnten. https://learn.microsoft.com/de-de/ Gruß, Nils