Email Einstellung der Standardauthentifizierung bei Microsoft

Question

Microsoft wird seine Standardauthentifizierung im Laufe des Jahres einstellen. Ab dem 1. Oktober 2022 wird die Standardauthentifizierung für die Protokolle Outlook, EWS, RPS, POP, IMAP und EAS in Exchange Online deaktiviert. SMTP-Authentifizierung wird ebenfalls deaktiviert, wenn sie nicht verwendet wird.
https://docs.microsoft.com/de-de/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-september-2021-update/ba-p/2772210

Da die Anmeldung der IMAP und SMTP Verbindungen zu Microsoft Exchange Servern betroffen ist, müsste tomedo die moderne Authentifizierung in den Emailkonten übernehmen, wie das bei MAC OS schon umgesetzt ist: https://support.apple.com/de-de/guide/deployment/dep158966b23/web
 

Bis wann plant zollsoft die Integration der modernen Authentifizierung in tomedo?

Answer 1

Die Authentifizierung über OAuth2.0 (moderne Authentifizierung) ist bereits implementiert und wird vorrausichtlich bis zum 31.05.2022 zur Verfügung stehen. Gerade testen wird noch intern und konfigurieren für verscheidene Provider.

Comments

Perfekt. Herzlichen Dank für die rechtzeitige Umsetzung, damit bleibt genug Zeit zum Testen.

---

Sehr geehrter Herr Huster,

die Implementierung ist da - es gibt für den Provider (hier Office 365) keine hinterlegte Konfiguration.

Wo kommt diese her? Wo wird das eingestellt oder ist das noch nicht von zollsoft umgesetzt?

Besten Dank für eine Info.

---

Sehr geehrter Herr Mildner,

wir arbeiten derzeit noch an Konfigurationsproblemen mit den verschiedenen Providern von Microsoft (daher die Fehlermeldung) und werden zeitnah eine Lösung zur Verfügung zu stellen.

Freundliche Grüße,

Constantin Huster

---

Hallo Herr Huster,

nachdem für Office365 noch kein Auth2.0 in tomedo hinterlegt ist (wir das Verfahren aber getestet haben) ist ein Rücksprung zur Standardauthentifizierung nicht möglich:

An der Kombi Email/Passwort liegt es nicht, dass haben wir bereits xfach getestet und über andere Wege mit Login erfolgreich abschliessen können. Mit dem Rücksprung auf die Standardauthentifizierung hat sich irgendetwas aufgehängt - mit der Folge, dass kein Zugriff mehr zur Aktualisierung der Emails stattfindet.

Alle anderen Postfächer, die wir nicht mit Auth2.0 getestet haben, funktionieren einwandfrei.

Microsoft hat die moderne Authentifizierung bereits standardmäßig auf allen Postfächern aktiviert - über das Admin panel Panel haben wir das aktuell aber wieder deaktivieren können.

Haben Sie einen Workaround? 

---

Wir haben inzwischen die Log-Protokollierung von Microsoft erhalten, der Account meldet sich bei Microsoft gar nicht an.

Lediglich der Login über Webbrowser ist erfolgreich und registriert.

---

Inzwischen sind leider alle Accounts offline, kann also nicht an der Einzeleinstellung liegen.

Microsoft aktiviert gerade bei allen Office 365 Anwendungen zwangsweise für 2-3 Tage die moderne Authentifizierung. Obwohl abgeschaltet, scheint die Standardauthentifizierung nicht mehr zu funktionieren.

Bitte dringend OAuth2.0 für Office365 als Template in tomedo hinterlegen.

---

Liebes tomedo Team,

wir hatten schon vor Monaten auf die Umstellung hingewiesen. Microsoft hat kurzerhand für 48 Stunden die Standardauthentifizeriung abgeschaltet. Leider funktioniert aktuell das vorzeitige Rücksetzen vor der Frist nicht bei unserem Kunden. Bitte rüsten Sie schnellstens das OAuth2.0 Template nach!

---

Hallo Herr Mildner,

ich arbeite an einer Lösung. Leider habe ich auch mir Änderungen von Microsoft zu kämpfen. Ich werde mich spätestens morgen wieder dazu melden und Ihnen mitteilen wann ein Lösung verfügbar ist.

Freundliche Grüße,

Constantin Huster

---

