Gelöst
Zugang über CalDAV und CardDAV nicht mehr möglich
vor 10 Tagen
Ich hatte lange über den Zugang https://spica.t-online.de/ Zugang zu meinem Kalender und Adressbuch via Benutzername (ohne t-online.de) und das Zugangspasswort. Seit einigen Wochen ist dies nicht mehr möglich. Ich habe auch die 2FA konfiguriert, was aber ebenfalls zu keinem Erfolg geführt hat. Kalender und Adressbuch sind über die Webseite noch zugreifbar, nicht aber über den bisherigen Weg.
Frage: Wie muss der Zugang nun eingerichtet werden?
260
0
6
Das könnte Ihnen auch weiterhelfen
vor 2 Stunden
26
0
3
439
0
22
vor 11 Minuten
9
0
0
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.

Angebote anzeigen
Aktuelle Telekom Angebote für Mobilfunk (5G/LTE), Festnetz und Internet, TV & mehr.

Akzeptierte Lösung
akzeptiert von
vor 10 Tagen
Ist bekannt, einfach gedulden bis das "Problem" behoben ist
https://telekomhilft.telekom.de/conversations/e-mail/syncplus-caldavcarddav-http-403-forbidden/6a533d9e0b9b3713cc255ef8?commentId=6a533fdcfdab4d20d4667f81
5
von
vor 9 Tagen
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.
von
vor 9 Tagen
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.
Das Thema wird trotzdem weiter verfolgt und man arbeitet an einer Lösung des Problems, das hat nix mit dem Beitrag und der Lösungsmarkierung darin zu tun.-
Die Lösungsmarkierung zeigt schnell den aktuellen Stand und auch den Hinweis auf den "Sammelthhread" so dass jeder andere der das gleiche Problem hat schnell erkennen kann was er "tun kann".
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von