NorbertFe

Wärs dann nicht das einfachste, einfach die Root/Intermediate CAs von Sectigo runterzuladen und zu verteilen? Dann brauchst du doch nur noch die CRL URLs freigeben (wenn gewünscht) und alles läuft. Klingt für mich nach weniger Aufwand.

Das Zwischenzertifikat muss dir eigentlich der Webserver liefern. Das Rootzertifikat kommt aus dem Cert-Store. Aber frag mich jetzt nicht, wie das da reinkommt. Üblicherweise über obigen Weg.

Ja, so verstehe ich das auch. :)

Spätestens jetzt solltest du dann aber über Performance nachdenken. ;) Und zwar nicht nur wo die Switches hängen, sondern auch wie schnell sie angebunden sind und welche Routingperformance die Firewall bietet. Über Redundanz kann man dann ebenfalls nachdenken. Firewall aus = Netz aus.

Toll, das sagt ja genau das Gegenteil der Schulungsunterlagen :)

Na die zwischen den Netzen (wenn gewollt und benötigt) und die Default Route ins Internet (wenn benötigt). Für DHCP muss der DC gar nicht in den anderen Netzen erreichbar sein, das erledigt ja das Relay (stellvertretend). AD muss erreichbar sein, wenn die Clients sich anmelden sollen/müssen. Also ja, der DC müßte in dem Szenario erreichbar sein. Schon deswegen könnte ein Routing über die Firewall sinnvoller sein, als mit ACLs auf den Switches zu hantieren. Aber je nach Konfiguration kann beides gut umgesetzt sein. Ja genau. Woher sollen wir denn wissen, was bei deiner Präsentation besser ankommt. In der Realität wirst du beide Varianten treffen. Netzwerkleute werden jetzt mit Core-, Distribution- und Access Switches ankommen. Aber ist das für dein Szenario zielführend?

Nein! ;) Natürlich ist das möglich. Das Relay musst du aber an der jeweiligen Routinginstanz aktivieren. Dein Windows DHCP hat dann einfach für alle VLANs entsprechende DHCP Scopes. Per Routing. Aber wozu sollte man das wollen? Wir reden hier doch grad über Segmentierung. Kommt auf dein Design an.

Mit krumm war wohl eher alles außer /24 /16 und /8 gemeint. ;) Eben weil man jedesmal erst "nachrechnen" darf, welche IP Kreise dazugehören und vor allem weil es immer noch geräte gibt, die eben nur diese Masken erlauben (auch wenns inzwischen seltener wird). Und ja, wenn man weiß was man tut und keine solche Geräte hat, ist das technisch natürlich machbar.

Naja dann wirst du dich wohl mit 802.1x mal auseinandersetzen müssen. Damit kann man dann eine ankommende Verbindung authentifizieren und anhand von Kriterien einem entsprechenden VLAN zuordnen. Siehe auch obigen Link, den dir jemand gepostet hat.

Wiederspricht sich dein Gedanke nicht mit der Anforderung? Was ist jetzt eigentlich deine Frage?

Wenn es on Premises wäre, gäbs ja gar keine Frage. ;) Dann bräuchte man 3 CALs.

Ionos? Steht dein Exchange beim Provider oder wie?

Das wären dann 4 Lizenzen. Laut MS Schulungsunterlagen bedingt "Send as" auch eine Lizenz, wohingegen Shared Mailboxes (ohne Send as) keine zusätzlichen Lizenzen benötigen. Leider fand ich das aber nur in den Schulungsunterlagen damals und nirgends in den verfügbaren Lizenzinfos bei MS. Aber ich gebe zu, ich hab mich jetzt nicht besonders angestrengt. ;)

Einfach mal am Client eine gpmc installieren und benutzen.

Genau ;)

Nicht alle Vorschläge die da kommen sind sinnvoll: https://www.servolutions.de/support/articles/temporaryservererror2013.htm Ich wäre auf jeden Fall bei "Stell auf SMTP-Zustellung um" dabei. Das bedeutet aber, dass du dir Gedanken um einen vernünftigen Spamfilter machen solltest. Auf jeden Fall gewinnt man deutlich gegenüber diesen POPConnector-Krücken. Bye Norbert

Eher von 39€. Steht ja nur ein Name im Zert. Falls man keine Maschinenauth braucht. ;)

Eben, also noch viel weniger Probleme. Wobei in einer Testumgebung eher selten ein KMS steht. ;)

ja und wie lange läuft es? ;)

Und was passiert, wenn du keinen key eingibst? https://www.microsoft.com/de-de/evalcenter/evaluate-windows-server-2022

Wann hast du das letzte mal einen Server installiert?

Das mag sein, aber für den wissensaufbau einer für dich neuen Technologie würde ich 1. nicht die produktive Umgebung verwenden 2. eine kleine Testumgebung aufbauen, die nicht mal unbedingt der produktivumgebung entsprechen muss. aber jeder muss wohl seine eigenen Fehler machen. viel Erfolg.

Nein, das „macht keinen Sinn“.

Grundsätzlich sehe ich das auch so. Aber wenn’s nur intern ist und interne Dienste dran hängen dann ginge das schon. ;)

Nein der SAML Dienst muss ein Zertifikat anbieten dem der Client vertraut. Ob das jetzt ein eigenes, gekauftes oder ein selfsigned ist ist grundsätzlich egal. Macht aber je nachdem mehr Aufwand. Wenn das ne produktive Umgebung sein sollte, würde ich mir an deiner Stelle erstmal eine Testumgebung aufbauen. Außer du hast eine produktive Testumgebung (wie fast alle), aber dann weißt du ja was du tust. ;) Bye Norbert