Vielen Dank. Es ist saublöd, wenn Microsoft Fristen angibt und dann mal testweise die Zugänge abschaltet, damit man auf die Änderung aufmerksam wird. Wir haben die  OAuth2.0 über das Admin Panel abgeschaltet, mit der Folge dass gar nichts mehr geht (IMAP teilaktiviert - geht auch nicht). Wir sind gerade mit allen Support Teams am Arbeiten, weil jetzt minutenweise europaweit immer meht unserer Kunden betroffen sind.

Ich halte sie ebenso auf dem Laufenden.

---

Über die Konsole in Office 365 haben wir die Standardauthentifizierung wieder aktivieren können.

Es funktioniert inzwischen wieder überall, nur nicht in tomedo. Wieso gibt es bei den Konteneinstellungen nun 2 verschiedene Passwörter zu hinterlegen, die aber nicht greifen und plötzlich verschwinden?

Kann da doch etwas an den Settings hängen?

---

Das ist ein GUI-Bug und hat nichts mit den Einstellungen zu tun. Man kann nur ein Passwort je Acount hintelegen. Wenn Sie von Passwort zu OAuth2.0 wechseln und dann wieder zurück sollte der GUI- Bug weg sein. Eventuell noch mal den Port und die Verschlüsselungsmethode prüfen, die kann für OAuth2.0 ander sein als für Passwort.

Freundliche Grüße,

Constantin Huster

---

Wenn das ein GUI Fehler ist, ist die Fehlerquelle ausgeschlossen.

Wir haben folgendes Lagebild:

Der Server wurde im Rahmen der wöchentlichen Wartung gestern Abend neu gebootet.  

Der Email Ausfall muss daher rühren.  Eventuell sind Sicherheitstoken durch den Reboot abgelaufen.

Die Telemetriedaten und Log Dateien zeigen, dass sich der OTK über Standard Authenthifizierung  anmeldet und versendet. Gleicher Acoount, gleiche Settings.

Von Tomedo gibt es in den Log Dateien bei Microsoft keinerlei Hinweis auf einen fehlgeschlagenen Anmeldeversuch, obwohl in Tomedo ein Authentifizierungsfehler erscheint.  Leider ist im Tomedo log nichts genaueres zu finden.  

Mit der Neuanmeldung Standart AUTH scheint es nicht zu klappen. Eingeloggte Clients bleiben weiterhin verbunden und senden und empfangen.

Wir haben überprüft, ob die IP Adresse blacklistet ist.  Negativ. Zur Sicherheit die IP gewechselt.  Negativ.   Eine Annahmerichtlinie ist nicht hinterlegt.  Sonst könnte der OTK aus Ihrem Hetzner Data Center auch nicht senden.

Wir sind etwas ratkos. Microsoft verweist aktuell auf die Verfahren der 48 Stunden Ubterbrechung.  Wir haben entsprechend alles umgesetzt.  Negativ.  

Eventuell ist in Azure die Rechte Federation noch nicht synchronisiert.

---

Seit 22.30 Uhr loggen sich die Accounts wieder ein. Das lag definitiv an Microsoft. Wir hatten inzwischen IMAP Konten außerhalb von Office 365 testweise angehängt, die taten einwandfrei.

Wir haben unendlich viel über die Powershell und die GUI im Admin Bereich an Einstellungen probiert. Da das aber so pünktlich wieder funktionierte, haben wir entweder eine Synchronisation der Server im Verdacht oder die abgeschaltete Frist ist vorüber.

Wir sind Ihnen sehr dankbar, wenn OAuth2.0 bald funktionieren könnte. Wir rechnen da mit weiteren Komplikationen bis das implementiert ist und wollen das rechtzeitig vor den bayerischen Ferien und an einem Wochenende testen und umstellen, wenn nicht  medizinischer Hochbetrieb ist.

Diese "Testunterbrechung" von Microsoft ist völlig aus dem Ruder gelaufen und auch unsinnig gewesen, da wir frühzeitig auch bei tomedo, zu OAuth2.0 angefragt hatten und vorbereitet sind.

Besten Dank wie immer für das wirklich immer schnelle Feedback auf unsere Fragen.

---

Schön zu lesen, dass sich die Account wieder einloggen können. Meine Testauccounts gehen leider noch nicht  wieder (allerging bei keiner Anwendung, die ich versuch habe. Daher sehr wahrscheinlich ein Microsoft Problem). Danke für Ihr feedback zu dem Thema. Ich weiß aus eigenen Erfahrung wie komplex sich die Konfigurationsarbeit bei solchen Problem gestalten kann. Ich versuche OAuth2.0 so schnell wie möglich umzusetzen und halte Sie auf dem laufenden.

