Typo3 (Symfony) E-Mail Versand mit Exchange Online via Microsoft 365 Entra Application (OAuth2)

Veröffentlicht am von — Keine Kommentare ↓

Wegen zahlreicher Nachfragen, hier ein Beitrag zur Einrichtung einer Microsoft 365 Entra Application für den E-Mail Versand via Symfony (XOAUTH2Authenticator-Klasse), also XOAuth2Authenticator. Also eigentlich ein „wie versendet man E-Mails auf Typo3 via Microsoft 365 [Exchange Online]“ wenn OAuth2 im Einsatz ist.

Viele Web-Agenturen haben leider offenbar immer noch nicht mitbekommen, dass eine SMTP-Authentication mit Username/Kennwort keine gute Idee ist und daher von praktisch allen großen Providern abgekündigt wurde. Dazu gehören T-Online, Google, Microsoft, web.de, GMX, Cleanmail und viele weitere. Zugegeben, OAuth2 ist nicht so einfach wie „Name und Kennwort“, aber Lichtjahre sicherer.

Typo3 nutzt Symphony für den Mailversand. Selbiges hat eine XAuth-Klasse, die auch OAuth2 unterstützt. Diese Anleitung soll die Einrichtung einer solchen „Registrierten Anwendung“ („App“) erleichtern.

Typo3 und Microsoft 365

  1. Öffnen von Microsoft Entra (https://entra.microsoft.com/), dann den Punkt „App-Registrierungen“ auswählen:

    2. Öffnen von „+ Neue Registrierung“. Hier nur den (Anzeige-)Namen eingeben und „Nur Konten in diesem Organisationsverzeichnis“ auswählen. Dann mit „Registrieren“ die App einrichten:

    3. Dann zur App ein „Secret“ (Geheimnis) hinzufügen. Das ist das Authentifizierungs-Token für den Symphony-Mailer. Dort einen „Neuen geheimen Clientschlüssel“ erstellen, idealerweise mit maximaler Laufzeit. Mit „Hinzufügen“ bestätigen.

    4. Das neu erstellte Secret am besten schnell an einen sicheren Ort kopieren. Wenn diese Seite geschlossen ist, gibt es keine Möglichkeit mehr, das Secret erneut anzuzeigen.

    5. API-Berechtigungen für den Mailversand hinzufügen. Benötigt werden die Berechtigungen:

    Mail.Send
User.Read
User.ReadBasicAll

    Das geht unter „API Permissions“ (API Berechtigungen) und „Hinzufügen“.

    Die Berechtigungen sind in „Microsoft Graph“ enthalten.

    Für diese BErechtigungen muss der „Administrator Consent“, also die „Administratoreinwilligung“ gesetzt sein.

    In Symphony wird diese Konfiguration nun übernommen, also einfach in die Config eingetragen oder ins GUI kopiert. Dieser Screenshot ist O. Krömer geklaut. Die Variablen sind perfekt benannt.

    VSSADMIN lässt löschen nicht zu „Fehler: Die gefundenen Snapshots befinden sich außerhalb des für Sie zulässigen Kontexts“

    Veröffentlicht am von — Keine Kommentare ↓

    Problem

    Manchmal lässt vssadmin es nicht zu, dass der Admin verbliebene Volumenschattenkopien (VSS) entfernt.

    Die Fehlermeldung sieht dann so aus:

    C:\> vssadmin delete shadows /for=c: /all
vssadmin 1.1 - Verwaltungsbefehlszeilenprogramm des Volumeschattenkopie-Dienstes
(C) Copyright 2001-2013 Microsoft Corp.

Fehler: Die gefundenen Snapshots befinden sich außerhalb des für Sie zulässigen Kontexts. Entfernen Sie sie mithilfe der
Sicherungsanwendung, von der sie erstellt wurden.

    Lösung

    Das Kommandozeilentool vssadmin ist seit Windows Server 2019 fehlerhaft – gefühlt wird es auch immer schlimmer.

    Die Alternative diskshadow mit der Kommando delete shadows all funktioniert hingegen (bisher) fehlerfrei.

    C:\>diskshadow
Microsoft DiskShadow Version 1.0
Copyright (C) 2013 Microsoft Corporation
Auf Computer: DC,  10.07.2025 11:32:35


DISKSHADOW> delete shadows all

    LDAPS (LDAP over TLS) auf DCs schnell testen

    Veröffentlicht am von — Keine Kommentare ↓

    Nach und nach wird LDAPS anstelle des unverschlüsselten LDAP auf Windows Domänen Controllern (DCs) eingeführt. Das ist auch sinnvollso. Das einzige was der Admin dazu tun muss, ist ein passendes (Domänen-) Zertifikat zu installieren. Das funktioniert auch bestens mit Wildcard-Zertifikaten, sofern man eine Domäne mit „Routingfähigem“ FQDN verwendet.

    Wann man nun ein Zertifikat hinzugefügt hat, wie testet man das denn auf die schnelle? Natürlich hat Microsoft kein Werkzeug dafür an Boad, aber OpenSSL to the rescue.

    Lösung

    Man verbinde sich einfach mit dem openSSL-Client mit dem LDAPS-Port

    openssl.exe s_client -connect DC.EXMAPLE.COM:636

    und warte auf den CONNECTED output. Wenn es den gibt, war die Verbindung erfolgreich.

    Die Ausgabe des TLS-Tests sieht dann (in etwa) so aus:

    C:\>openssl.exe s_client -connect DC.EXAMPLE.COM:636
Connecting to <IP>
CONNECTED(000001F8)
depth=1 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=RapidSSL TLS RSA CA G1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=*.EXAMPLE.COM
verify return:1
---
Certificate chain
 0 s:CN=*.EXAMPLE.COM
   i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=RapidSSL TLS RSA CA G1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 01 00:00:00 2026 GMT; NotAfter: Jun 29 23:59:59 2096 GMT
 1 s:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=RapidSSL TLS RSA CA G1
   i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov  2 12:24:33 2017 GMT; NotAfter: Nov  2 12:24:33 2029 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
ETZGLDCCBRSgAwIBAgIQAp8gNFzPD8DDuYunngMxzzANBgkqhkiG9w0BAQsFADBg
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3

[...]