Na ja, so einfach ist das "Problem" wohl doch nicht, denn sonst hätte man es bereits behoben. Wenn für den User "fdi" das Gedulden eine  "Akzeptierte Lösung" ist mag dies aber nicht für alle zutreffen. Was mich allerdings irritiert, ist das dieser Eintrag nun rechts oben ein grünes "Gelöst" Flag hat. Macht man sich hier die "Problem"-Lösung nicht etwas zu einfach?

Na ja, so einfach ist das "Problem" wohl doch nicht, denn sonst hätte man es bereits behoben. Wenn für den User "fdi" das Gedulden eine  "Akzeptierte Lösung" ist mag dies aber nicht für alle zutreffen. Was mich allerdings irritiert, ist das dieser Eintrag nun rechts oben ein grünes "Gelöst" Flag hat. Macht man sich hier die "Problem"-Lösung nicht etwas zu einfach?

Ich habe mir daher mal die tatsächliche Kommunikation per "curl" angeschaut. Die TLSv1.3 Kommunikation zur spica Infrastruktur läuft korrekt. Nach der Authentifizierung im "alten" Stil wird allerdings die alte SSL Session ID auf "stale" gesetzt und gelöscht, was den 403 Fehler bewirkt. Offenbar will man bei den Zugriffen nun nur noch 2FA zulassen. Wenn dies allerdings der Fall ist, hat sich das Management nicht ordentlich informiert, was andere (Google, Microsoft usw) hier bereits an Zeit und Geld investiert haben. Na ja, ob es sich für die Telekom lohnt, auch eine OAUTH2 Umgebung zu implementieren? Bosch wollte das auch mal, nutzt nun aber die Microsoft Lösung und hat dies auch unter einem Jahr dann zum Fliegen bekommen.

Statt der vollständigen OAUTH2 Lösung könnte man bei der Telekom auch das Applikation-Passwort für diese Aufgabe verwenden. Für den eMail-Zugriff nutzt man dies ja bereits. Wenn man dieses Passwort verwendet, könnte die "Problem"-Lösung tatsächlich schneller erfolgen, wenn die spica Infrastruktur Zugriff auf die eMail-Credentials bekommt.

Eventuell teilt jemand vom Telekom Team ja mal die aktuelle Denkrichtung mit, damit man abschätzen kann, wie lange der Ausfall wohl noch dauern wird.