Freundliche Grüße,

Constantin Huster

---

Die Änderungen am Code für OAuth2.0 mit Microsoft sind abgeschlossen (Problem ließen sich nicht durch Konfiguration allein Lösen). Das läuft jetzt noch eine Runde durch interne Testing und kommt dann einem der nächsten updates.

Die Freundliche Grüße,

Constantin Huster

---

Guten Morgen zusammen,

in welcher Tomedo-Version wird OAuth für Microsoft umgesetzt sein?

Freundliche Grüße

Eric Schindler
HNOmedic

---

Hallo Herr Schindler,

wir sind inzwischen auf Version 1.113.0.17 - da geht es noch nicht. Im Changelog für die nächste Version ist zu OAuth nichts vermerkt.

Viele Grüße

Michael Mildner
GEMIFYE / MET.online

---

Hallo Herr Huster,

wir haben vorgestern beim Kunden endlich unter Tomedo-Client v1.114.0.17 und Server-Tools 114-s544 bei 2 von 4 Emailkonten OAuth 2.0 eingerichtet. Das hat einwandfrei funktioniert, inkl. Aufruf über das Office 365 Portal. Der Zugangscode wurde erfolgreich übermittelt. Danach haben wir einen Verbindungstest unternommen, der erfolgreich abgeechlossen wurde.

Heute ruft uns die Praxis an, dass auf keinem Konto Emails empfangen werden und auch nicht versendet werden. Wir haben in den Log-Files keine Fehler entdeckt. Nun haben wir eines der beiden Konten wieder aus Passwort Authentifizierung umgestellt und sofort funktioniert es wieder. Der Fehler hängt also augenscheinlich mit der OAuth2.0 Umstellung zusammen.

Haben Sie eine Idee, was den Versand und Empfang blockt?

---

Hallo Herr Mildner,

ich habe leider noch keine guten Neuigkeiten für Sie. Nachdem mit einem Microsoft-Exchange-Testkonto alles funktioniert hatte, haben wir gerade ein ähnliches Problem mit einem anderen Testkonto. Verbindungstest geht, E-Mail-Abruf geht, aber E-Mail-Versand geht nicht. Es würde mich interessieren, ob das Abrufen und das Versenden bei Ihren Konto schon einmal funktioniert hat. Zur Zeit gehe ich von einem Konfigurationsproblem des Microsoft-Exchangeservers aus. E-Mail-Konten andere Microsoft Dienste sind nicht betroffen. Wenn Sie Hinweise zur Konfiguration haben sind diese sehr willkommen.

Freundliche Grüße,

Constantin Huster

---

Guten Morgen Herr Huster,

also weder Abruf noch Versand funktionieren. Die regulären APP Einstellungen in der Admin Konsole von Office 365 haben wir überprüft.

Wir versuchen heute aus den Unmengen der Office 365 Logs das Problem am Exchangeserver herauszufiltern. Wir geben Ihnen Bescheid.

Viele Grüße,

Michael Mildner

---

Guten Morgen zusammen,

ich möchte ergänzen, dass wir gestern den gleichen Fehler bei unserer Exchange-Konstellation entdecken konnten. Mails empfangen geht, versenden nicht - OAuth Code Anforderung funktionierte beim zweiten Anlauf problemlos. Verbindungstest war erfolgreich.

Viele Grüße

Eric Schindler

---

Wir haben nun im Azure Active Directory Admin Center unter Anmeldeprotokolle alle Anmeldungen überprüft. Die beiden betreffenden Accounts haben sich erfolgreich identifiziert. Es gibt hierzu keine Fehlermeldung. An der Identifizierung scheint es nicht zu legen, sonst würde wahrscheinlich auch der Verbindungstest nicht funktionieren.

Wir suchen weiter....

---

Leider doch zu früh gefreut, es gibt einen Anmeldefehler

Leider weist die Analytik von Azure aktuell keine genaueren Protokolldetails aus. Es muss also doch mit der Identifizierung zu tun haben.

---

Noch ein Nachtrag auf einen ersten Verdacht.

Für die tomedo APP Registrierung hat der normaler Nutzer in Office 365 keine Rechte. Dafür wird der globale Admin benötigt. Es sieht aber danach aus, dass auch dieser globale Admin sich die Rechte auf die einzelnen Office 365 Konten erst "granten", also hierfür berechtigen muss. Der Zugangscode ließ sich nur über das Adminkonto erzeugen. In dieser Kombination ist der Fehler wahrscheinlich zu suchen. Wir sind aber auch noch nicht ganz schlau.

