Welche Anmeldeverfahren unterstützt der Web-Client 2.0?

Der Web-Client 2.0 unterstützt sechs Anmeldeverfahren – deutlich mehr als der Web-Client 1.0 (Legacy), der nur die Standard-Anmeldung beherrschte. Voraussetzung ist jeweils, dass das Verfahren auf dem Enterprise Server zugelassen ist (Verwalten → Servereinstellungen → Verbindungen → Unterstützte Authentifizierungen) und für den Benutzer aktiviert wurde. Im Anmeldedialog wählen Benutzer das Verfahren unter Authentifizierungsmethode.

1. Standard (Benutzername & Passwort) – Anmeldung mit den Password Depot-Zugangsdaten des Serverbenutzers (Standardverfahren).

2. SSPI (Domänenanmeldung) – Anmeldung mit Windows-Domänen-Zugangsdaten. Der Benutzername muss im UPN-Format (benutzer@firma.de) oder im Down-Level-Format (DOMÄNE\benutzername) angegeben werden.

3. Windows SSO (Negotiate) – passwortlose Anmeldung über die bestehende Windows-Anmeldung (Kerberos/SPNEGO). Voraussetzungen: Integrierte Windows-Authentifizierung (IWA) in den Servereinstellungen aktiviert; beim Benutzer ist IWA als Anmeldemethode aktiviert und SAM-Kontoname oder UPN hinterlegt; das Endgerät ist Mitglied der Domäne (oder einer vertrauten Domäne); der Browser erlaubt Negotiate gegenüber dem Server (Chrome/Edge: Richtlinie AuthServerAllowlist, auch per Gruppenrichtlinie verteilbar; Firefox: network.negotiate-auth.trusted-uris).

4. Passkey (WebAuthn) – passwortlose Anmeldung per Passkey (z. B. Windows Hello oder Hardware-Sicherheitsschlüssel). Passkeys lassen sich im Web-Client im Profilbereich registrieren, umbenennen und entfernen; im Desktop-Client und im Web-Client registrierte Passkeys sind untereinander austauschbar.

5. Identitätsanbieter (OIDC) – neu ab 2.0: Anmeldung über OpenID Connect, z. B. mit Entra ID, Ping Identity, Auth0 oder einem generischen Anbieter. Die verfügbaren Anbieter ruft der Web-Client vom Server ab. Beim Identitätsanbieter muss die Basis-URL des Web-Clients (nur Ursprung, ohne Pfad) als Redirect-URI registriert und id_token als Antworttyp zugelassen sein.

6. Azure AD / Entra ID (veraltet) – ältere Microsoft-Anmeldung über eine fest hinterlegte App-ID, nur noch für Bestandsumgebungen. Für Neueinrichtungen empfiehlt der Support durchgängig den OIDC-Weg mit eigenem Entra ID-Anbieter.

Zwei-Faktor-Authentifizierung (2FA): TOTP wird für alle Verfahren unterstützt; bei der ersten Anmeldung zeigt der Web-Client den QR-Code zur Einrichtung der Authenticator-App. Über die REST-API gibt es keine vertrauenswürdigen Geräte – der 6-stellige Code ist bei jeder Anmeldung erforderlich. FIDO2-Sicherheitsschlüssel als zweiter Faktor werden über die REST-API nicht unterstützt (stattdessen TOTP oder E-Mail-Code verwenden); dies ist nicht zu verwechseln mit der Passkey-Anmeldung aus Punkt 4.

Hinweis: Beim Web-Client 1.x funktionierte die Anmeldung über OIDC/Entra ID nicht – sie steht erst ab Version 2.0 zur Verfügung. Administratoren können die Auswahl im selbst gehosteten Web-Client über die config.json vorkonfigurieren (defaultAuthMethod, disabledAuthModes).

Verwandte Themen:

• Entra ID (früher Azure AD) an den Enterprise Server anbinden – Voraussetzungen und empfohlener Weg

• Anmeldung per Single Sign-On (SSO) am Enterprise Server einrichten und Fehler beheben

• Wie erhalte ich den Web-Client 2.0 und welche Voraussetzungen gelten?

• Web-Client 2.0 installieren und bereitstellen (On-Premises)