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-onlinehttps://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-september-2021-update/ba-p/2772210Da 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?

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.

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?

Email Einstellung der Standardauthentifizierung bei Microsoft

[gelöscht]

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

IT Support

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

IT.HNOmedic

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

IT Support

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....

IT Support

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.

IT Support

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.

IT Support

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.

IT Support

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

IT Support

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

[gelöscht]

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

IT Support

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

[gelöscht]

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

IT Support

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

IT Support

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.

IT Support

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:

Michael Heger

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.

Marc Diehl

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.

IT Support

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

IT Support

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.

IT Support

;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

« Vorherige Seite Nächste Seite »