NilsK

Moin, du hast eine Vorlage angelegt, aber sie nicht veröffentlicht. Das ist im GUI leider getrennt. Du musst im GUI der CA (nicht in der Vorlagen-MMC) per Rechtsklick auf "Zertifikatsvorlagen" deine neu erzeugte Vorlage ausdrücklich hinzufügen. Gruß, Nils

Moin, als Dummfug. Da hat jemand das Konzept von Cores und Hyperthreading nur halb verstanden und etwas aufgeschrieben, was technisch kompetent klingen soll, bei näherem Hinsehen aber eben das Gegenteil offenbart. Eine dauerhafte Auslastung von 50 Prozent ist auch auf einem Host selten zu beobachten. Und wenn doch, dann wäre zunächst zu fragen, was denn da eigentlich gemessen wird. Das ist auf allen Plattformen nämlich eine Frage, die nicht trivial ist und leider oft zu Fehleinschätzungen führt. HT und Multithreading sind erheblich komplexer als es zunächst scheint. Generell bleibt, dass CPU höchst selten das Problem ist. Die klemmenden Dinge liegen fast immer woanders. Gruß, Nils

Moin, kommt drauf an. Sprichst du von einem RDS-Host (auch "Terminalserver" genannt)? Dann braucht es weiter den Lizenzserver. Bei (fast) allen anderen MS-Produkten muss man nur "zählen" und die Lizenznachweise vorlegen können. Gruß, Nils

Moin, ja, weiß ich. In Workshops diskutiere ich das auch immer sehr ausführlich. An dieser Stelle hätte es aber in der Darstellung abgelenkt. Wie du schon richtig sagst, gibt es für solche Aussagen fast nie einen technischen Grund, sondern es geht immer nur darum, dass der Softwarehersteller sich Diskussionen über Performance ersparen will. Ein anderes Beispiel wäre Exchange - als eins der wenigen MS-Produkte gibt es dafür auch so eine Aussage (maximal 2:1), dort aber noch eins schärfer mit Supportausschluss. Ist in der Praxis aber auch kein Problem - dann verschiebt man im Supportfall eben andere VMs, bis das Verhältnis passt und man den Supportcall abwickeln kann. Gruß, Nils

Moin, komischerweise nehmen die Missverständnisse über die CPU-Belastung durch Virtualisierung deutlich zu, seit die CPUs mit Kernen nur noch so um sich werfen. Daher hier noch mal ausdrücklich: Es ist generell überhaupt kein Problem, die CPU eines Virtualisierungs-Hosts zu überbuchen. Ganz im Gegenteil: Genau dafür ist Virtualisierung da. Eine CPU kümmert sich nie nur um eine Aufgabe, sondern schaltet ständig zwischen Aufgaben hin und her. Ob es sich dabei um verschiedene Programme innerhalb eines Betriebssystems handelt oder um verschiedene Programme innerhalb mehrerer Betriebssysteme, ist der CPU am Ende egal. "Gängige" Anwendungen lasten eine CPU (oder auch einen Kern) niemals auch nur ansatzweise aus. Dadurch ist die CPU statistisch gesehen fast immer im Leerlauf. In der Praxis ist eine CPU-Überbuchung von 10:1 fast nie ein Problem. Auch eine Überbuchung von 20:1 kann durchaus funktionieren. Heißt: Ein Beispiel-Host habe 8 Cores, dort laufen 40 "gemischte" VMs, die jeweils 2 Cores haben (Verhältnis 10:1). Mit großer Wahrscheinlichkeit wird die CPU nicht der Engpass sein. (Wahrscheinlich wird man vorher feststellen, dass das RAM nicht reicht.) Wenn die VMs (einzelne oder alle) wirklich höhere Anforderungen stellen (Terminalserver, stark belastete Datenbankserver usw.), kann mehr Designaufwand erforderlich sein. Selbst dann ist in den meisten Fällen aber noch eine CPU-Überbuchung möglich. Ein 1:1-Verhältnis zwischen physischem Core und VM-CPU ist technisch praktisch nie erforderlich. Gruß, Nils

