[Tristan Ochs]

Moin Zusammen,

leider habe ich Probleme mit der OAuth2-Einrichtung für ein internes Ticketsystem (von außerhalb nicht erreichbar).

Ich bin bisher wie folgt vorgegangen:
1. Firewallfreigabe Ports 80, 443 vorerst zu * sowie 143 + 993 zu outlook.office365.com
2. Download & Installation des Pakets von https://ftp.otobo.org/pub/otobo/packages/, da aktuell der Download im OTOBO bei mir nicht funktioniert (fehlende Firewallfreigabe?)
3. Anlegen einer Unternehmens-App im Azure AD, Zuweisen des richtigen Benutzers
4. Anlegen des Clientschlüssels, Kopieren des „Werts“
5. Gewähren folgender Berechtigungen + Administratoreinwilligung

6. Eintragen von Tenant-ID, APP-ID und Zugriffsschlüssel im OTOBO
7. Erfolgreicher Login mit dem Nutzer it-ticket@*********.*** und IMAPOAuth2 im Postmaster
8. Testweise Zuweisung einer Business Premium Lizenz zum Postfach (vorher Shared-Mailbox ohne Lizenz)

Leider hat das alles nicht geholfen. Mit dem Select Befehl SELECT * FROM auth_token scheint nur ein „refresh“-Token erstellt zu werden, niemals aber ein „access“-Token.

Beim Ausführen von bin/otobo.Console.pl Maint::PostMaster::MailAccountFetch --force-pid --debug erhalte ich folgende Fehlermeldung: https://pastebin.com/e38aNChR

Ich weiß langsam nicht mehr, wie ich hier noch vorgehen soll. Das einzige was mir hier etwas komisch vorkommt, ist "Login", "it********ticket\@xxxxxxx.xxx". Während das @xxxxxxx.xxx von mir stammt, sind die Sterne zwischen it und ticket „von alleine“ dort. Normalerweise lautet die Adresse nämlich it-ticket@. Bei SMTP bereitet das Ganze allerdings keine Probleme, nur bei IMAP habe ich Probleme.

Ich hoffe jemand hat hier vielleicht eine Lösung. Nach 2 Tagen der Fehlersuche verzweifle ich langsam :-| .

Grüße
Tristan

[Tristan Ochs]

Noch ein Nachtrag:

Hier nochmal aus der Sicht des Systemprotokolls:

In unserer Firewall habe ich gerade auch noch einmal nachgeschaut – dort versucht der OTOBO-Host keine Verbindung über IMAP oder sonstiges zu Microsoft aufzubauen, lediglich per NTP (123) / HTTPS (443).

Zum OTOBO hin baut nur mein PC aktuell eine HTTPS-Verbindung (443), hier steht im Firewalllog denied – „Could not associate packet to any connection.“ – obwohl die Weboberfläche normal aufrufbar ist (per HTTPS bzw. HTTP mit anschließender direkter Weiterleitung auf HTTPS). Vielleicht ist das Logging-Level der Firewall auch nicht umfangreich genug eingestellt.

Weiß sonst jemand, welche notwendigen Ports noch nicht freigegeben sein könnten?

Danke vorab.

[marcel-graf]

Hallo Tristan,

nach der Anleitung bist du vorgegangen?

https://doc.otobo.org/manual/admin/10.1/en/content/communication-notifications/postmaster-mail-accounts.html#pop3-and-imap-oauth2-authentification

Wir nutzen Otobo in einer Docker installation auf einer Ubuntu Server VM,  aktuell über http (kein https), da das System aktuell nur intern ereichbar sein soll.  Der Ubuntu Server selbst hat Zugriff auf das Internet.

Bei dieser konstellation ist aber zu beachten, dass man beim hinzufügen des OAuth2 Kontos dann nach dem man die Authentifizierungsdaten eingeben hat, in der URL von https auf htp ändern muss.

Ich habe das im Forum irgendwo schon mal geschrieben.

Gruß Marcel

 

 

 

[Tristan Ochs]

Hallo Marcel,

erstmal Danke dir für deine schnelle Antwort ;-).

Ich bin genau nach der Anleitung vorgegangen – bis auf eine Abweichung, die ich bereits in einem Forenbeitrag gelesen habe: Während der Anleitung wird eine zweite Anwendung erstellt, das wollen wir (vermutlich) ja nicht, da sich dann die Einrichtungsschritte auf zwei Anwendungen verteilen und keine „richtig“ funktioniert. Aber auf die vorhandene zuerst erstellte Anwendung habe ich die Schritte 1 zu 1 angewendet.

Ich hab aber eine Theorie, woran es jetzt liegen könnten – das muss ich aber erst noch ausprobieren, sobald der zuständige Kollege, welcher unsere Firewall betreut, Zeit hat. Eventuell führt nämlich ein Geoblocking unserer Firewall dazu, dass der IMAP-Port zu ist. Das wäre natürlich extremst ärgerlich, da ich extrem lange nach dem Problem gesucht habe.

Ich melde mich auf jeden Fall, wenn ich weiß, ob es jetzt funktioniert oder nicht.

Grüße
Tristan

[Tristan Ochs]

Moin Zusammen,

ich bin euch ja noch den Grund schuldig, warum es nicht funktioniert hat: Der Kollege, welcher die Firewall-Regel angelegt hat, hat leider einen winzigen Fehler in der Konfiguration gemacht, weshalb es nicht funktioniert hat. Mit dem Geoblocking der Firewall hat es nichts zu tun gehabt.

Mein „heißer“ Tipp daher an alle: Probiert erstmal, ob ihr mit telnet outlook.office365.com 993 nach außen kommt.

Grüße
Tristan

[Autor]

Beiträge