---

So,unser technischer Support konnte fehlende Rechte ausmachen.

Dazu müssen Sie ins Azure Active Directory Admin Center wechseln (Einstieg über das Admin Portal von Office 365) und dort auf die Unternehmensanwendungen wechseln. Bei uns hat tomedo auch die Anwendung mit dem Namen "tomedo" eingetragen. Es reicht nicht aus, den Zugangscode über das zentrale Adminkonto einzurichten!

Dann die Rechte zuweisen. Eines der Problemkonten kann nun bereits senden und empfangen. Also alle die Probleme haben, sollten in diesem Bereich suchen.

---

Danach  ggf. nochmal den Prozess "Zugangscode anfordern" in tomedo wiederholen.

---

Sehr geehrter Herr Huster,

leider muss ich mit dem leidigen OAUTH2 Thema nochmal auf Sie zukommen.

Inzwischen haben wir fast alle Email-Accounts umgestellt, klappt prima.

ABER:
wir haben ein Emailkonto, dass alle automatisierten Emails wie Terminerinnerungen usw. versendet. Dieses ist ein no-reply@postfach.xyz Konto, auf das man nicht antworten kann. Dieses wird über "Senden als / send as" über das Hauptkonto der Praxis angesprochen:

Über die Passwort Authentifizierung klappt das super - das Konto wird aus der zweiten Zeile "E-Mail-Adresse" angesprochen und Emails darüber versendet (auch über das Backend des OTK1 läuft das ebenso noch gut/Basic Authentification!). Aber über OAUTH2.0 klappt das nicht.
Die Codevergabe läuft einwandfrei und es funktioniert auch eine Anmeldung die in Azure Directory ankommt, aber über OAUTH2.0 läuft das "Senden als" bei tomedo nicht.

In Azure wird folgender Fehler ausgeworfen:

AADSTS50126

InvalidUserNameOrPassword - Error validating credentials due to invalid username or password.

Nach 2 vergeblich langen Tagen in Azure kommen wir nicht weiter. Die Auswertung der Email Logs von tomedo ist dürftig, eine Debug Möglichkeit haben wir nicht in tomedo.

 

In GITHUB haben wir einen Hinweis gefunden, dass möglicherweise falsche Parameter zur App-Anwendung übermittelt werden - das wäre dann wieder in Ihrem Code, den wir nicht einsehen können.

 

Könnten wir uns des Themas bitte nochmals annehmen? Ich öffne parallel ein Ticket bei Microsoft.

 

Danke und freundliche Grüße aus München

Michael Mildner

 

---

Sehr gehrter Herr Mildner,

danke für die ausführlichen Informationen. Ich schaue mir da an und versuche das Problem nachzustellen, um zu schaue was ich da tomedo-seitig machen kann. Ich melde mich morgen wieder dazu.

Freundliche Grüße,

Constantin Huster

---

Herzlichen Dank,

Microsoft First Level Support hat sich heute schon aus einem Call Center in Indien bei uns gemeldet. Mangels sprachlicher Verständigung ist das erstmal gescheitert. Ich hoffe, dass wir da bald mit jemanden bei Microsoft reden können, der Deutsch oder Englisch ausreichend spricht.

Viele Grüße

Michael

---

Sehr geehrter Herr Mildner,

ich habe das Problem nicht vergessen, habe aber noch keine Lösung gefunden. Ich halte Sie auf dem laufenden. Bitte sagen Sie mir bescheid wenn Sie mit dem Support von Microsoft geredet haben.

Freundliche Grüße,

Constantin Huster

---

Sehr geehrter Herr Huster,

vielen Dank für den Zwischenstand. Wir hatten inzwischen den Microsoft Support per Remoteviewer auf tomedo gelassen, die haben sich alles schön aufgezeichnet. Das Problem ist jetzt nach Redmond eskaliert - wir warten von dort auf eine Rückmeldung.

Aktuell läuft es wieder auf auf Basic Authentification. Am 01.10. will Microsoft umstellen, wir haben aber gestern über einen anderen Systempartner bei wiederum einem ganz anderen System gehört, dass Microsoft anscheinend die Frist bis Jahresende verlängern will. Bestätigt haben wir das bisher aber nirgendwo vorgefunden oder ist uns mitgeteilt.

Nur um niemanden zu erschrecken, zusammengefasst: OAUTH2.0 läuft auf tomedo einwandfrei - nur Alias Versenden funktioniert aktuell nicht über OAuth2.0.

