Schlagwörter: O365, OAuth2, PostMaster
-
AutorBeiträge
-
-
1. Juli 2022 um 14:19 Uhr - Views: 1623 #13392
Moin zusammen,
wir sind momentan dabei den Postmaster Dienst auf OAuth2 umzustellen. Mit einem lizenzierten Office365 Benutzer klappt das auch anstandslos und Otobo holt die Mails sofort aus dem jeweiligen Postfach.
Wir haben allerdings für unseren Servicedesk eine Shared Mailbox eingerichtet, auf die wir jetzt mit OAuth2 anscheinend keinen Zugriff mehr haben. Zumindest klappt die Anmeldung mit dem Benutzer an der Shared Mailbox über OAuth2 nicht.
Vor der Umstellung wurden die Mails über POP3S abgeholt und als Benutzer wurde ein Dienstbenutzer mit Zugriff auf die Shared Mailbox angegeben. Der Benutzername wurde so angegeben: Mail-Dienstbenutzer/Mail-Shared-Mailbox.
Gibt es in Otobo mit OAuth2 noch die Möglichkeit sich mit einem Benutzer an einer Shared Mailbox anzumelden?
Docker Installation, V 10.1
-
16. August 2022 um 10:12 Uhr #13556
Hallo Lenard,
damit es klappt, darfst du dich nicht mit mail@domain.tld/shared01 anmelden, sondern mit mail@domain.tld.
Wenn du von pop3s auf pop3oauth2 umstellst und zur Loginseite von Microsoft umgeleitet wirst, gibst du nicht das Passwort für mail@domain.tld/shared01 ein, sondern wählst ‚Mit einem anderen Konto anmelden‘ (oder ähnlich) aus. Anschließend nimmst du mail@domain.tld und das zugehörige Passwort.
Ich musste im Azure AD unter Authenifizierung diesen Punkt auswählen:
Konten in einem beliebigen Organisationsverzeichnis (beliebiges Azure AD-Verzeichnis – mehrinstanzenfähig)Ohne diese Auswahl kam die Fehlermeldung:
invalid_request:AADSTS50194: Application xxxxx is not configured as a multi-tenant application.
So konnte ich unsere 50-60 Shared Mailboxes (mit 2 Azure AD Anbindungen) umstellen.
Ciao
Tobi
-
12. Oktober 2022 um 11:06 Uhr #13997
Hallo Tobi,
Hallo zusammen,habe schon diverse Meldungen hier im Forum durch und antworte in dieser, weil sie am passendsten scheint.
Tobi, hast du einmal die offizielle Anleitung mit dem verglichen, was du durchgeführt hast um scheinbar erfolgreich die Anbindung zu schaffen? Irgendwelche zusätzlichen Schritte oder etwas anders gemacht?
Ich kämpfe auch damit, Otobo via IMAP mit einer Shared Mailbox in M/O365 zu betreiben. Ich bekomme es im Moment einfach nicht hin und weiss nicht, wo ich bei der Fehlersuche noch ansetzen soll – zu viele Faktoren. Firewall (eigentlich alles frei, aber SSLI), M365 Lizenzthemen (geht das überhaupt von MS-Seite?), Einstellungen Oauth / Enterprise-App-Registrierung, Einstellungen Otobo, …
Ich sehe am Tenant, dass eine erfolgreiche Anmeldung über OAuth stattfindet, aber die Abfragen laufen ewig bis in den Timeout und im Kommunikationsprotokoll steht:
Kernel::System::MailAccount::IMAPOAuth2
Something went wrong while trying to connect to 'IMAPOAuth2 => helpdesk@XXXXYYYYYZZZ.de/outlook.office365.com': Can't call method "authenticate" on an undefined value at /opt/otobo/Kernel/System/MailAccount/IMAPOAuth2.pm line 83.
Was bisher geschah:
- Otobo 10.1.5 manuelle Installation auf Ubuntu Server 22 LTS
- Erweiterung MailAccount-OAuth2 installiert und nach Anleitung konfiguriert.
- ClientID, Secret für Profil Custom1 (MicrosoftAzure) hinterlegt.
- AuthURL und TokenURL mit Tenant-ID angepasst
- IMAP an outlook.office365.com
- SCOPE: offline_access https://outlook.office.com/IMAP.AccessAsUser.All
- Anwendungsregistrierung im Tenant durchgeführt ebenso nach obenstehenden Anleitung bzw. all den Anmerkugen hier im Forum.
- Rechte an Anwendung vergeben: User.Read, IMAP.AccessAsUser.All, offline_access
- Admin Consent für die Rechte vergeben (eigentlich glaube ich nicht nötig)
- Redirect URL Typ „web“ nach Muster angepasst (https://<OTOBO address>/otobo/index.pl?Action=AdminMailAccount)
- Den Shared-Mailbox-Benutzer als Nutzer der Enterprise-App hinzugefügt
- Access tokens (used for implicit flows) sind aktiv
- Firewallseitig sollte freie Fahrt sein: HTTP(S)/IMAP(S) ans M/O365 Universum.
- Anmeldung und Freigabe nach Auswahl von „IMAPOAuth2“ im Postmaster-Eintrag hat funktioniert. Bei Auswahl dieses Protokolls und Speichern des Eintrags wird man zu Microsoft weitergeleitet. Dort dann zunächst Adminfreigabe erteilt. Dann mit der dem Benutzer der Shared-Mailbox (ohne \sharename@tld) angemeldet und danach Weiterleitung auf die Otobo-Mailaccount-Seite und Hinweis „Mail Account Updated“.
- Vorschläge aus dem Forum die getestet wurden / Workarounds ausprobiert
- IMAP/POP/MAPI/EWS aktiv für Shared Mailbox in ExchangeOnline
- In der Apache-Konfig PerlPostConfigRequire /opt/otobo/scripts/apache2-perl-preload_otobo_psgi.pl gesetzt (bzw. war da)
- Schreibweise der Mailbox im Postmaster-Eintrag mit helpdesk@tld.xzy und helpdesk\helpdesk@tld.xzy probiert
- Supported Accountype auf „Account in any organizatorial directory (multitanant)“ gesetzt (kein Unterschied zu single Tenant geht auch nicht)
-
16. November 2022 um 10:23 Uhr #14269
Nachtrag hierzu.
War doch der Klassiker. Auf der Firewall war IMAPS freigegeben. Für den Verbindungsaufbau wird aber wohl beides IMAP(143) und IMAPS(993) benötigt. Leider sehe ich in der Konfiguration nicht, welcher Port bzw. welches Protokoll genutzt wird.
Thema SMTP: leider nach meinen Recherchen kein Versand über eine in M365 bereitgestellte Shared-Mailbox via SMTP möglich ohne eine Lizenz zuzuweisen. Muss aber gestehen, dass ich an der Stelle etwas die Lust verloren habe mich weiter in die Thematik zu begeben. Versand läuft via lokalem Mailrelay.
-
-
-
AutorBeiträge
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.