Moin, Am einfachsten ist es, keine neue Domäne aufzubauen, sondern die bestehende zu aktualisieren. Sonst werden die Profile nicht das letzte Problem sein. Gruß, Nils

Moin, in dem Fall braucht man ja nur exakt ein Zertifikat für das Code Signing. Da könnte in so einer Umgebung ein selbstsigniertes durchaus interessant sein. Definiert man eine längere Laufzeit, kann man auf das Timestamping verzichten. Möchte man hingegen Timestamping, um von der Laufzeit des Zertifikats dauerhaft unabhängig zu sein, ist ein kommerzielles Zertifikat tatsächlich besser - kostet dann aber auch etwas. Gruß, Nils

Moin, ach, schau an, das war mir gar nicht bewusst. Ich dachte, es ginge hier (wie meistens) nur um die TLS-Verbindung. Das trifft in kleineren Umgebungen ja ohnehin oft zu, daher die Frage nach dem Einsatzzweck. Gruß, Nils

Moin, dann findest du alles Nötige in dem Video. Beachte, dass du eine Eingabe- und Bearbeitungsmöglichkeit selbst zur Verfügung stellen musst, das neue Feld taucht in den AD-Tools nicht auf. Gruß, Nils

Moin, "mit einem AD-Account befüllt" ist eben nicht so einfach. Was meinst du damit? Den Anmeldenamen? Den DN? Was du dort sinnvoll reinschreibst, hängt davon ab, was mit dem Wert dann gemacht werden soll. Ein vorhandenes Feld kann man nicht "klonen". Solche organisatorischen Daten sind in einem HR-System besser aufgehoben als im AD. Siehe in diesem Video ab Minute 25:20: [Video: Active Directory als Datenspeicher? | faq-o-matic.net] https://www.faq-o-matic.net/2011/02/09/video-active-directory-als-datenspeicher/ In dem Video siehst du auch, wie man eine Schemaerweiterung technisch durchführt. Gruß, Nils PS. meine Güte - nach über acht Jahren (Alter des Videos) sieht fast alles anders aus. Windows, ich, selbst die Wand im Hintergrund ...

Moin, ich würde solche Dinge nicht im AD-Schema realisieren, weil sie mit dem AD als Netzwerkverwaltung nichts zu tun haben. Wenn es doch sein muss, kann man das tun, und wenn man es richtig macht, ist es auch "sicher". Prüfe aber, welche Daten du wie ablegen willst - was soll genau in dem Feld stehen? Der DN? Und: Das vorhandene Feld "Vorgesetzter" ist deutlich komplexer, weil es auch ein zugehöriges Backlink-Attribut hat. Das wirst du vermutlich aber so gar nicht brauchen. [AD-Schema | faq-o-matic.net] https://www.faq-o-matic.net/kategorien/active-directory/ad-schema/ Gruß, Nils

Moin, ja, dafür kann ein internes Zertifikat interessant sein. Wenn es nur solche einfachen Zwecke (einzelne interne TLS-Zertifikate) in einer kleinen Umgebung sind, dann reicht eine einstufige PKI meist aus. Die würde ich dann direkt als Enterprise-CA in die Domäne installieren. Sollte sich später Bedarf an anderen Zwecken auftun (insbesondere Verschlüsselung zur Datenablage), dann kann man eine zweistufige PKI auch nachträglich neu einrichten. Gruß, Nils

Moin, und warum baust du einen neuen Forest? Das erfordert dann ja eine aufwändige Migration. Was ist der Grund dafür? Wofür du interne Zertifikate brauchen könntest, musst du schon selbst beantworten. Für Exchange brauchst du sie nicht. Falls es keinen Einsatzzweck gibt, lass die PKI weg. Die kann man bei Bedarf auch später einrichten, denn man sollte schon wissen, was man damit will, damit man das passende Design festlegen kann. Gruß, Nils

