Nachfolgend wird die allgemeine Anbindung zwischen oxaion ERP und Microsoft 365 bzw. Exchange Online erläutert.
Für die Anwendungsfälle des allgemeinen E-Mail-Versands sowie des E-Rechnungs-Mailscan (ERW) werden die Voraussetzungen und Konfigurationen erläutert.
Die Anleitung richtet sich an technische Ansprechpartner im Consulting oder beim Kunden, um die Anbindung selbstständig einzurichten.
Folgende Anwendungsfälle im oxaion ERP benötigen eine (jeweils eigenständige) Anbindung an Office 365:
Anwendungsfall | Wofür | Detailseite mit den konkreten Schritten |
|---|---|---|
Allgemeiner E-Mail-Versand | Versand von Belegen (Auftragsbestätigung, Rechnung, Lieferschein, …) per SMTP aus oxaion ERP heraus | |
E-Rechnungs-Mailscan (ERW) | IMAP-Abruf eingehender E-Rechnungen aus einem Postfach, sowie SMTP-Versand von Fehlerbenachrichtigungen aus demselben Prozess | Einrichtung und technische Einstellung ERW |
Anbindung mit Anwendungsberechtigung (App-only, Client Credentials)
Es gibt grundsätzlich unterschiedliche Möglichkeiten, wie sich oxaion ERP gegen ein Office-365-Postfach authentifizieren kann:
Variante | Postfach-Passwort erforderlich? | MFA/CA unterstützt? |
|---|---|---|
Legacy (Benutzername/Passwort, Basic Auth) | Ja | Nein |
OAuth mit Benutzername/Passwort (ROPC) | Ja | Nein |
OAuth mit Secret (App-only, Client Credentials) | Nein | Ja |
App-only ist für neue Einrichtungen die empfohlene Variante, aus mehreren Gründen:
Basic Auth wird von Microsoft für SMTP AUTH Client Submission schrittweise abgeschaltet (Bestandsmandanten: ab Ende 2026 standardmäßig deaktiviert; neue Mandanten bereits ab Dezember 2026 ohne Basic Auth).
ROPC (Resource Owner Password Credentials - das Postfach-Passwort wird gegen einen Token getauscht) scheitert, sobald für das Postfachkonto Multi-Faktor-Anmeldung (MFA) oder eine Conditional-Access-Regel (CA) greift.
Diese Anforderungen sind bereits heute der häufigste, produktiv auftretende Ausfallgrund (außerdem markeirt Microsoft das ROPC in der verwendeten Bibliothek (MSAL) zudem als veraltet).App-only authentifiziert sich hingegen mit einem eigenen Client Secret statt mit einem Postfach-Passwort - es ist dabei kein Benutzerkontext involviert und somit MFA/CA-robust.
Eine ausführliche technische Gegenüberstellung aller drei Varianten (inkl. Registry-Details für Entwickler) findet sich in Mail-Authentifizierung SMTP/IMAP: Varianten und Azure-Einrichtung.
Die Variante App-only mit Client Credentials ist im oxaion ERP verfügbar ab der Version 2021.5609.1.
Vorherige Versionen unterstützen den ROPC, ausschließlich für den ERW-Mailscan und ERW-Mailversand.
Der zentrale E-Mail-Versand über MAILSERVER_USER und MAILSERVER_PASSWORT zum Drucken von Belegen verwendete vorher kein OAuth-Verfahren.
Einrichtung in Azure/Entra ID
Für App-only ist eine App-Registrierung in Microsoft Entra ID erforderlich.
Im Azure Portal unter Microsoft Entra ID → App-Registrierungen eine neue Registrierung anlegen.
Unter Zertifikate & Geheimnisse ein neues Client Secret erzeugen. Wichtig: das Secret niemals im Klartext per E-Mail, Ticket oder Chat weitergeben, sondern sicher übergeben (z. B. Passwort-Tresor)!
Unter API-Berechtigungen → Office 365 Exchange Online → Anwendungsberechtigungen die für den jeweiligen Anwendungsfall benötigten Berechtigungen hinzufügen (
SMTP.SendAsAppund/oderIMAP.AccessAsApp, siehe Tabelle unten).Admin Consent durch einen Admin einholen (Häkchen „Administratorzustimmung erteilen" oberhalb der Berechtigungsliste).
Welche Anwendungsberechtigung für welchen Anwendungsfall:
Anwendungsfall | Benötigte Anwendungsberechtigungen |
|---|---|
Allgemeiner E-Mail-Versand |
|
E-Rechnungs-Mailscan (ERW) |
|
Der ERW-Mailscan verwendet dieselbe App-Registrierung sowohl für den IMAP-Abruf als auch für den SMTP-Fehler-Versand. Daher müssen beide Berechtigungen hinterlegt sein.
Fehlt IMAP.AccessAsApp, schlägt nur der IMAP-Abruf fehl, während der SMTP-Versand unabhängig davon funktioniert.
Einrichtung in Exchange Online
Eine Application Permission im Azure Entra ID allein genügt nicht! Zusätzlich muss im Exchange Online die App (Registrierung) für den Zugriff auf das konkrete Postfach autorisieren.
Ohne diese Berechtigung bleibt ein gültiger Token wirkungslos (der Connect scheitert z. B. mit 535 5.7.3 Authentication unsuccessful oder, beim Senden im Namen eines anderen Postfachs, mit SendAsDenied).
Die Berechtigung im Exchange Online muss vom Admin des Exchange durchgeführt werden.
Klassisches Modell: MaxilboxPermission für ServicePrincipal:
Install-Module ExchangeOnlineManagement Connect-ExchangeOnline New-ServicePrincipal -AppId <ClientID> -ObjectId <ObjectID> Add-MailboxPermission -Identity <Postfach> -User <ServicePrincipal> -AccessRights FullAccess
Wichtig: <ObjectID> ist die Object ID der Enterprise Application, nicht die der App-Registrierung selbst - dies ist eine häufige Fehlerquelle laut Microsoft-Dokumentation.
Die Berechtigung muss für jedes Postfach separat vergeben werden, auf welches die App (Registrierung) zugreifen soll (z. B. für jedes Absender-Postfach beim allgemeinen Versand, bzw. für das ERW-Postfach).
Eine Berechtigung auf einem Postfach erlaubt keinen Zugriff auf ein anderes.
Alternative — RBAC-Modell (neuer, aber aktuell nur für SMTP dokumentiert): kann mit oxaion ERP nicht verwendet werden.
Einrichtung im oxaion ERP
Sobald die Berechtigungen im Azure- und Exchange eingerichtet sind, kann die App-Registrierung mit App-only Berechtigung im oxaion ERP verwendet werden.
Dafür sind in der Registry die entsprechenden Werte zu hinterlegen für Tenant-ID, Client-ID und Client-Secret. Ist kein Secret hinterlegt, greift das ROPC, ohne Tenant- und Client-ID das Basic Auth.
Anwendungsfall | Registry-Schlüssel |
|---|---|
Allgemeiner E-Mail-Versand |
|
E-Rechnungs-Mailscan (ERW) |
bzw. (global als Default) |
Die konkreten Registrierungsschritte je Anwendungsfall stehen in den verlinkten Detailseiten oben E-Mail Versand und Einrichtung und technische Einstellung ERW .
Abgrenzung zu EWS (Exchange WebServices)
Für die Kalender-/Kontakt-Synchronisation per Exchange Web Services (EWS) existiert ein eigener, separater App-only-Zugriff mit eigener App-Registrierung (EXCHANGE_CLIENT_ID/EXCHANGE_TENANT_ID/EXCHANGE_SECRET).
Diese ist unabhängig von den oben beschriebenen Anwendungsfällen, es muss nicht dieselbe Azure App-Registrierung verwendet werden.