Also suchen wir alle weiter :-)

Beste Grüße,

Michael Mildner

---

Hallo Herr Huster,

nach mehrfach täglichen Support Calls seit 29.09. und einer "Begutachtung von tomedo" per Remotesession hat Microsoft uns jetzt lapidar mitgeteilt:

Use of the shared mailbox is an expected error via smtp protocol

As per Basic Authentication Deprecation in Exchange Online – September 2022 Update - Page 2 - Microsoft Tech Community, we will not be disabling or changing any settings for SMTP AUTH.

Auf gut deutsch heißt das nun für unsere Exchange Server und die unserer Kunden: OAuth2.0 funktioniert, ist aber nicht notwendig, da die Basic Authetifizierung auch über die seit 2 Jahren genannten Ablaufdaten möglich ist.

Man kommt sich da wirklich leicht vergackeiert vor....

Was nicht funktioniert, stellen wir jetzt auf Basic Authentification zurück, was funktioniert bleibt auf OAuth2.0. Und alles soll ohne eine Enddatum laufen. Wir haben es nun schriftlich von Microsoft, per Email und als offizielles Partner Support Ticket. Ob das nun für alle Kunden gilt???

Wir schließen das Ticket bei uns, weil ja nun alles beim Alten bleibt ;-)

Danke für Ihre Bemühungen.

 

---

Seit heute Nachmittag (17.04.) sind alle unsere Microsoft Office 365 Email-Konten in tomedo offline (nicht verifiziert) und lassen sich auch über Zugangscode nicht mehr online verbinden.

Es gibt einen Fehler im Exchangeserver bei Microsoft Status, der dazu nicht wirklich passt. Hat noch jemand ähnliche Probleme? Nach dem Erzeugen des Zuagngscodes kommt folgende Fehlermeldung:

---

Ja, der Fehler ist bei allen unseren Kunden aufgetreten. Seit gestern ca. 16 Uhr, findet Microsoft die tomedo-App mit der obigen ID nicht mehr, obwohl diese im Appverzeichnis von https://entra.microsoft.com zu finden ist.

Auch das Löschen dieser App hat nichts gebracht. Normal sollte beim Zugriff eine Meldung kommen, diese App neu einzutragen, geht aber nicht.

Zur Zeit noch keine Lösung.

---

Ich kann das Verhalten bestätigen. Seit heute Morgen bekommen wir den selben Fehler wie  Michael Mildner bei unseren Kunden mit O365, wenn wir versuchen, das oAuth erneut zuzuweisen.

---

Hallo an die Herren Heger und Diehl,

können Sie mir Ihre Softwareversionen von tomedo nennenß
Wir hatten bei unserem Kunden vorgestern tomedo und Server Version upgedatet.
Welche Versions Nummern setzen Sie ein? Die App bei uns ist 1.141.013.
Und haben schon ein genaueres Fehlerbild nach 6 Stunden Suche.

Aktuell haben wir ein Ticket bei zollsoft geöffnet, ob im API Code etwas verändert wurde.

Wir haben auch alle Azure Settings und Protokolle untersucht, da ist nicts auffälliges dabei. Wenn tomedo die API nicht geändert hat, dann ist das ein Microsoft Thema....

