Viele Administratoren verzichten auf die digitale Signierung von eigene PowerShell-Skripten. Um solche PowerShell-Skripte in der lokalen IT-Infrastruktur ausführen zu können wird daher die PowerShell-Ausführungsrichtlinie auf Unrestricted konfiguriert. Diese Konfiguration ist ein großes Sicherheitsrisiko für das gesamte Unternehmen.
Unrestricted
Wenn das digitale Zertifikat zur Code-Signierung in Ihrem persönlichen Zertifikatsspeicher hinterlegt ist, ist die Signierung besonders einfach.
Wechseln Sie in einer PowerShell_Session in das Verzeichnis, das die zu signierende PowerShell-Datei enthält und signieren Sie die Datei mit den folgenden Befehlen. In diesem Beispiel wird die Datei MyPowerShellScript.ps1 signiert.
MyPowerShellScript.ps1
# Lesen des Signatur-Zertifikates aus dem persönlichen Zertifikatspeicher # des Anwenders, der die Signierung durchführt $cert=Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert # Lesen eines exportierten Signatur-Zertifikates aus einer PFX-Datei # Wenn der Export mit einem Kennwort geschützt ist, werden Sie nach # dem Kennwort gefragt $cert = Get-PfxCertificate -FilePath C:\SCRIPTS\CERTS\CodeSigningVarunagroup.pfx # Digitale Signierung der Datei MyPowerShellScript.ps1 Set-AuthenticodeSignature -FilePath MyPowerShellScript.ps1 -Certificate $cert
Wissenswert ist, dass das Cmdlet Get-PfxCertificate, im Gegensatz zur Dokumentation bei Microsoft Docs, keinen Parameter -Password verfügt, um das Kennwort als SecureString zu übergeben.
Get-PfxCertificate
-Password
Konfigurieren Sie nach der Signierung Ihrer PowerShell-Skripte die Ausführungsrichtlinie für Ihre Systeme mit Hilfe einer Gruppenrichtlinie.
Viel Spaß mit PowerShell!
In vorherigen Blog-Artikeln wurde allgemein das Thema E-Mail Verschlüsselung und E-Mail Sicherheit besprochen und auf die Verbindungsverschlüsselung mit TLS eingegangen. In diesem Artikel werden Möglichkeiten zum Einsatz von S/MIME zur Signierung und Verschlüsselung von E-Mail Nachrichten betrachtet.
In der heutigen Zeit kommt der Signierung und Verschlüsselung von E-Mail Nachrichten eine zentrale Rolle zu, um sich gegen Wirtschaftsspionage und anderen Zugriffe Dritter auf die Unternehmenskommunikation zu schützen. Die Sicherung des Nachrichtenverkehrs ist nur ein Baustein im gesamten Informationssicherheitskonzept eines Unternehmens. Weitere Punkte sind u.a. Schutz gegen den Verlust von Daten (Data Leackage Prevention, DLP), Berechtigungsmanagement (RMS) oder die Kontrolle von Zugriffsberechtigungen.
Das generelle Konzept zur Verschlüsselung von Nachrichten per S/MIME geht auf das Jahr 1995 zurück. Die aktuellen Implementierung von S/MIME 3.2 sind seit 2010 Stand der Technik.
Bei der Verwendung von S/MIME wird eine unverschlüsselte E-Mail Nachricht in einer sog. MIME gekapselt und nur signiert oder auch verschlüsselt. Neben diesem ersten Teil enthält die neue Nachricht auch die erforderliche Zertifikatsinformation zum Zugriff auf den Nachrichtenteil.
Zertifikate teilen sich in einen öffentlichen und einen privaten Schlüssel und bilden gemeinsam das Schlüsselpaar eines Anwenders. Im Standardfall wird das Schlüsselpaar auf einem Clientrechner eines Benutzers erzeugt und der öffentliche Schlüssel von einer Zertifizierungsstelle signiert. Der private Schlüssel verbleibt auf dem Rechner des Benutzers.
Da der private Schlüssel somit nur an einer Stelle gespeichert ist, jedoch für die Laufzeit des Zertifikates zum Entschlüsseln von Nachrichten benötigt wird, stellt dies ein Risiko dar. Kommt es ohne Datensicherung des privaten Schlüssels zu einem Schaden am Gerät, muss ein neues Zertifikat ausgestellt werden und alte, mit dem verlorenen Zertifikat verschlüsselte Nachrichten, können nicht mehr entschlüsselt werden. Mehr dazu im Abschnitt "Gateway-Lösungen".
Neben der Speicherung des Zertifikates auf dem Clientrechner können auch Signaturkarten verwendet werden. Der Einsatz von Signaturkarten erfordert allerdings auch den Einsatz von passenden Lesegeräten, die meist nicht für alle Arten von Clientgeräten zur Verfügung stehen. Die auf Signaturkarten gespeicherten Zertifikate sind durch eine PIN vor unbefugtem Zugriff geschützt.
Im Standardfall ist das S/MIME E-Mail Zertifikat auf dem Clientrechner eines Benutzers vorhanden. Dies bedeutet, dass der Benutzer auf diesem Clientrechner in der Lage ist, E-Mail Nachrichten zu signieren oder zu verschlüsseln. Und dies auch nur mit einem E-Mail Programm wie Outlook. Alternative Produkte verfügen eventuell über einen separaten Speicher für S/MIME Zertifikate und verwenden nicht den Zertifikatsspeicher des Betriebssystems.
In der heutigen Welt ist ein fester Clientrechner, sei es ein Desktop PC oder ein Laptop, nicht mehr das einzige Gerät, über das ein Mitarbeiter Zugriff auf E-Mails hat. Wenn in einem Unternehmen S/MIME verwendet wird, soll die Zugriff auf E-Mail Nachrichten und damit das Verfassen und Lesen von verschlüsselten Nachrichten auf allen Clients verfügbar sein.
Zu den Client-Optionen und Zugriffsarten gehören:
Je nach erforderlichem Einsatzszenario im Unternehmen, muss das S/MIME Zertifikat sowohl auf den Servern, als auch auf den auf den unterschiedlichen Endgeräten ausgerollt und installiert werden. Dies bringt ganz neue Herausforderungen mit sich. Gerade wenn unterschiedlichste Endgeräte zum Einsatz kommen oder eine BYOD Kultur etabliert ist, empfiehlt sich eine zentrale Gateway-Lösung für die E-Mail Verschlüsselung.
Der Einsatz von S/MIME Verschlüssung beim Zugriff auf Webmail (Outlook Web App) erfordert den Zugriff des Browsers auf den lokalen Zertifikatsspeicher. Hierzu muss eine separate Software-Komponente (S/MIME Plugin) installiert werden, die nur mit dem Internet Explorer funktioniert. Zusätzlich müssen die serverseitigen S/MIME Parameter für OWA im Exchange Server konfiguriert werden. Da die OWA S/MIME Implementierung aber nur ein Teil der zur Verfügung stehenden Crypto-Einstellungen unterstützt, müssen OWA S/MIME Einstellungen und die Crypto Konfigurationen des Betriebssystem im Einklang erfolgen. Ansonsten kommt es in OWA zu Fehlermeldungen und der Benutzer kann E-Mails nicht signieren, verschlüsseln oder entschlüsseln. Dies bedeutet, dass ein Benutzer per Outlook verschlüsselte E-Mails nicht in OWA öffnen kann.
Die zur Signierung und Verschlüsselung verwendeten Zertifikate werden von einer Zertifizierungsstelle signiert. Diese Zertifizierungsstelle ist Bestandteil einer sog. PKI und wird entweder von einem externen Anbieter oder aber vom eigenen Unternehmen betrieben.
Die Verwendung eines externen Anbieters von Zertifikaten hat den Vorteil, dass in den allermeisten Fällen die erforderlichen Zertifikate (Root- und Intermediate-Zertifikate) zur Überprüfung eines E-Mail Zertifikates bereits auf den jeweiligen Endgeräten zur Verfügung stehen. Die benötigten E-Mail Zertifikate für Mitarbeiter werden immer für einen bestimmten Zeitraum ausgestellt, wobei unterschiedliche Zeiträume mit unterschiedlichen Kosten verbunden sind.
Die Implementierung einer eigenen PKI ermöglicht es Unternehmen, die Zertifikatsinfrastruktur auch für andere Komponenten zu verwenden. Hierzu gehören u.a. interne Webserver, Lync Kommunikation oder Benutzerauthentifizierung.
Die Verwendung einer eigenen PKI erhöht aber auch die Komplexität der IT-Infrastruktur und will gut überlegt und geplant sein, da etablierte PKI für einen langen Zeitraum in Betrieb ist.
Für S/MIME bedeutet der Einsatz einer eigenen PKI, dass die erforderlichen Root- und Intermediate Zertifikate für externe E-Mail Empfänger zur Verfügung stehen müssen. Partnerunternehmen können diese Zertifikate mit Hilfe von Softwareverteilung intern zur Verfügung stellen. Andere Empfänger müssen in der Lage sein, sich diese Zertifikate von einer Webseite herunterladen zu können. Hinzu kommt, dass der Endpunkt zur Überprüfung von zurückgezogenen Zertifikaten ebenfalls aus dem Internet erreichbar sein muss.
Wie bereits oben beschrieben, ist die Ausstellung von E-Mail Signatur Zertifikaten auf Benutzerrechnern in Unternehmen als Risiko zu sehen. Ebenso können Benutzer nicht ohne weiteres die gewohnten unterschiedlichen Endgeräte verwenden, um S/MIME Nachrichten zu empfangen oder zu senden.
Hier setzen Gateway-Lösungen an, die zentral die Signierung und die Ver- und Entschlüsselung sicherstellen. Das Zertifikatmanagement, also die Ausstellung und das Widerrufen von Benutzerzertifikaten erfolgt ebenfalls zentral am Gateway.
Die öffentlichen Schlüssel von eingehenden Nachrichten werden automatisch ausgelesen und zentral gespeichert. Hierdurch stehen die öffentlichen Schlüssel von externen Kommunikationspartnern allen Mitarbeitern im Unternehmen für eine sichere E-Mail Kommunikation zur Verfügung.
Durch ein Regelwerk kann sichergestellt werden, dass E-Mails an Empfänger, die keine Verschlüsselung unterstützen, auch unverschlüsselt zugestellt werden. Die Verschlüsselung des Übertragungskanal ist weiterhin möglich.
Als Beispiel einer solchen Lösung sein hier enQsig von Net at Work, Paderborn, genannt. Diese zertifizierte Verschlüsselungslösung unterstützt neben der Verschlüsselung mit S/MIME auch PGP. Das Produkt verfügt über weitere Funktionen, die Sie gerne hier nachlesen können.
Eine zentrale Gateway-Lösung zur E-Mail Verschlüsselung stellt eine optimale Möglichkeit zur Implementierung sicherer E-Mail Kommunikation dar, bei gleichzeitiger Reduzierung des Aufwandes für die erforderliche IT-Infrastruktur und die notwendigen Prozesse.
Es gibt keinen wirklichen Grund, E-Mail Verschlüsselung nicht einzusetzen. Die Gefährdungen für sensible Unternehmenskommunikation werden in den nächsten Jahren eher steigen als sinken.
Und mit einer zentralen Gateway-Lösung ist es sowohl für mittelständische Unternehmen, als auch für Großkonzerne möglich, eine verlässliche Kommunikationsumgebung zu schaffen, die anderen technischen Entwicklungen nicht im Wege steht.
Haben Sie Fragen rund um das Thema E-Mail Verschlüsselung und E-Mail Sicherheit? Kontaktieren Sie uns unter: emailsecurity@granikos.eu.
Vom 4. - 8. November fand die diesjährige Microsoft Ignite Konferenz statt. Ein großes Thema war die Absicherung von Identitäten und Applikationen und die sichere Zusammenarbeit im Rahmen von Modern Workplace und Modern Life.
Die folgenden Liste bietet einen Überblick über die wichtigsten Sessions zum Thema Azure Active Directory. Der jeweilige Link führt Sie zu den detaillierten Session-Informationen, inklusive der Session-Aufzeichnung und PowerPoint-Präsentation, falls vorhanden. Hinter jedem Titel ist der Themenlevel für die Zielgruppe vermerkt.
Intermediate (200)
Foundational (100)
Advanced (300)
Expert (400)
TK = Technical Keynote WRK = Workshop Session THR = Theater Session (20 Minuten) BRK = Breakout Session (45 Minuten) SECO = Session (45 Minuten)
Viel Spaß mit Microsoft 365 und Azure Active Directory.
Sie benötigen Hilfe bei der Entscheidung für oder gegen einen Wechsel zu Office 365 oder Microsoft 365? Unser Microsoft Cloud Workshop hilft Ihnen, die für Ihr Unternehmen passenden Entscheidungen zu treffen. Melden Sie sich bei uns: info@granikos.eu
In der heutigen Zeit ist die skriptbasierte Verwaltung von Server-Softwarelösungen aus der Arbeitswelt von Administratoren nicht mehr wegzudenken. Immer mehr Produkte und cloudbasierte Dienste lassen sich nur per PowerShell und individuelle Skripte sinnvoll administrieren. Gerade Office 365 ist hier ein unrühmliches Beispiel, da jeder Dienst über eine individuelle PowerShell-Schnittstelle verfügt.
Dieser Umstand hat zur Folge, dass Sie als Administrator oft Skripte zur Verwaltung komplexer Umgebungen einsetzen müssen, die Sie nicht selbst geschrieben haben. Die Skripte werden entweder von externen Dienstleister programmiert oder einfach aus dem Internet heruntergeladen. Hierbei implementiert jedes Skript, im Idealfall, eine eigene Protokollierung der ausgeführten Aktionen.
Die PowerShell-Skripte sind in den meisten Fällen für die individuelle Ausführung durch einen Administrator konzipiert und weniger für die regelmäßige und vollautomatische Ausführung. Als Administrator möchten Sie sich aber um wichtiger Dinge kümmern, als z.B. die Anlage von Benutzerkonten im Active Directory, die E-Mail-Aktivierung von Konten oder die Erstellung von SharePoint Team-Sites.
Sie stehen u.a. vor folgenden Problemen:
Sie kommen mit der Nutzung der Windows Bordmitteln, wie dem Task Scheduler, schon recht weit. Aber Sie werden mir zustimmen, dass dieses Tool nicht gerade die bequemste Art ist, um PowerShell-Skripte sinnvoll und sicher zu automatisieren.
Ein Lösung für dieses Dilemma ist die Nutzung einer Softwarelösung, die uns ein Trennung zwischen dem ausführenden Skript-Kontext und dem Kontext des Anwenders, der ein Skript startet, bietet. Mit einem Rollen- und Berechtigungssystem kann ein Skript, in Abhängigkeit der Rollenzuweisung, unterschiedlich ausgeführt werden.
WIr benötigen also ein Lösung, die uns folgende Funktionen bietet:
Mit ScriptRunner steht eine professionelle Softwarelösung zur Verfügung, die uns all diese Möglichkeiten bietet. ScriptRunner ist ein sehr umfangreiches und leistungsfähiges Produkt zur PowerShell-Automatisierung. Aus meiner Sicht ist das Sicherheitskonzept, das für die Delegierung der Skript-Ausführungen eingesetzt wird, einer der Hauptgründe für das Produkt.
Das folgende Schaubild vereutlicht die Isoliserung von ScriptRunner für die sichere Ausführung von PowerShell-Skripten.
Grafik © ScriptRunner
Die einzelnen Schritte sind:
Die Automatisierung und die wiederkehrende Ausführung führt zu einer Reduzierung der Betriebsrisiken und minimiert kostenintensive manuelle Nacharbeiten. Dies gelingt durch die hohe Reproduzierbarkeit der immer gleichen Aufgaben (Stichwort: Erstellung von Benutzern mit unterschiedlichen Attributen, je nach Fachabteilung). Durch ein Zonenmodell und die strikte Trennung der Ausführungsberechtigungen (Anwender, Automatisiserungsdienst, Skript-Credentials) erreichen Sie ein Maximum an Betriebssicherheit.
Mit solch einer Aufteilung können Sie die Ausführung von Skripten nicht nur an das Helpdesk-Team delegieren, sondern sogar an DV-Ansprechpartner in Fachabtielungen. Die Weboberfläche ist intuitiv bedienbar und führt den Anwender sucher durch alle konfigurierten Eingabe- und Auwahlschritte.
Ab Q1 2019 werden Sie speziell für Exchange Server, Exchange Online und Office 365 entwickelte Skripte zur Nutzung mit ScriptRunner in diesem Blog finden.
Viel Spaß bei der Automatisierung!
Vom 4. - 8. November fand die diesjährige Microsoft Ignite Konferenz statt. Micosoft Teams nahm im Ausstellungsbereich "Modern Workplace & Modern Life" einen großen Bereich ein. Mit großer Spannung wurden die Ankündigungen zu neuen Funktionen rund um Microsoft Teams erwartet.
Die folgenden Liste bietet einen Überblick über die wichtigsten Sessions zu Microsoft Teams.
Der jeweilige Link führt Sie zu den detaillierten Session-Informationen, inklusive der Session-Aufzeichnung und PowerPoint-Präsentation, falls vorhanden. Hinter jedem Titel ist der Themenlevel für die Zielgruppe vermerkt.
TK = Technical Keynote THR = Theater Session (20 Minuten) BRK = Breakout Session (45 Minuten) MTG, VCE = Lernmodul (45 Minuten)
Nutzen Sie für Fragen zu den einzelnen Sessions gerne direkt die Kommentarmöglichkeit unterhalb Sessionbeschreibung. Hierzu ist allerdings eine Anmeldung erforderlich,
Für Fragen rund um Microsoft Teams stehen Ihnen die Conversation Spaces der Tech Community zur Verfügung:
Viel Spaß mit Microsoft 365 und Microsoft Teams.
Exchange Server 2019 ist die aktuelle Version der E-Mail-Messaging Plattform für die Installation in der lokalten IT-Infrastruktur (aka On-Premises). Als lokale Infrastruktur gilt auch die Nutzung von Exchange Server 2019 auf virtualisiserten Serversystemen in Microsoft Azure. Bei Microsoft handelt sich, technisch gesehen, nur um ein ausgelagertes Rechenzentrum. Als wirkliche Alternative zu einem eigenen Betrieb von Exchange Server 2019 steht Ihnen Exchange Online, als Bestandteil des Software-as-a-Service Angebotes von Office 365, zur Verfügung.
Der Betrieb von Exchange Server 2019, die hybride Verbindung zwischen einer lokalen Exchange Organisation und Exchange Online oder die alleinige Nutzung von Exchange Online erfordern eine detaillierte Planung und Vorbereitung.
Auf dieser Seite finden Sie die wichtigsten Referenz-Links zu Online Ressourcen von Microsoft und anderen Quellen, um das für Sie richtige Exchange Produkt zu installieren, einzurichten und zu betreiben.
Wie einleitend schon ausgeführt, kann Exchange grundsätzlich in vier unterschiedlichen Architekturmodellen betrieben werden, die ihre ganz individuellen Vor- und Nachteile bieten. Diese sind:
= kontrolliert durch Microsoft = kontrolliert durch Kunden
Der Betrieb und die vollständige Verwaltung von Exchange Server erfordern die Verwendung der Exchange Management Shell (EMS). Mit Hilfe des browserbasierten Exchange Admin Center (EAC) können Sie Gelegenheitsaufgaben durchführen. Dies gilt für Exchange Server 2019 ebenso wie für Exchange Online.
Viel Spaß mit Exchange Server 2019 und Exchange Online.
Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu
In ihrem Blogartikel Improving Security - Together hat die Exchange Produktgruppe angekündigt, die unsichere Authentifizierungsmethode Basic Authentication zum 13. Oktober 2020 nicht nur für die Exchange Web Services (EWS) abzuschalten, sondern zusätzlich auch für Exchange ActiveSync (EAS), POP, IMAP und Remote Exchange PowerShell.
Bei der Basic Authentication handelt es sich um eine in die Jahre gekommene Authentifizierungsmethode, die im Vergleich zu modernen Authentifizierungsmethoden Schwächen hat. Diese Schwächen führen dazu, dass diese Authentifizierungsmethode immer wieder von Angreifern verwendet wird, um unberechtigten Zugriff auf Ressourcen zu erlangen. Exchange Online und Azure AD sind, als globale Clouddienste, immens vielen Angriffen dieser Art ausgesetzt.
Die moderne Authentifizierung (Modern Auth), basierend auf OAuth 2.0, bietet im Zusammenspiel mit Multi-Faktor-Authentifizierung (MFA) einen umfassenderen Schutz für den Zugriff auf Exchange Online und andere Cloud-Ressourcen. Diese Art der Authentifizierung ist nicht neu, setzt sich für bestimmte Zugriffsarten aber nur langsam durch. Die Unterstützung für Modern Auth wird bereits seit Office 2013 unterstützt und ist seit Version 2016 nativ in das Produkt integriert.
Für mobile Endgeräte stellt sich die Situation etwas anders dar. In vielen Fällen erfolgt der Zugriff auf Exchange Online Postfächer mit nativen E-Mail-Clients der mobilen Endgeräte statt. Diese verwenden in den meisten Fällen das ActiveSync-Protokoll (EAS). EAS wiederum bedient sich standardmäßig der Basic Authentifizierung und ist daher für die Zukunft nicht mehr das passende Protokoll für den Zugriff auf Exchange Online. Hier ist Outlook Mobile (Android/iOS) die bessere Alternative. Mit Outlook Mobile haben Sie die Möglichkeit, die Authentifizierung der Benutzerkonten zusätzlich mit MFA abzusichern.
Für die Protokolle SMTP, POP und IMAP gibt es eine besondere Herausforderungen. Diese Protokolle unterstützen heute die moderne Authentifizierung (noch) nicht. Für den Zugriff auf Mitarbeiter-Postfächer stellt dies noch keine Problem dar, da dieser Zugriff immer über das Protokoll MAPIoverHTTP erfolgen sollte. Das eigentliche Problem sind all die anderen Applikationen, die Sie gegenwärtig für einen POP/IMAP-Postfachzugriff und SMTP-Mailversand über ein Exchange Online Postfach konfiguriert haben. Hierzu gehören z.B. Ticketsysteme, ERP-Lösungen oder individuell programmierte Line-of-Business-Applikationen (LOB).
Ähnlich sieht es für die Authentifizierung von PowerShell-Skripten aus, die auf einem Ihrer internen Skript-Server ausgeführt werden und Aktionen gegen Exchange Online ausführen. Für die direkte Anmeldung an die Exchange Online PowerShell mit Modern Auth können Sie bereits heute das Exchange Online PowerShell Modul mit MFA oder die Azure Cloud Shell verwenden.
Die Deaktivierung der Basic Authentication für Exchange Online hat direkte Auswirkungen auf die von Ihnen betreute IT-Infrastruktur. Um eine Unterbrechung im Zugriff auf Exchange Online-Ressourcen zu vermeiden, müssen Sie wissen, mit welchen Protokolle Anwender und Applikationen auf Exchange Online-Endpunkte zugreifen. Die Exchange Produktgruppe wird ein Software-Tool zur Auswertung bereitstellen, dass Sie bei der Analyse der Zugriffsarten unterstützt.
Für den Zugriff auf Exchange Postfächer von Windows Desktops ist die Maßnahme einfach. Wenn Sie noch ältere Windows Desktop Betriebssystem im Unternehmen einsetzen, wechseln Sie auf Windows 10 als Standard-Betriebssystem und migrieren Sie die Office-Installation zu Office 2019 bzw. Office 365 ProPlus.
Nutzen Sie Outlook Mobile für den Zugriff auf Exchange Online Postfächer. Outlook Mobile lässt sich über die gängigen Mobile Device Management (MDM) Lösungen zentral auf mobile Endgeräte verteilen und konfigurieren. Mit Hifle von Mobile Application Management (MAM) und Conditional Access können Sie die Sicherheit beim mobilen Zugriff auf Exchange Online Postfächer noch weiter erhöhen.
Für automatisierte PowerShell-Skripte wird die Anpassung auf Modern Auth schwieriger. Sie können für die Ausführung der Skripte in der lokalen IT-Infrastruktur das Exchange Online PowerShell Modul mit MFA implementieren. Hierbei müssen Sie allerdings bedenken, dass Skripte mit einer längeren Ausführungszeit in technische Probleme laufen werden. Wenn Ihre Skripte von Timeouts und Skriptverzögerungen, sog. Micro Delays, betroffen sind, müssen Sie die Strategie zur Skriptausführung überdenken und den Skript-Code anpassen. Eventuell ist es vorteilhafter, eine professionelle Softwarelösung zur Ausführung von Skripten einzusetzen, die Modern Auth nativ unterstützt. PowerShell-Skripte, die nur Aktionen gegen Exchange Online oder anderen Office 365 Endpunkten ausführen, können auch in Azure Automation betrieben werden.
Wichtig ist auch noch einmal der Hinweis, dass sich die Deaktivierung der Basic Authentifizierung auf Exchange Online bezieht. Die On-Premises Variante von Exchange Server 2019 ist davon nicht betroffen.
Die Exchange Produktgruppe ist sich der Herausforderungen für die Kunden bewusst. Der Titel des Original-Artikels Improving Security - Together ist mit Bedacht gewählt. Ein besserer Schutz von Exchange Online Postfächern und Ressourcen ist nur möglich, wenn die Erhöhung der Sicherheit gemeinsam, also von Ihnen als Office 365 Kunde und der Exchange Produktgruppe, umgesetzt wird.
Bereiten Sie sich und Ihre IT-Infrastruktur rechtzeitig auf die Abschaltung der Basic Authentication vor. Erstellen Sie einen realistischen Zeitplan für die notwendigen Konfigurationen und Anpassungen, um spätestens im Juli 2020 die Umstellung abgeschlossen zu haben. Es hat sich schon immer bewährt, einen zeitliche Puffer einzuplanen.
Die Erhöhung der Sicherheit geht immer mit Komfortverlust einher. Dieser Komfortverlust ist jedoch zu verschmerzen, wenn man den Sicherheitsgewinn gegenüberstellt.
Viel Spaß mit Exchange Online!