NilsK

Moin, ja, auch in dem Fall ist das Käse. Bereiche innerhalb eines Subnets anhand von Regeln auf MAC-Basis unterscheiden ... da rollen sich mir die Fußnägel hoch. Zumal du am Ende nichts davon hast. Ich bin kein Netzwerker, aber Telefone würde ich immer in ein anderes VLAN/Subnetz stecken. Das ist ja ein ganz anderer Typ Traffic mit ganz anderen Anforderungen. Ach so, und eine Subnet Mask mit ...254 halte ich auch für Käse. Gruß, Nils

Moin, abgesehen davon, dass DHCP-Bedingungen in aller Regel Käse sind und mehr Probleme schaffen als lösen: Das Herstellerpräfix ist ganz sicher nicht 00014, sondern das nächste Zeichen ist auch noch relevant. https://de.adminsub.net/mac-address-finder/00014 Gruß, Nils

Moin, öffentlich kann ich keine Empfehlungen aussprechen. Gruß, Nils

Moin, öh - es ist nicht ganz nachzuvollziehen, was du wann wo wie gemacht hast. Da das in einem Forum nicht so gut zu klären ist, wäre es evtl. sinnvoll, dir jemanden ins Haus zu holen, der sich mit dem Thema auskennt. Vermutlich muss gar nicht viel gemacht werden, aber per Forendiskussion bleiben zu viele Wenns und Abers offen. Gruß, Nils

Moin, dass die alte bzw. frühere PKI ein Problem ist, glaube ich nicht. Starte mal pkiview.msc - was taucht dort auf? Die "frühere" sollte nicht drin sein. Ich bin mit den Details der EFS-Steuerung mit PKI leider nicht vertraut, weil das höchst selten nachgefragt wird. Das heißt nicht, dass es nicht interessant sei, aber ich kann aus Erfahrung nichts beitragen. Ich schau mal ins PKI-Buch, ob ich da was finde. Edit: Nein, leider merkt das Buch zu diesem Punkt auch nichts an. Allerdings steht dort, dass das vordefinierte "Basis-EFS" eine Version-1-Vorlage ist, für die es gar kein Autoenroll gibt. Dieser Punkt ist dann offenkundig nicht relevant. Mangels passender Laborumgebung kann ich grad nix weiter tun. Gruß, Nils

Moin, die Verschlüsselung als solche ist in beiden Fällen gleich sicher und gilt als gut. Die Frage ist, wie der Schlüssel geschützt ist. Das TPM soll den Schlüssel an die lokale Maschine koppeln, sodass man die Disk nicht in einem anderen Rechner lesen kann. Man kann den Key auch auf USB speichern, dann hängt die Sicherheit an dem Stick. Dafür gibt es auch Szenarien - kommt halt auf die Anforderungen an. Gruß, Nils

Moin, ich weiß nicht genau, was der GP-Editor an dieser Stelle macht. Vielleicht listet er nur die Vorlagen auf, die für Autoenroll berechtigt sind - ist das gegeben? Gruß, Nils

Moin, okay, das hatte ich anders verstanden. In dem Fall sind die Berechtigungen auf der Vorlage der nächste Verdächtige. Das ist wiederum in der Vorlagen-MMC zu steuern. Gruß, Nils

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