Parallel versuchen wir uns durch Microsoft Support Welt durchzuschlängeln. Das ist komplex. Das Thema ist im ENTRA System von Microsoft verortet und wird vom Azure Support gemanagt. Selbst wir als Partner haben aktuell Probleme ein Ticket zu dem Case zu öffnen. Wir sind da gerade dran. Hilfeich für uns wäre, wenn Sie Ihre Fehlermeldung posten könnten (ID's bitte schwärzen). Dann können wir darauf verweisen, dass das kein singuläres Thema ist.

Aktuell hat das Thema bei uns allerhöchste Prioritätsstufe erhalten.

Viele Grüße

Michael Mildner

---

Hallo Herr Heger,

können Sie bitte im ENTRA Azure Portal bei der registrierten Anwendung fur SMTP AUTH in der Anmeldedisgnose bei sich überprüfen, ob Sie den gleichen Fehler wie wir erhalten:

 

Fehlercode: 700016

Nachricht: Die Anwendung mit dem Bezeichner „{appIdentifier}“ wurde im Verzeichnis „{tenantName}“ nicht gefunden. Dies kann auftreten, wenn die Anwendung nicht vom Administrator des Mandanten installiert wurde oder wenn sie von den Benutzern des Mandanten keine Zustimmung erhalten hat. Unter Umständen haben Sie Ihre Authentifizierungsanforderung an den falschen Mandanten gesendet.

Aktion: Die Anwendung wurde nicht im Verzeichnis/Mandanten gefunden. Dies kann auftreten, wenn die Anwendung nicht vom Administrator des Mandanten installiert wurde oder wenn sie von den Benutzern des Mandanten keine Zustimmung erhalten hat. Unter Umständen haben Sie den Bezeichnerwert für die Anwendung falsch konfiguriert oder die Authentifizierungsanforderung an den falschen Mandanten gesendet.

Das betrifft  den Azure Fehler AADSTS700016: Application with identifier not found in the directory
Das würde bedeuten, dass die Unternehmensanwendung mit dem Azure ID Abo nicht mehr verknüpft wäre und daher die SAML authentication an der Entra ID scheitert und in Folge dessen der Token nicht ausgestellt wird.

Nachdem es nach meiner Rechnung oben nun 3 unterschiedliche Azure IDs betrifft, glaube ich nicht, dass alle von uns gleichzeitig etwas umkonfiguriert haben.

Es gäbe noch den Fehler, dass tomedo oder Microsoft einen Fehler beim Rückschreiben der URL haben. Mein Bauchgefühl sagt mir aktuell, dass der Fehler bei Microsoft liegt.

Update folgt.

---

;Müssen korrigieren, nicht SAML token, sondern OAuth 2.0 token macht das Problem:
https://learn.microsoft.com/de-de/entra/identity-platform/v2-protocols

---

Wir schauen uns das Problem gerade von zollsoft Seite an ob wir da was machen können. Wir geben ihnen bescheid wenn wir wissen wo das Problem liegt.

---

Wir haben den Fehler gefunden und wir werden heute im Laufe des Tages ein HotFix Update (Client und Server) dafür freigeben (Version noch nicht bekannt. Wird noch gebaut). Danach muss für jedes Mail Konto was in tomedo via Mircrosoft laufen ein neuer OAuth 2.0 Token genneriert werden.

Problem liegt leider auf Seiten von Microsoft. Diese haben unsere Token für die Anbindung gelöscht. Diese konnten auch nicht wiederhergestellt werden duch den Support von Microsoft. Deswegen haben wir gestern Abend neue Tokens angelegt und diese müssen jetzt in einem neuen tomedo Client und im tomedo Server eingebaut.

---

Herzlichen Dank!

---

Hallo Herr Jentsch,

können Sie das Fehlerbild noch etwas erläutern, damit wir vorbereitend tätig werden können?

Die von Ihnen o.g. "gelöschten Tokens" beziehen sich auf Schlüssel der tomedo App selber oder token, die sich über die ENTRA Unternehmensanwendung erstellen lassen? Heißt das, dass die Unternehmensanwendung neu angelegt werden muss? Soweit ich Herrn Heger oben verstanden habe, wurde dieser Schritt schon erfolglos unternommen.

Falls Arbeiten parallel an ENTRA in Azure vorgenommen werden müssen, würen wir diesbezüglich schon gerne loslegen, um dann mit dem Hotfix-Update die Email Accounts zügig wieder online zu bekommen. Ich habe vorhin beim Kunden nachgesehen, da sind bereits hunderte von Emails in den Postausgängen, die nicht übermittelt werden.

Danke 

---

Bug Fix Version v1.142.0.3 ist freigegeben danach müssen nochmal die OAuth Keys in tomedo neu erzeugt werden. Wir werden nochmal ein Extra Post in Forum erstellen und nochmal Kunden die Sich in Support gemeldet hatten Informieren.

---

Sehr gerrne. Ich versuche es einmal grob zu erklären.

wir mussten von unserer Seite im Microsoft Entra-Admin Center eine neue App registrieren weil bei der alten tomedo App die Tokens für die Anbindung kaputt waren.
Wir konnten mit Hilfe vom Support von Microsoft es nicht wieder reparieren. Deswegen haben wir einfach eine neue App registiert und die neuen client_id und neue Seckrets in den Server und in den tomedo Client eingebaut. Damit wir einen neuen Unternehmensanwendung dort anlegen können.
Somit konnten wir schneller eine Lösung bereitstellen als der Support von Microsoft.
Bei unseren Test mussten wir nichts weiteres bei uns Einstellen im Entra Admin Center. Und wir konnten wieder Mails versenden und empfangen. Sowie auch bei einem Kunden mussten wir nur die Tokens neu erzeugen und es ging wieder.