Unternehmens-SSO (OIDC, SAML) & Multi-Faktor-Authentifizierung (MFA)

Ort der Konfiguration

Unternehmensadministratoren erreichen diese Einstellungen über Einstellungen → Unternehmen, in den Tabs Anmeldemethoden und Zwei-Faktor-Authentifizierung.

Unternehmens-VPN, -Proxy oder -Firewall

Wenn sich Ihre Benutzer hinter einem VPN, einem Unternehmens-Proxy oder einer Firewall mit SSL-Inspektion anmelden, können einige SSO-Flüsse blockiert oder verändert werden (Status-Cookie entfernt, Identitätsdomänen nicht erreichbar). Das typische Symptom ist eine Anmeldung, die fehlschlägt oder in einer Schleife läuft — während SSO ohne VPN funktioniert. Geben Sie Ihrem Netzwerkteam die Netzwerkfluss-Matrix, um die erforderlichen Domänen ohne SSL-Inspektion und ohne Cookie-Umschreibung freizugeben.

Verfügbare Anmeldemethoden

FoxPlan unterstützt mehrere Authentifizierungsansätze:

• Passwort
• Google Sign-in
• Microsoft Sign-in
• Unternehmens-SSO (OIDC)
• Unternehmens-SSO (SAML 2.0)

Wichtig

Unternehmensadministratoren behalten immer die Anmeldung per Passwort, selbst wenn diese für das Unternehmen deaktiviert ist. So wird vermieden, dass man aus FoxPlan ausgesperrt wird, falls der Identitätsanbieter nicht verfügbar ist.

Ausnahmen: das Passwort für bestimmte Benutzer beibehalten

Wenn Sie Ihre Organisation auf SSO umstellen, können Sie die Passwort-Anmeldung für alle außer einer Liste ausgewählter Benutzer deaktivieren.

Deaktivieren Sie das Kontrollkästchen Passwort: Unter den Kontrollkästchen erscheint dann ein Auswahlfeld „Ausnahmen: Benutzer, die das Passwort behalten". Wählen Sie dort die betroffenen Benutzer aus und speichern Sie.

Diese Benutzer sehen weiterhin das Passwortfeld auf dem Anmeldebildschirm, während alle anderen über SSO oder die Google-/Microsoft-Anmeldung gehen müssen.

Typische Anwendungsfälle:

