OTP-Migration in Hub Vault: Henne-Ei-Problem beim Devolutions Account Login 🐣

Hallo,

ich kann Ihre Situation und die damit verbundenen Herausforderungen gut nachvollziehen.

Als mögliche Alternative könnten Sie die 2FA-Methode für den Devolutions Account auf Push-Benachrichtigungen umstellen. Die Push-Anfragen werden über den Bereich „Tools“ in der mobilen Anwendung verwaltet. Dadurch wären Sie nicht darauf angewiesen, das OTP aus dem Hub abrufen zu müssen, um sich erneut anzumelden.

Mit freundlichen Grüßen,

Danke für die schnelle Antwort.

Allerdings sehe ich dabei zwei Schwierigkeiten:

1. Die Mobile App setzt ein Smartphone voraus. Aus rechtlichen Gründen können wir bei Privatgeräten nur Angebote machen, keine Vorgaben. Das war bereits mit anderen Authenticator-Apps ein Problem. Nicht alle Mitarbeiter nutzen oder wollen eine Mobile App für dienstliche Zwecke verwenden.

2. Bei meinem eigenen Admin- und User-Account ist die Push-Benachrichtigung bereits einmal abgebrochen und musste neu eingerichtet werden. Was nur über einen OTP- oder E-Mail-Fallback möglich war. Das zeigt, dass Push-Benachrichtigungen selbst keine zuverlässige Standalone-Lösung sind, sondern ebenfalls einen Fallback benötigen.

Das eigentliche strukturelle Problem bleibt: Solange der Devolutions Account das primäre Login für Hub ist, gibt es immer ein potenzielles Henne-Ei-Problem zwischen OTP-Quelle und Hub-Zugang. Bisher hat die Workspace App dies mit der Authenticator Funktion gelöst.

Hallo,

vielen Dank für die zusätzlichen Details. Ich verstehe Ihren Punkt vollkommen.

Die Push-Benachrichtigung ist tatsächlich mit einem Fallback-Code gekoppelt. Beide Methoden werden gemeinsam konfiguriert und sind in der mobilen App im Bereich „Tools“ verfügbar. Sollte die Push-Funktion einmal nicht verfügbar sein, kann weiterhin der zugehörige Code verwendet werden.
Falls der Einsatz einer mobilen App in Ihrer Umgebung jedoch grundsätzlich keine geeignete Option ist, könnten Sie alternativ die 2FA-Methode über die E-Mail-Adresse des Benutzers konfigurieren. Dadurch hätten die Benutzer weiterhin eine unabhängige Fallback-Möglichkeit, ohne auf eine mobile Anwendung angewiesen zu sein.

Mit freundlichen Grüßen,

Danke für den schnellen Support. Einige Folgefragen zur Klärung:

1. Push Account Einträge erzeugen auch OTPs. Ist das der angesprochene Fallback-Code?
2. Werkzeug Mobile: Sind die OTPs in der mobilen Workspace App auch dann verfügbar, wenn der Login selbst hängt oder die Verbindung zu Hub unterbrochen ist?
   1. Denn dann haben wir weiterhin ein Henne Ei Problem. Noch schlimmer wenn wir SSO über Entra verwenden. Dann brauchen wir doch wieder Authenticator. Aktuell identifizieren wir neue Nutzer über Devolutions OTP Account Einträge. Praktisch auch für das Onboarding neuer M365 Nutzer.
3. Werkzeug Desktop: Fehlt diese Funktion in der Desktop App komplett, oder wird der Authenticator nach der Migration dorthin verschoben?
4. Wenn wir Devolutions Push nutzen, können wir keinen weiteren OTP mehr einrichten? Das war bisher ein hervorragender Fallback. Zumindest für Admin Accounts. Jetzt scheint es nur noch SMS und Mail Fallback zu geben.

Hallo,

ja, genau — wenn Sie eine Push-Benachrichtigung konfigurieren, wird gleichzeitig auch ein TOTP/OTP als Fallback eingerichtet. Der angezeigte Code dient also als Fallback, falls die Push-Benachrichtigung einmal nicht funktioniert.

Die zugehörigen OTPs bleiben in der mobilen Workspace App im Bereich „Tools“ verfügbar, auch wenn der Login hängt oder die Verbindung zum Hub unterbrochen ist. Dadurch kann der Code weiterhin zur Anmeldung verwendet werden.

Die Push-Benachrichtigungen selbst werden aktuell nur über die mobile Anwendung unterstützt. Für Workspace Desktop ist diese Funktion derzeit nicht verfügbar, und eine Unterstützung ist kurzfristig nicht geplant.

Wie erwähnt, wird bei der Einrichtung von Push automatisch auch ein OTP-Fallback mit eingerichtet.

Mit freundlichen Grüßen,