Wir versuchen, eine sichere E-Mail-Gateway-Lösung durch die integrierte E-Mail-Nachrichtenverschlüsselung von MS365 zu ersetzen.
Wir haben eine E-Mail-Flussregel eingerichtet, um die Verschlüsselung von einer bestimmten Absenderadresse an jeden beliebigen Empfänger wie folgt zu erzwingen:
BEDINGUNGEN:
Regel anwenden, wenn:
Absender ist '[email geschützt]'Gehen Sie folgendermaßen vor: Nachrichtensicherheit ändern - Office 365-Nachrichtenverschlüsselung und Rechteschutz anwenden
- Nachricht mit „Verschlüsseln“ schützen (Standard-Verschlüsselungsrichtlinie)
Wenn wir nun von alwaysencrypt- das ist einLizenziertes Business Basic-Kontoin diesem Mieter - wir haben seltsame Ergebnisse.
- Beim Senden an ein Nicht-MS365-Konto/-Mandanten/-Domäne werden E-Mail-Nachrichten ordnungsgemäß zugestellt und erfordern die Übermittlung eines OTP-Codes zur Validierung des Zugriffs. Dies funktioniert einwandfrei.
- Bei manchen MS365-Mandantenempfängern, die jedoch NICHT Teil des ursprünglichen Mandanten sind, funktioniert die Rechteverwaltung ordnungsgemäß und identifiziert diesen externen Mandanten ordnungsgemäß als Empfänger, und dem Benutzer wird der Zugriff gestattet.
- Für andere MS365-Mandantenempfänger, die NICHT Teil des ursprünglichen Mandanten sind, erlaubt das System ihren Benutzern nicht, sich anzumelden und die MS365-Mandantenauthentifizierung zum Zugriff auf das Dokument zu verwenden, und schlägt mit einer Meldung ähnlich der folgenden fehl:
Selected user account does not exist in tenant 'Example Tenant' and cannot access the application 'UUID' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.
Es ist sehrneudass diese dritte Option bei uns möglich ist und MS365 externen Mandanten die OTP-Code-Option NICHT bietet.
Ich sehe keine Möglichkeit, dies zu beheben und externen Mandanten Zugriff auf das Rechtesystem zu gewähren, ohne sie manuell zu unserem Ursprungsmandanten hinzuzufügen. Dies ist ein Problem, da es sich hierbei um ein automatisiertes System handelt, das verschlüsselte Nachrichtendaten als Teil von Warnsystemen an externe Empfänger sendet.
Hat das schon mal jemand gesehen und hat jemand eine Idee, wie wir es lösen können, um es zu zwingen, für den Zugriff auf verschlüsselte Nachrichten KEINE MS365-Mandantenauthentifizierung zu verwenden und nur eine OTP-Code-Verifizierung durchzuführen, wenn sie sich außerhalb der Organisation befinden?
Ich sollte anmerken, dass MS365 jetzt die Verwendung von Microsoft Purview erzwingt, sodass die älteren OME-Lösungen nicht funktionieren, und es gibt keinerlei Dokumentation dazu, wie man dies ändern oder diese Überarbeitungen nach Bedarf vornehmen kann.
Beachten Sie, dass ich Zugriff auf einen globalen Administrator auf dem ursprünglichen Mandanten habe und daher bei Bedarf Zugriff auf alle Powershell-Optionen haben SOLLTE.
Antwort1
Tatsächlich stellt sich also heraus, dass es sich hier gar nicht um ein „Mieter“-Problem handelt, sondern um ein Lizenzproblem. Und das istnichtin der Dokumentation leicht zu finden, da die grundlegenden Purview-Seiten nicht einmal darauf verweisen. Es steht nur in den FAQ, die Sie nicht sehen, wenn Sie versuchen, Verschlüsselungssachen zu debuggen.
BegrabenHierIn den FAQ der Microsoft Purview OME-Dokumentation (aber NICHT an anderer Stelle in der Purview-Dokumentation) wird angegeben, in welchen Plänen Purview automatisch unterstützt wird:
Um die Microsoft Purview-Nachrichtenverschlüsselung verwenden zu können, benötigen Sie einen der folgenden Pläne:
Microsoft Purview Message Encryption wird als Teil von Office 365 Enterprise E3 und E5, Microsoft 365 Enterprise E3 und E5, Microsoft 365 Business Premium, Office 365 A1, A3 und A5 sowie Office 365 Government G3 und G5 angeboten. Sie benötigen keine zusätzlichen Lizenzen, um die neuen Schutzfunktionen von Azure Information Protection zu erhalten.
Sie können Azure Information Protection Plan 1 auch zu den folgenden Plänen hinzufügen, um Microsoft Purview-Nachrichtenverschlüsselung zu erhalten: Exchange Online Plan 1, Exchange Online Plan 2, Office 365 F3, Microsoft 365 Business Basic, Microsoft 365 Business Standard oder Office 365 Enterprise E1.
Jeder Benutzer, der von der Microsoft Purview-Nachrichtenverschlüsselung profitiert, benötigt eine Lizenz zur Verwendung der Nachrichtenverschlüsselung.
Leider ist dies NICHT auf den Seiten mit den MS365-Plänen aufgeführt und in keiner der anderen Dokumentationen zu den MS365-Plänen ausführlich beschrieben – zumindest an keiner offensichtlichen Stelle.
Wir haben wie angegeben eine Lizenz für Azure Information Protection Plan 1 erhalten und sie dem alwaysencryptBenutzer im Ursprungsmandanten zugewiesen. Nachdem Microsoft Zeit hatte, diese Änderung und den AIP-Dienst auf den Ursprungsmandanten anzuwenden, funktioniert es wie erwartet und externe Mandanten können die Nachrichten jetzt anzeigen, ebenso wie Nicht-MS365-Empfänger.
Microsoft hat heute für seine Dokumentation die Note -1 bekommen, aber immerhin haben wir das Problem mit einer einfachen Lösung gelöst: indem wir Microsoft noch mehr Geld zustecken.