Moin wie würdest du denn von außen per Web Access zugreifen, wenn nicht über Port 80? Ein Port ist ja nicht automatisch eine Sicherheitslücke. Die bestünde nur, wenn das, was auf dem Port lauscht, angreifbar ist. Gruß, Nils

Moin, ist das für Produktion oder als Testumgebung? Wofür würdest du denn Zertifikate nutzen wollen? Und wenn du nur eine einstufige PKI hast, warum hast du die CA dann nicht in der Domäne? Gruß, Nils

Moin, das steht ja auch in dem Hilfe-Artikel von Mailstore unter "Voraussetzungen": https://help.mailstore.com/de/server/Verwendung_von_Lets_Encrypt_Zertifikaten#.C3.9Cber_Let.27s_Encrypt Ist eben die Frage, ob Mailstore auch von extern genutzt werden soll. Falls nein, ist Let's Encrypt nicht die richtige Wahl. Siehe auch meine zweite Antwort oben. Gruß, Nils

Moin, hatten wir gerade vor wenigen Tagen. Gruß, Nils

Moin, bei Umgebungen mit einer "Handvoll" Objekten wäre ja auch eine Migration kein großer Akt. Bei mehreren Händen sieht das aber schnell anders aus. Und zufällig hast du exakt die Argumente genannt, die alle Kunden an dieser Stelle bringen ... Gruß, Nils

Moin, naja, dann wird alles Nähere zur Einrichtung ja sicher in der Doku des Herstellers stehen. Wie man das konkret einbindet, ist von System zu System im Detail unterschiedlich. Ist der Mailstore-Server denn vom Internet aus erreichbar? Nur dann kannst du mit Let's Encrypt sinnvoll arbeiten. Falls er nur intern erreichbar ist, nutze ein selbstsigniertes Zertifikat oder eins von einer internen PKI. Gruß, Nils

Moin, ein TLS-Zertifikat hat mit einer IP-Adresse nichts zu tun. Es soll ja bestätigen, dass der DNS-Name der richtige ist. Let's Encrypt ist ein vollautomatisiertes Verfahren für TLS-Zertifikate. Unterstützt Mailstore das denn? Wenn nicht, wirst du das nicht nutzen können, jedenfalls nicht ohne größeren Entwicklungsaufwand. Gruß, Nils

Moin, du willst deinem Browser nicht sagen, dass er ungültige Zertifikate ignorieren soll. Gruß, Nils

Moin, Mit "Surfen im Netz" meinst du jetzt nur die Website von dem Tool? Welche Details nennt denn die Fehlermeldung im Browser? Gruß, Nils

Moin, richtig gut sind erst erwartete Mails. Da biste nahezu machtlos. [Phished! - michael wessel Blog] https://www.michael-wessel.de/blog/2019/07/09/phished/ Gruß, Nils

Moin, korrekt. Die Unterscheidung zwischen Rolle und Berechtigungsgruppe lässt sich am besten umsetzen, wenn man zwei verschiedene Gruppentypen hat - eben die Globalen und die Domänenlokalen Gruppen. Dadurch wird die grundlegende logische Trennung noch deutlicher, als wenn man nur eine Namenskonvention nutzen würde (die man natürlich auch braucht). Ein weiterer Grund für die verschiedenen Gruppentypen: Domänenlokale Gruppen sollen explizit nur die Berechtigungen auf Ressourcen in der eigenen Domäne umfassen (also in dem Sicherheitsbereich, den man verwaltet). Daher können sie nur bei Ressourcen der eigenen Domäne eingesetzt werden. Globale Gruppen hingegen sollen absichtlich in anderen Domänen sichtbar sein, falls es mehrere gibt, weil sie organisatorische Zwecke erfüllen. Gruß, Nils

Moin, ich würde halt kein HCI empfehlen. Unterhalb einer bestimmten - ziemlich großen! - Größenordnung ergibt das schlicht keinen Sinn. Man halte sich vor Augen, dass "Hyperscale" das Vorbild war - die ganz großen Web-Rechenzentren. Nicht die mittelständische Umgebung mit einstelliger Host-Anzahl. Gruß, Nils