-
Beiträge
-
-
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_tokenscheint 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 --debugerhalte ich folgende Fehlermeldung: https://pastebin.com/e38aNChRIch 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.xxxvon 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 -
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.
-
Hallo Tristan,
nach der Anleitung bist du vorgegangen?
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
-
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
-
-
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 993nach außen kommt.Grüße
Tristan
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.