cj_berlin

Würmer.

so isses.

...aber nur, wenn Du Exchange-Attribute tatsächlich von on-prem in die Cloud synchronisierst,

Nein. Der Sinn ist, dass der User von außerhalb die Anwendung X mit ihren spezifischen Ein- und Ausgaben erreichen kann, nicht, dass seine Maschine SMB und RPC zu Domain Controllern machen kann, nachdem sie im MSHEIMNETZ herumgelegen ist.

Zwei Punkte, und das sind nur die wichtigsten: Maschinen, die zuvor in einem fremden Netz waren, kommen in das eigene. VPN ist meistens TCP, moderne Application Delivery ist meistens UDP. UDP in TCP zu verpacken, bedeutet alle Vorteile von UDP zu verlieren.

Das stellst Du jetzt einfach mal als gegeben hin. Stimmt aber so nicht. In meiner Praxis verfügen nahezu 100% der Umgebungen, auch kleinere (was immer das in meiner Praxis bedeutet), über eine eigene oder eine extern gemanagte PKI... Ob jeder dieser PKIs so gepflegt und gehärtet ist, wie sie sollte, steht auf einem anderen Blatt. Ich vermag halt einfach nicht zu erkennen, wo bei alldem die Schuld von Microsoft oder von jedem anderen Hersteller ist. Bei einem Produkt hat Microsoft es versucht, die Defaults auf Sicherheit zu trimmen: Vista. Was war das Gejammer groß! SCT war nur ein Beispiel. Du hast Dich beschwert, dass der Hersteller keine leicht zu bedienenden Mittel zur Verfügung stellt, Compatibility-bound Defaults in Security-bound Defaults umzuschalten. Das ist die Antwort darauf. Das, ASR und WDAC bringen schon eine ganze Menge. Der Rest ist Aufgabe der Admins. Was wäre denn sonst ihre Aufgabe? Schöne Namen aus dem Disney-Kanon für die Server aussuchen?

...wobei das bei Anwälten noch einmal besonders ist. Wenn sie eine e-Mail-Adresse veröffentlichen, kann jedes Organ der Rechtspflege an diese Adresse zustellen (wurde mir von einem Kunden, selbst RA und Notar, erklärt, als ich für die Kanzlei die Briefvorlage anpassen sollte und fragte, warum die Mail-Adresse nicht drauf ist).

SCT? Verständlicher geht's ja wohl kaum - Backup der GPO einspielen, verknüpfen, fertig. Ach, die 16-Bit-Applikation aus 1998 funktioniert nicht mehr? Nun, Du wolltest "sicher"

Ganz ehrlich? Lass das mit dem VPN sein. VPN war gestern schon Mist. Terminalserver Remote Desktop Gateway Clients, die nicht 100% der Zeit im Office auf dem Tisch sind, kommen gar nicht erst ins LAN und müssen auch nicht in die Domäne. Warum wollt ihr Exchange on-prem bauen? Habt ihr jemanden mit genug Know-How, um das jahrelang zu betreiben? Habt ihr ihn/sie gefragt, ob er/sie das auch möchte? Holt euch Microsoft 365, dann habt ihr, je nach Tarif, Exchange, Teams, SharePoint *und* Management für die Clients, ohne dass sie dafür in die Domäne müssen. Habt ihr mehr davon.

...wobei Zoom im Vergleich zu Teams oder Webex ja noch geht... Dennoch kein Vergleich zu TeamViewer oder AnyDesk.

Korrekt. Und er kann und darf per PowerShell (oder GUI) angepasst werden, nur nicht über AD-*, sondern über Exchange-*.

Moin, mailNickname ist der Alias. Dieser darf on-prem (übrigens: es heißt on premiseS) bei mehreren Empfängern den gleichen Wert haben, in Exchange Online hingegen nicht). Beide Attribute dürfen nicht per ADSIEdit oder AD-PowerShell bearbeitet werden, sondern nur durch Exchange.

https://github.com/mozilla/policy-templates/blob/master/README.md#websitefilter

Nein.

Das Schlimme ist, 90% der Dinge, die dort stehen werden, sind seit 20 Jahren nicht neu, und werden trotzdem nicht oder nur halbherzig angegangen. Ich hatte auf der CIM dieses Jahr ein Bildchen dazu gezeigt: Bingo!

