NilsK

Moin,

Vermutlich weil da die 13 dabei ist.

Gruß, Nils

... so wie in Hotels und bei der Bahn.

Moin,

es klingt so, als erwartest du eine Art Zertifikats-Download bei Bedarf. So verstehe ich die Mimik aber nicht. Wenn man Windows lässt, wie es will, dann installiert und aktualisiert es einen großen Schwung von Zertifikaten, mit denen ein großer Schwung von Diensten funktioniert. Das ist mehr oder weniger zeitgesteuert, Updates gibt es dann, wenn welche vorliegen. Die Auswahl der so verteilten Zertifikate liegt bei Microsoft und wird sicher auf Verträgen mit deren Anbietern beruhen.

Willst du das so nicht, dann musst du eben selbst eingreifen und den Aufwand in Kauf nehmen, den das bedeutet. Da kann es dann eben vorkommen, dass du das im Einzelfall nachsteuern musst. Hier wird die Annahme sein, dass der Einzelfall bei einem konkreten System eben ein Einzelfall ist, weil man da dann ja auch nicht so viele Services braucht.

Das ist jetzt aber nur mein Verständnis ohne weitere Recherche. Um Details habe ich mich da mangels Bedarf noch nie gekümmert.

Gruß, Nils

Moin,

und falls der ausführende Account keine ausreichenden Berechtigungen hat, aber lokaler Administrator ist, dann ist der Schalter /B bei solchen Aktionen sehr hilfreich. Dessen Erläuterung ist nicht verständlich, es geht im Kern darum, dass man sich so über fehlende Berechtigungen hinwegsetzen kann.

Gruß, Nils

Moin,

ich habe bislang nicht mit Umgebungen zu tun gehabt, in denen sowas ein Thema war. Aber weiter unten in dem von Norbert empfohlenen Link steht ja ein Verfahren, in dem man die Root-Zertifikate von einem Client (der ins Internet darf und so die CTLs aktualisiert) exportiert, um sie komplett oder teilweise einem Rechner zur Verfügung zu stellen, der das nicht im Internet aktualisieren darf.  Schon probiert?

Der gravierende Nachteil von 1. scheint mir im Moment ja zu sein, dass du es nicht zum Laufen bekommst.

Gruß, Nils

Moin,

es spricht einiges dafür, dass du die Planung - dem Vorschlag von Jan @testperson folgend - in Ruhe vornimmst und dabei ein, zwei Schritte in die Zukunft denkst. Jetzt ad hoc per Subnetting ein paar Adressen im Range hinzuzufügen, schafft kurzfristig evtl. Erleichterung, sorgt aber auch für mehr Komplexität, ohne dass es für die Zukunft irgendwie flexibler oder skalierbarer wird.

Gruß, Nils

Moin,

in der OpenScape-Doku, die ich auf die Schnelle gefunden habe, wird auch eine direkte Ankopplung an Active Directory beschrieben. Wenn ihr ohnehin nur intern zugreift, wäre das vermutlich weit einfacher und weniger fehlerträchtig als die Anbindung per ADFS/SAML.

Gruß, Nils

Moin,

was Norbert sagt.

/22 wäre ebenso "krumm". Man rechnet nicht unbedingt damit, übersieht es und läuft in Fehler.

EDIT: Jetzt verstehe ich das Missverständnis, das ich erzeugt habe. Mit "ungerade" meinte ich oben nicht "nicht durch 2 teilbar", sondern "krumm" in dem Sinne, den Norbert gerade beschrieben hat. Leider kann ich den obigen Beitrag jetzt nicht mehr bearbeiten, sonst würde ich das Wort ändern.

Gruß, Nils

Moin,

an sowas denke ich dabei auch. @druckerheini, versuch mal

dir /X

Hilft das Ergebnis, die Sache aufzuklären?

Gruß, Nils

Moin,

aber sowas sollte einem der Lieferant durchaus beantworten können. Wenn nicht, dann eskalieren. Wenn dann immer noch nicht ... gibt es mehr als den einen. Sowas muss nun wirklich nicht der Kunde rausfinden, das ist ja keine technische Designfrage.

Gruß, Nils

Moin,

vor 2 Stunden schrieb daabm:

 

Nö. Ne Netzmaske ist ne Netzmaske, völlig egal wie lang sie ist. Komm gern mal nen Tag bei uns vorbei, dann zeige ich Dir unsere Netze

komm du mal nen Tag in die Netzwerke, die ich bei Kunden antreffe.

Gruß, Nils

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,

vor 17 Stunden schrieb NorbertFe:

Was hat eigentlich DHCP mit Zugangsdaten von Geräten zu tun?

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,

vor 9 Minuten schrieb mwiederkehr:

Und bei Admin-Accounts sollte man darauf vertrauen können, dass die Admins selbst ein genug sicheres Passwort verwenden.

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