• Notfallkonten („Break-glass") für den Fall eines Ausfalls des Identitätsanbieters
• Dienstleister oder Externe, die nicht in Ihrem Unternehmensverzeichnis enthalten sind
• Schrittweise Migration: die Teams in Wellen auf SSO umstellen

Die Einstellung wird vom Server durchgesetzt, nicht nur von der Anmeldeseite: Eine Anmeldung mit Passwort über die API oder die mobile App wird abgelehnt, und Haben Sie Ihr Passwort vergessen? verschickt keinen Link. Unternehmensadministratoren und die oben genannten Ausnahmen behalten ihren Zugang. API-Konten, die sich per Token authentifizieren, sind nicht betroffen.

Tipp

Das Auswahlfeld ist nur sichtbar, wenn die Methode Passwort deaktiviert ist: Solange sie aktiv ist, gilt sie bereits für alle, und keine Ausnahme ist erforderlich.

MFA-Optionen

Organisationen können wählen zwischen:

• TOTP (kompatibel mit Google Authenticator, Microsoft Authenticator, Okta, Keycloak)
• Verifizierung per E-Mail
• Kein MFA

Geltungsbereich: für wen die Zwei-Faktor-Authentifizierung gilt

Sobald eine Methode ausgewählt ist (TOTP oder E-Mail), erlaubt ein Abschnitt „Gilt für" die Auswahl der betroffenen Benutzergruppe:

Option	Wirkung
Alle Benutzer	Die Zwei-Faktor-Authentifizierung gilt für das gesamte Unternehmen (Standardverhalten).
Nur die aufgeführten Benutzer	Nur die ausgewählten Benutzer durchlaufen die Zwei-Faktor-Authentifizierung.
Alle Benutzer außer den aufgeführten	Die Zwei-Faktor-Authentifizierung gilt überall, außer für die ausgewählten Benutzer.

Für die beiden letztgenannten Modi steht ein Auswahlfeld zur Verfügung, um die betroffenen Benutzer zu bestimmen.

Typische Anwendungsfälle:

• Schrittweise Einführung: mit „Nur die aufgeführten Benutzer" und einem Pilotteam beginnen, dann auf „Alle Benutzer" umstellen.
• Gezielte Verstärkung: die Zwei-Faktor-Authentifizierung nur für Administratoren und sensible Profile verlangen.
• Technische Ausnahmen: Konten, die keine MFA-Abfrage beantworten können (Servicekonten, gemeinsam genutzte Terminals), über „Alle Benutzer außer den aufgeführten" ausnehmen.

Der Geltungsbereich wird serverseitig durchgesetzt: Ein Benutzer außerhalb des Geltungsbereichs meldet sich direkt an, ohne MFA-Abfrage, selbst wenn eine Methode für das Unternehmen aktiv ist.

Vorsicht

Im Modus „Alle Benutzer außer den aufgeführten" stellt jeder ausgenommene Benutzer eine Schwächung des Sicherheitsniveaus dar. Überprüfen Sie diese Liste regelmäßig.

Anmeldeablauf

1. Der Benutzer gibt seine E-Mail-Adresse ein und fährt fort
2. FoxPlan ermittelt das zugehörige Unternehmen
3. Die für diese Organisation verfügbaren Authentifizierungsmethoden werden angezeigt
4. Der Benutzer wählt je nach aktivierten Optionen Passwort oder SSO

Bei Passwortabläufen greifen die MFA-Abfragen. SSO-Abläufe delegieren die Authentifizierung an den Identitätsanbieter.

Konfiguration des Unternehmens-SSO (OIDC)

FoxPlan unterstützt OIDC-Anbieter: Okta, Keycloak, Google, Microsoft sowie individuelle Implementierungen.

Auf Seiten des Identitätsanbieters:

• Eine OIDC-Anwendung vom Typ Web anlegen
• Weiterleitungs-URL: {origin}/login/oauth2/code/{registrationId}
• Client ID, Client Secret (oder Zertifikat, siehe unten) und Issuer URI erfassen

Im SSO-Formular von FoxPlan:

• Auswahl des Anbieters
• Anzeigename
• Client ID
• Client-Authentifizierung: geteiltes Secret oder Zertifikat
• Issuer URI
• Scopes: openid,profile,email
• Username-Attribut (typischerweise sub oder email)
• Aktivierungsschalter

Konfiguration des Unternehmens-SSO (SAML 2.0)

Für Identitätsanbieter, die nur SAML sprechen — AD FS vor Windows Server 2016 oder SAML aufgrund Ihrer Sicherheitsrichtlinie — und für jeden SAML-2.0-Anbieter: Entra ID, Okta, Keycloak, Shibboleth… Nach der Anmeldung erhält der Benutzer genau dieselbe Sitzung wie mit OIDC.

Im SSO-Formular von FoxPlan wählen Sie den Anbieter SAML 2.0 und geben vorzugsweise die Metadaten des Anbieters an:

• Metadaten-URL — für AD FS: https://<adfs-server>/FederationMetadata/2007-06/FederationMetadata.xml. Sie wird bei jeder Anmeldung neu gelesen: Ein beim Anbieter erneuertes Signaturzertifikat wird ohne Ihr Zutun übernommen.
• oder eingefügte Metadaten als XML, wenn der FoxPlan-Server diese URL nicht erreicht. Unlesbares XML wird schon beim Speichern abgelehnt. Fügen Sie es erneut ein, wenn der Anbieter sein Zertifikat erneuert.

Die Metadaten liefern Entity-ID, SSO-URL und Signaturzertifikat des Anbieters. Ohne sie füllen Sie diese drei Felder von Hand aus.

Beim Identitätsanbieter tragen Sie FoxPlan mit den Werten ein, die die Maske und Konfiguration prüfen anzeigen:

Angabe	Wert
Kennung von FoxPlan (Entity-ID, Relying party identifier)	{origin}/saml2/service-provider-metadata/{registrationId}
Rücksprung-URL (ACS, Binding HTTP-POST)	{origin}/login/saml2/sso/{registrationId}
Metadaten von FoxPlan	Dieselbe URL wie die Kennung: Sie liefert die Metadatendatei, die unverändert importiert werden kann (AD FS: „Import data about the relying party published online“)

{registrationId} lautet <Kennung des Unternehmens>-saml2.

Attribute. FoxPlan ordnet den Benutzer seinem Konto über die E-Mail-Adresse zu. Es sucht sie im Attribut aus den erweiterten Optionen, dann unter den üblichen Namen — email, mail, die AD-FS-URI http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, die LDAP-OID urn:oid:0.9.2342.19200300.100.1.3, der UPN — und ersatzweise in der NameID, sofern sie die Form einer Adresse hat. Vor- und Nachname folgen derselben Logik (givenName, surname, AD-FS-URIs). Ohne E-Mail-Adresse wird die Anmeldung abgelehnt.

Fügen Sie bei AD FS der Vertrauensstellung eine Ausstellungsregel „Send LDAP Attributes as Claims“ hinzu: E-Mail-Addresses → E-Mail Address, Given-Name → Given Name, Surname → Surname.

Binding. Die Authentifizierungsanfrage wird standardmäßig per HTTP-Redirect gesendet; HTTP-POST bleibt verfügbar. Die Antwort des Anbieters kommt immer per HTTP-POST zurück.

Nicht unterstützt: Signieren der Authentifizierungsanfragen, verschlüsselte Assertions und SAML-Abmeldung (Single Logout). Hinterlegen Sie bei AD FS kein Verschlüsselungszertifikat in der Vertrauensstellung und verlangen Sie keine signierten Anfragen.

On-Premise-Installation

Der FoxPlan-Server lädt die Metadaten des Anbieters selbst herunter. Stellt ein internes AD FS sie bereit, dessen Zertifikat von der PKI Ihres Unternehmens signiert ist, legen Sie das Zertifikat dieser Zertifizierungsstelle in ca-sortant/ ab — siehe Eingehende und ausgehende Zertifikate.

Benutzerbereitstellung und AD-Gruppen

Mit der Bereitstellung steuert Ihr Verzeichnis (Active Directory, Entra ID, Okta, Keycloak…) FoxPlan. Sie funktioniert mit OIDC und SAML 2.0, also auch mit AD FS.

• Konten bei der ersten Anmeldung angelegt. Ein FoxPlan unbekannter Benutzer, der Mitglied mindestens einer mit einer FoxPlan-Gruppe verknüpften AD-Gruppe ist, erhält bei seiner ersten SSO-Anmeldung ein Konto, ohne Einladung. Er tritt dem Arbeitsbereich dieser Gruppe als Mitglied des Arbeitsbereichs bei: ohne Rechte und ohne Lizenz. Die Rolle vergibt anschließend der Administrator.
• Gruppen bei jeder Anmeldung synchronisiert. Verknüpfte FoxPlan-Gruppen folgen den AD-Gruppen des Benutzers: Er tritt ihnen bei jeder Anmeldung bei oder verlässt sie. Diese Gruppen konfigurieren seine Oberfläche — Menüs, Funktionen, geteilte Favoriten, Projektvorlagen.

Gruppen und Rollen bleiben getrennt: Die Bereitstellung ändert nie eine Rolle. Ein Benutzer ohne verknüpfte Gruppe wird abgewiesen, wie ohne Bereitstellung. Ein in FoxPlan gelöschter Benutzer wird durch SSO nicht neu angelegt.

Bereitstellung aktivieren — in der SSO-Konfiguration, Bereich Benutzerbereitstellung:

• Konten anlegen und Gruppen bei der Anmeldung synchronisieren ankreuzen;
• Gruppenattribut: leer lassen, um die üblichen Namen zu erkennen (groups, memberOf, Group- und Role-Ansprüche von AD FS), oder das Attribut (SAML) bzw. den Claim (OIDC) Ihres Anbieters angeben.

Gruppen verknüpfen — im Reiter Benutzerzugriff → Gruppen des Arbeitsbereichs eine Gruppe bearbeiten und Verknüpfte AD-Gruppen ausfüllen, eine pro Zeile. Eine AD-Gruppe wird über ihren Namen (Finance, CONTOSO\Finance) oder ihre Kennung (Entra-GUID) angegeben. Der Vergleich ignoriert Groß-/Kleinschreibung und Domänenpräfix und behält vom LDAP-DN nur den CN. Standardgruppen lassen sich nicht verknüpfen: Ihre Mitglieder ergeben sich aus den Rollen.

Ein bereitgestelltes Konto ist auch Mitglied der Standardgruppe All users. Seine Menüs und Funktionen sind die Schnittmenge aus All users und seinen synchronisierten Gruppen: Eine AD-Gruppe kann nur einschränken, nie erweitern. Konfigurieren Sie All users großzügig und schränken Sie in den mit dem AD verknüpften Gruppen ein.

In der Mitgliederliste kennzeichnet ein Abzeichen AD jene, die nur durch die Synchronisation dabei sind. Sie folgen dem AD, nicht der Maske. Ein von Hand hinzugefügtes Mitglied wird von der Synchronisation nie entfernt.

Beim Identitätsanbieter die Gruppen des Benutzers übermitteln:

Anbieter	Einstellung
AD FS	Ausstellungsregel „Send Group Membership as a Claim“ oder „Send LDAP Attributes as Claims“: Token-Groups – Unqualified Names → Group
Entra ID	Token configuration → Add groups claim. Entra sendet die Kennungen (GUID) der Gruppen und ab 200 Gruppen keine Liste mehr: die Ausgabe auf die der Anwendung zugewiesenen Gruppen beschränken
Okta	Groups claim, gefiltert auf die relevanten Gruppen
Keycloak	Mapper Group list (SAML) oder Group Membership (OIDC)

Austritte

Mit der Bereitstellung bei der Anmeldung allein wird ein Austritt aus dem AD erst bei der nächsten Anmeldung berücksichtigt. SCIM, siehe unten, setzt ihn sofort um. Andernfalls löschen Sie den Benutzer in FoxPlan.

Mit AD FS deaktivieren Sie zusätzlich Passwort in den Anmeldemethoden: Ein im AD deaktiviertes Konto kommt dann gar nicht mehr hinein, spätestens nach Ablauf seiner FoxPlan-Sitzung (24 h).

Automatische Bereitstellung per SCIM (Entra ID, Okta)

Mit Entra ID oder Okta kann das Verzeichnis Benutzer und Gruppen auch selbst an FoxPlan übertragen, ohne auf deren Anmeldung zu warten: Das ist das Protokoll SCIM 2.0. Es gelten die Regeln der Bereitstellung bei der Anmeldung — Konto als Mitglied des Arbeitsbereichs nur für Mitglieder einer verknüpften Gruppe, Rollen werden nie geändert. SCIM ergänzt sofortige Austritte: Ein im Verzeichnis deaktivierter oder aus der Anwendung entfernter Benutzer verliert sofort seinen Zugang.

1. Klicken Sie unter Einstellungen → Unternehmen → Bereitstellung (SCIM) auf Token erzeugen und kopieren Sie es: Es wird nie wieder angezeigt, FoxPlan speichert nur seinen Fingerabdruck.
2. Im Verzeichnis:
   • Entra ID: Unternehmensanwendungen → Ihre FoxPlan-Anwendung → Bereitstellung, Modus Automatisch. Tenant URL: die von FoxPlan angezeigte URL (https://<ihre-domain>/scim/v2); Secret Token: das Token. Verbindung testen, Benutzer und Gruppen der Anwendung zuweisen, dann die Bereitstellung starten.
   • Okta: die Anwendung → Provisioning → SCIM. SCIM connector base URL: die URL; Unique identifier field: userName; Aktionen Push New Users, Push Profile Updates und Push Groups; Authentifizierung HTTP Header mit dem Token.
3. Verknüpfen Sie die FoxPlan-Gruppen mit den übertragenen Gruppen, über Name oder Kennung, wie oben beschrieben.

Im Verzeichnis	In FoxPlan
Benutzer der Anwendung zugewiesen	Wartend; Konto angelegt, sobald er einer verknüpften Gruppe angehört
Einer Gruppe hinzugefügt oder daraus entfernt	Tritt den verknüpften FoxPlan-Gruppen bei oder verlässt sie
Deaktiviert oder aus der Anwendung entfernt	Konto sofort deaktiviert: keine Anmeldung mehr, aus den Arbeitsbereichen entfernt
Reaktiviert	Konto wiederhergestellt

Der Reiter bewahrt das Aufrufprotokoll 90 Tage auf. Ein übertragener Benutzer, dessen E-Mail-Adresse einem bestehenden FoxPlan-Konto entspricht, wird damit verknüpft: Ihn im Verzeichnis zu deaktivieren, deaktiviert auch dieses Konto. Das Token neu zu erzeugen oder zu widerrufen, stoppt die Bereitstellung sofort, ohne bereits angelegte Konten zu berühren.

On-Premise-Installation

Hier ruft das Verzeichnis FoxPlan auf, über Port 443 und den Pfad /scim/v2. Entra ID und Okta sind Onlinedienste: Die URL muss aus dem Internet erreichbar sein, es sei denn, Sie nutzen deren in Ihrem Netz installierten Bereitstellungs-Agenten.

Client-Authentifizierung: Secret oder Zertifikat

Der Tausch des Autorisierungscodes gegen ein Token ist der einzige Aufruf, den FoxPlan direkt an den Identitätsanbieter richtet, von Server zu Server. FoxPlan muss sich dabei ausweisen, und das Feld Client-Authentifizierung bietet dafür zwei Wege.

Client Secret (Standard). Ein geteiltes Geheimnis, auf beiden Seiten hinterlegt. Das ist der bisherige Modus, und für bestehende Konfigurationen ändert sich nichts: ohne ausdrückliche Auswahl bleiben sie dabei.

Zertifikat (privater Schlüssel). FoxPlan signiert eine JWT-Assertion mit einem privaten Schlüssel, und der Anbieter prüft sie mit dem öffentlichen Zertifikat, das Sie dort hinterlegt haben (private_key_jwt, RFC 7523). Das Geheimnis wird dann nie über das Netz übertragen — deshalb untersagen viele IT-Abteilungen inzwischen Client Secrets.

Es erscheinen dann zwei Felder:

• Client-Zertifikat: das X.509-Zertifikat im PEM-Format. Es ist die öffentliche Hälfte und muss ebenfalls beim Identitätsanbieter hinterlegt werden (in Entra ID: Certificates & secrets → Certificates).
• Privater Schlüssel: im unverschlüsselten PKCS#8-Format, das mit -----BEGIN PRIVATE KEY----- beginnt. Ein PKCS#1-Schlüssel (BEGIN RSA PRIVATE KEY) oder ein passwortgeschützter Schlüssel wird abgelehnt, samt dem Befehl zur Umwandlung.

So erzeugen Sie ein Schlüsselpaar:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out zertifikat.pem -days 730 -nodes -subj "/CN=foxplan-sso"
openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-pkcs8.pem

Hinterlegen Sie zertifikat.pem beim Anbieter und fügen Sie key-pkcs8.pem in FoxPlan ein.

Der private Schlüssel wird verschlüsselt gespeichert, nie von der API zurückgegeben und nie erneut angezeigt: Lassen Sie das Feld beim Bearbeiten leer, bleibt der gespeicherte Schlüssel erhalten. Das Zertifikat dagegen ist öffentlich und bleibt sichtbar.

Ein Zertifikat läuft ab

Anders als ein Secret trägt ein Zertifikat ein Enddatum. Ist es überschritten, steht das SSO sofort still.

Die Frist wird deshalb dauerhaft angezeigt: Die Liste der Konfigurationen enthält eine Spalte Authentifizierung, die für jedes SSO zeigt, ob es sich mit Secret oder Zertifikat authentifiziert — und im zweiten Fall das Ablaufdatum, im letzten Monat davor orange, danach rot. Dieses Datum wird nie eingetippt: Es wird bei jeder Anzeige aus dem Zertifikat selbst gelesen, der einzigen Quelle, die nicht von der Wirklichkeit abweichen kann. Konfiguration prüfen liefert alle Einzelheiten, einschließlich Fingerabdruck.

Konfiguration je Anbieter

Google — Issuer URI: https://accounts.google.com

Microsoft / Azure — Issuer: https://login.microsoftonline.com/{tenantId}/v2.0

Okta — Web-App-Typ mit passender Zuweisung und passenden Zugriffsrichtlinien

Keycloak — Issuer URI des Realms, konfigurierter Authorization-Code-Flow

Vor dem Ablauf gewarnt werden

Eine Anzeige setzt voraus, dass jemand hinsieht. FoxPlan warnt deshalb von sich aus: Eine E-Mail geht an die Administration des Unternehmens, zu drei Zeitpunkten — dreißig Tage, sieben Tage und an dem Tag, an dem das Zertifikat abgelaufen ist. Die Nachricht nennt den betroffenen Anbieter, gibt das Datum an und verweist auf den Konfigurationsbildschirm.

Jede Stufe wird nur einmal gemeldet: Der Durchlauf merkt sich, was bereits verschickt wurde. Sobald das Zertifikat erneuert ist — die Frist also wieder über dreißig Tagen liegt — stellt sich der Zähler von selbst auf das nächste Zertifikat um. Es ist nichts zu tun.

Ist keine Unternehmensadministration hinterlegt, geht keine E-Mail hinaus: ein Grund mehr, diese Liste in den Mitgliedern des Unternehmens aktuell zu halten.

Wenn die Anmeldung fehlschlägt

Wer sich per SSO nicht anmelden kann, landet wieder auf dem Anmeldebildschirm — mit einem Satz, der die Ursache benennt, statt mit einem Code des Identitätsanbieters:

Was die Person sieht	Was zu tun ist
Das Anmeldezertifikat ist abgelaufen	Zertifikat erneuern und auf beiden Seiten neu hinterlegen
Das Zertifikat ist unbrauchbar	Prüfen, ob der private Schlüssel zum Zertifikat passt
Der Anbieter hat die Anmeldedaten von FoxPlan abgelehnt	Das Secret wurde beim Anbieter geändert, oder das Zertifikat ist dort nicht hinterlegt
Keine aktive SSO-Verbindung	Die Konfiguration ist deaktiviert oder fehlt
Der Anbieter hat den Zugriff verweigert	Das Konto ist beim Anbieter nicht für die Anwendung freigegeben

Die technischen Einzelheiten — die genaue Meldung des Anbieters, der vollständige Stacktrace — bleiben in den Serverprotokollen, für den Support. Die Person erhält einen Satz, der ihr sagt, an wen sie sich wenden kann.

Die Konfiguration vor dem Test prüfen

Jede Konfiguration in der Liste trägt eine Schaltfläche Konfiguration prüfen. Sie öffnet einen Bericht, der den Bildschirm nicht verlässt und keine Anmeldung versucht:

• die URLs, die beim Identitätsanbieter zu hinterlegen sind, jeweils mit Kopierschaltfläche: die Weiterleitungs-URL und die URL zum Start der Anmeldung. Es sind genau jene, die die Anwendung verwenden wird — sie müssen nicht von Hand zusammengesetzt werden;
• die Konsistenzprüfungen: Pflichtfelder ausgefüllt, Discovery-Dokument vom Server gelesen, Aussteller und Endpunkte in Übereinstimmung mit dem, was der Anbieter veröffentlicht. Bei Authentifizierung per Zertifikat prüft der Bericht zusätzlich, ob der private Schlüssel zum Zertifikat passt, zeigt den SHA-1-Fingerabdruck — denselben wie die Konsole des Anbieters — und weist auf ein abgelaufenes oder bald ablaufendes Zertifikat hin.

Drei Stufen: grün, wenn alles stimmt, orange für einen Punkt, den man ansehen sollte, rot für das, was die Anmeldung verhindern wird. Die Angabe rechts neben jeder Zeile ist der Rohwert — URL, HTTP-Status, Meldung des Anbieters — genau das, was man an den Support weitergibt.

Eine Prüfung kann als „URL nicht abgefragt" gemeldet werden: Der Server ruft nur öffentliche https-Adressen auf, die Konfiguration ist nicht die Ursache.

Dieser Bericht ist schreibgeschützt: Er ändert die Konfiguration nie.

Fehlerbehebung

Prüfen Sie bei Authentifizierungsproblemen folgende Punkte:

• Die Weiterleitungs-URL stimmt zwischen IdP und FoxPlan exakt überein
• Die SSO-Konfiguration ist tatsächlich aktiviert
• Die E-Mail-Adresse des Benutzers gehört zum richtigen Unternehmen
• Prüfen Sie bei Okta/Azure/Keycloak die Zuweisung und die Einhaltung der Policies
• Prüfen Sie bei Benutzern mit Passwort+MFA die Registrierung (TOTP-Secret oder gültige E-Mail)