Das würde aber nicht dazu führen, dass statt des Namespaces der (korrekte) FQDN des Servers angesprochen wird, oder? Es wird ja im Endeffekt der Exchange angefahren und präsentiert auch das neue Zertifikat... Wenn im SCP --> Im AD kontrollieren!!! der richtige Name steht, und es keine CNAME-Einträge im DNS --> dort kontrollieren!! gibt, die auf den Server-FQDN verweisen, kann es ja nur entweder was gecachetes sein oder eine HTTP-Redirection. Bei Redirection wüsstest Du inzwischen, dass es sie gibt, den Autodiscover-Cache kannst Du zur Probe löschen. Bei Clients, die in der Domäne oder anderswie gemanagt sind, könntest Du die Zeit bis zur Migration mit einer lokalen XML-Datei und einer entsprechenden GPO überbrücken. Aber spätestens zur Migration muss das gerade gezogen sein, sonst hast Du andere Effekte.

VPN ist ein schwieriges Thema. Jemand hat mal gesagt, VPN ist nur für zwei Dinge gut: Es öffnet ein Tor ins Datacenter und erlaubt IT-Abteilungen, sich der Modernisierung der Legacy-Anwendungen zu widersetzen. Viele Firmen, die vor der Pandemie gar keine Remote-Arbeit hatten, haben VPN zum Glück übersprungen und gleich auf VDI mit einem Prä-Authentifizierungsgateway am Perimeter gesetzt. Aber bei vielen ist VPN tatsächlich Standard, und jetzt kommt's: 08:45 Laptop wird angemacht und ist im gleichen Netz (HeimWLAN) mit dem ungepatchten Drucker, dem ungepatchten ZigBee, zwei Kinder, die mit dubiösen Apps am Tablet rummachen und dem Default-Passwort am Router. 08:59 Du kommst vom Frühstück und baust die VPN-Verbindung in die Firma auf. 09:00 VPN ist aufgebaut. Weil Du aber auf Deinem WLAN-Drucker auch arbeitsbedingt drucken musst, ist VPN als Split-Tunnel konfiguriert. Finde einen Fehler auf diesem Bild

Auf Exchange 2010?

Was wäre denn der Unterschied? Ein SSL-Zertifikat hat einen Namen im Subject und einen oder mehrere Namen im SAN. "Multidomain" ist ein Marketing-Begriff und bedeutet nur, dass die SANs aus unterschiedlichen DNS-Domains stammen können. Die Frage ist: Stehen die beiden Namen, die Dein Server hat (mail.... und autodiscover...) im SAN? Falls ja, alles gut. Du kannst aber auch das Zertifikat zurücktauschen und das Vorherige verwenden.

Das ist beides Autodiscover.

Outlook cacht die URLs eine ganze Weile. Das heißt, wenn Du die gesamte Umstellung jetzt machst, werden fast alle Clients noch auf die alte InternalURL zugreifen wollen, der dortige FQDN wird im Zertifikat aber nicht enthalten sein. Du müsstest also im ersten Schritt Split-DNS und die URLs anpassen und erst ein paar Tage später das Zertifikat tauschen - und selbst dann wird es vermutlich noch ein paar Nachzügler geben, die versuchen werden, die alte URL zu erreichen, und eine Zertifikatsmeldung kriegen. Aber wenn Du eh migrierst, musst Du das Zertifikat auf dem 2010 vielleicht auch gar nicht tauschen - musst halt fertig migrieren, bis es ausläuft.

Eine Garantie wird Dir niemand geben, der Deine Umgebung nicht kennt. Aber wenn im Zertifikat sowohl der FQDN des Servers als auch der externe (und nun auch interne) Namespace als SANs hinterlegt sind, die CA-Kette vom IIS ausgeliefert wird und die Clients ihr vertrauen, sollte das nahtlos funktionieren. Da musste man IIRC noch basteln, damit die HTTP-Umleitung funktioniert. Aber auf dem Exchange 2016 kannst Du das machen, wenn er da ist.

Was jetzt genau? Split-DNS und vDir-URLs umschreiben? Kannst Du machen, für die Migration brauchst Du es ja sowieso.

Wenn Du eine halbwegs aktuelle Exchange-Version installiert hast, sollte das Entfernen dieses Hakens - NICHT auf vDir-, sondern, wie von mir beschrieben, auf Website-Ebene - dazu führen, dass HTTP- zu HTTPS-Umleitung stattfindet. Wenn Du den Haken setzt, fordert IIS SSL. Ein Versuch, HTTP zu verwenden, wird mit "Unauthorized" abgewiesen.

Moin, die Vorgehensweise ist so in Ordnung. autodiscover.firma.de brauchst Du nur, wenn Du Clients hast, die nicht Mitglied der Domäne sind. Outlook interessieren die Virtual Directories selbstverständlich auch, zumindest Autodiscover, EWS und MAPI. HTTP zu HTTPS-Umleitung kannst Du im IIS einrichten, indem Du den Haken bei "Require SSL" in beiden Websites entfernst.