NorbertFe

Gibt doch nix anderes mehr.

Ein Sync geht vom ad in die Cloud. Also nicht einfach weiter weiter weiter fertig klicken sondern überlegen was man synchen will und wie man das sinnvoll filtern kann. Es hat sich gezeigt, dass Attribute dafür am sinnvollsten sind. In deinem Fall musst du jetzt überlegen, ob du ausschluss- oder Einschlusskriterien nutzen willst. Wenn Attribut a=wert x dann synchen oder wenn Attribut a=wert x dann nicht synchen. Wenn du die Regeln angepasst hast, verschwinden sie User auch wieder aus der Cloud wenn du alles richtig gemacht hast. ;)

Üblicherweise macht man sich davon einen Screenshot und heftet ihn sicher ab. Spätestens jetzt weißt du, warum. ;)

Du musst dann wohl bei allen Konten den QR code neu scannen. Solange wir dein alter Authenticator noch geht ist das ja vermutlich schnell erledigt. Neues Gerät registrieren. bei einigen Anbietern gibts dafür die recovery Codes usw. Bei Duo kann man dafür ein extra Passwort anlegen, damit sowas nicht passiert.

Das weiss ich doch und würde ich bei einer org wie eurer auch erwarten, dass genug know how vorhanden ist. ;) und ich denke nicht, dass ihr mal eben ein /24 erweitert weil die ips ausgehen. :p

Dann kann jeder ja sich entweder mit 5 Jahren Supportzeiträumen anfreunden oder Alternativen nutzen. ;)

RDP CALs waren schon immer die Ausnahme von dieser Regel.

Siehst du doch. Kleinkunden sollen einfach cloud nutzen. Dann müssen sie sich keine Gedanken über Serverbetriebssysteme machen. Kann man mögen oder nicht, ändert aber nichts am aktuellen Trend.

Dann musst du halt RDS CALs kaufen und damit einen Terminalserver draus machen. Mehr als 2 geht halt nicht.

Du brauchst natürlich für JEDES Netz ein Gateway und dann ein Transfer Netz über das alle nach draußen kommen. ;) Man schaut sich an wie routing funktioniert und wie die eigenen Switches/Firewalls konfiguriert werden müssen.

So in etwa. ;)

Hatten wir nicht neulich das Thema inplace upgrade. Man kann Glück haben oder eben nicht. der wsus überlebt bspw. Ein inplace auch nicht. ;)

Und ich unter der von Jan. ;)

Ich sprach von sinnvoll :p

Weil die "krumme" Netze auch nicht mögen und /29 das kleinste sinnvolle Netz ist. :P

Genau so würd ich das auch machen. Warum jetzt drumherumdoktorn, wenns so einfach ist. Bye Norbert

Die Root CA wechselt ja nun auch nicht ständig und bei jedem Wechsel eurer Sectigo Zertifikate würde man ja grundsätzlich auch die Intermediate und Root CAs prüfen können. Also der Aufwand hält sich in Grenzen. Aber ja in wär auch für Automatismus.

JA! Genau so stand es in der Prüfung. Und ja es ist falsch. Wär ja nicht das erste Mal, dass falsche Fakten in der Prüfung stehen.

Das war uns allen klar. Ich hab leider die Prüfungsunterlagen von MS nicht mehr griffbereit, aber da stand eindeutig und auf Englisch drin, dass send-as Rechte eine Lizenz für Shared Mailboxes benötigen. Vielleicht gibts ja hier jemanden der die selben Prüfungsunterlagen/-fragen hatte. Ich hatte mir das genau deswegen gemerkt, weil es eben entgegen jeder Praxiserfahrung war. ;)

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?