HTTP: Anmeldung (Referenz)

Alle Anmeldeverfahren des Dienstes mit ihren Regeln und Antworten, die Selbstbedienung für eigene Schlüssel und die Anmelderichtlinie mit dem zweiten Faktor. Das Modell dahinter erklärt Anmeldung und Weitergabe der Identität.

Neben dem Dienstschlüssel kann sich ein Aufrufer mit seinem Windows-Konto anmelden, über HTTP Negotiate – Kerberos oder, wo Kerberos nicht verfügbar ist, NTLM. Gedacht ist das für Personen: Access über den ODBC-Treiber und Excel oder Power BI melden sich als der Benutzer an, der sie ausführt. Nirgends wird ein Schlüssel oder Kennwort gespeichert, und das Audit nennt die Person statt eines Schlüsselnamens.

"Security": {
  "AuthMode": "ApiKey, Windows",
  "ApiKeys": [ { "Client": "fachanwendung", "Key": "env:FACHANWENDUNG_SCHLUESSEL" } ],
  "WindowsAccounts": [
    { "Account": "FIRMA\\Fachdaten-Leser",  "Client": "fachdaten-lesen" },
    { "Account": "FIRMA\\Fachdaten-Pflege", "Client": "fachdaten-pflege" },
    { "Account": "S-1-5-32-545",            "Client": "auskunft" }
  ],
  "Clients": [
    { "Id": "fachanwendung",    "Databases": [ "fachdaten" ], "Resources": [ "*" ],     "Verbs": [ "*" ] },
    { "Id": "fachdaten-lesen",  "Databases": [ "fachdaten" ], "Resources": [ "views" ], "Verbs": [ "GET" ], "ReadOnly": true },
    { "Id": "fachdaten-pflege", "Databases": [ "fachdaten" ], "Resources": [ "*" ],     "Verbs": [ "*" ] },
    { "Id": "auskunft",         "Databases": [ "fachdaten" ], "Resources": [ "views" ], "Verbs": [ "GET" ], "ReadOnly": true }
  ]
}

Ohne Anmeldung antwortet der Dienst mit 401 und WWW-Authenticate: Negotiate; erst darauf meldet sich ein Client mit Windows an. Jede neue Verbindung beginnt deshalb mit einer Anfrage ohne Anmeldung, die im Audit als anonym … UNAUTHENTICATED (401) steht. Das ist der erste Schritt des Verfahrens, kein Fehler. Danach gilt die Anmeldung für die ganze Verbindung.

Kerberos setzt einen SPN HTTP/<rechnername> für das Konto voraus, unter dem der Dienst läuft; fehlt er, weicht Windows auf NTLM aus.

Wer SQL Server bisher mit Name und Kennwort erreicht, meldet sich mit derselben Anmeldung am Dienst an: über HTTP Basic, also mit Name und Kennwort in der Kopfzeile Authorization. Der Dienst prüft das Kennwort nicht selbst und speichert keines. Er öffnet mit Name und Kennwort eine Verbindung zum Server des angesprochenen Alias, und SQL Server entscheidet wie bei einer direkten Verbindung. Alle Anweisungen der Anfrage laufen danach über Verbindungen dieser Anmeldung: Berechtigungen, Spaltenvorgaben und Trigger sehen die Anmeldung selbst, auch ORIGINAL_LOGIN().

"Databases": [
  { "Name": "fachdaten", "Provider": "sqlserver", "ConnectionString": "…",
    "AllowSqlLogins": true }
],
"Security": {
  "AuthMode": "ApiKey, Windows, SqlLogin",
  "SqlLogins": [
    { "Login": "*",       "Client": "fachdaten-lesen"  },
    { "Login": "pflege1", "Client": "fachdaten-pflege" }
  ],
  "TrustedProxies": [ "10.0.0.5" ]
}

Ein persönlicher Schlüssel gehört einer Person, nicht einem Dienst. Er setzt keine Domäne, kein SQL-Kennwort und keine Infrastruktur voraus und funktioniert damit überall, wo der Dienst erreichbar ist. Personen und Schlüssel stehen im Verwaltungsspeicher; das Verfahren braucht ihn und wird mit PersonalKey eingeschaltet:

"Security": { "AuthMode": "ApiKey, PersonalKey" },
"Store": { "Path": "store/dbgwsvc.db", "MasterKey": "env:WKL_GW_MASTER_KEY", "MaxKeyLifetimeDays": 365 }

Der Schlüssel kommt in dieselbe Kopfzeile wie ein Dienstschlüssel (X-Api-Key, siehe ApiKeyHeader). Jeder Client, der einen Dienstschlüssel schicken kann – der ODBC-Treiber mit APIKEY/APIKEYENV, ein Skript, ein Berichtswerkzeug –, schickt ohne Änderung einen persönlichen. Das Präfix unterscheidet beide. Ebenso gilt ein persönlicher Schlüssel als Kennwort von HTTP Basic (der Name wird nicht geprüft; empfohlen ist pkuser, siehe unten): Excel und Power BI legen solche Anmeldedaten (Anmeldeart „Standard“) in ihrer eigenen Anmeldeverwaltung ab, während eine Kopfzeile in die Abfrage – und damit in jede Mappe – geschrieben werden müsste. Die Form des Schlüssels unterscheidet ihn vom Kennwort einer SQL-Anmeldung.

<a id=„benutzername-pkuser“></a>Benutzername pkuser (Konvention). Wer einen persönlichen Schlüssel als Kennwort einträgt, gibt als Benutzernamen pkuser an (personal key user). Pflicht ist das nicht: Der Dienst erkennt den Schlüssel an seiner Form (wkl_…), nicht am Namen, und nimmt jeden Namen an. Der einheitliche Name hat trotzdem Vorteile:

• In den Anmeldeverwaltungen von Excel, Power BI und Windows sieht man auf einen Blick, dass hier ein persönlicher Schlüssel steht und keine SQL-Anmeldung.
• Am Telefon genügt „Benutzername pkuser, Kennwort Ihr Schlüssel“, ohne Erklärung, welcher Name gemeint ist.
• Niemand trägt den Namen eines anderen Systems ein und hält ihn dann für einen Teil des Zugangs.

Legen Sie in SQL Server keine Anmeldung pkuser an: Ein Kennwort ohne die Form eines Schlüssels prüft der Dienst als SQL-Anmeldung dieses Namens.

„Zuletzt benutzt“ wird gesammelt und alle 60 Sekunden sowie beim Beenden geschrieben, nicht je Anfrage: Jeder Schreibvorgang in die Datei ließe den Dienst sie erneut lesen. Ein Absturz kostet höchstens diese Minute an Statistik, nie eine Berechtigung. Schreibvorgänge, die die Betriebsdaten nicht ändern (Benutzung, Schlüssel, Personen), übernimmt der Dienst nicht als neue Fassung und meldet sie nicht.

Personen und Schlüssel verwalten – über die Verwaltungsschnittstelle oder auf dem Rechner des Dienstes mit den Befehlen save-person, issue-key, revoke-key und list-keys; sie laufen mit Konfiguration und Umgebung des Dienstes, auch während er läuft. Aufruf, Optionen und Rückgabewerte stehen unter Befehle am Server: Personen und Schlüssel. Diese Befehle schreiben nicht ins Änderungsprotokoll (wer sie ausführt, hat ohnehin Zugriff auf die Datei); die Befehle zur Rettung init-admin, reset-totp und remove-sign-in-rule dagegen schon, mit dem Akteur „Konsole (Rechner, Konto)“.

Ein Schlüssel kann so ausgestellt werden, dass er ruht, bis die Verwaltung ihn für eine Zeit freischaltet – etwa ein nur lesender Schlüssel ohne zweiten Faktor, den eine Person in Power BI für Vorführungen vor dem Vorstand hinterlegt. Der Schlüssel selbst bleibt über alle Freischaltungen derselbe; Power BI muss also nicht neu eingerichtet werden. Außerhalb einer Freischaltung öffnet er nichts, auch wenn er in einem Bericht, auf einem Laptop oder in einer Mail liegen geblieben ist.

Freischalten darf nur die Verwaltung, nicht die Person selbst; beides steht mit Akteur und Ende im Änderungsprotokoll. Die Höchstlaufzeit des Schlüssels (MaxKeyLifetimeDays) gilt weiter: Nach ihr braucht es einen neuen Schlüssel.

Eine Person, die sich anders anmelden kann – mit ihrem Windows-Konto oder ihrer SQL-Anmeldung –, stellt sich persönliche Schlüssel selbst aus, etwa für Excel auf dem Laptop, und sperrt sie wieder. Die Verwaltung muss dafür nichts tun außer die Selbstbedienung einmal freizuschalten.

Die „WklGatewayClient – VBA-Klasse für den Datendienst“ (Dokumentation der Verwaltungsanwendung) bietet dafür OwnKeys, IssueOwnKey und RevokeOwnKey.

Die Anmelderichtlinie legt fest, welches Anmeldeverfahren für welchen Teil des Dienstes von welchen Netzen oder Ländern einen zweiten Faktor braucht oder abgelehnt wird – etwa „persönliche Schlüssel aus dem Firmennetz ohne, von außen nur mit TOTP“, „SQL-Anmeldungen nie von außen“ oder „Datenzugriff nur aus Deutschland“. Sie steht im Verwaltungsspeicher und wird über die Mengen SignInRules, SignInRuleItems, SignInRuleExceptions, SignInRuleExceptionItems und Settings der Verwaltungsschnittstelle gepflegt; ohne Speicher sind nur Ablehnungen möglich (Gateway:Security:SignInRules in der Konfigurationsdatei).

Für einzelne Personen oder Gruppen. Eine Regel kann auf Personen oder Windows-Gruppen beschränkt werden oder sie ausnehmen – etwa „von außen niemand, außer Frank Mustermann“: { Scope: Data, Effect: Deny, ExceptFrom: [10.0.0.0/8], ExceptPersons: [Frank Mustermann] }. Eine Person erkennt der Dienst an ihrem persönlichen Schlüssel, ihrem eigenen Windows-Konto oder ihrer SQL-Anmeldung; eine Gruppe nur bei einer Windows-Anmeldung. Ein Aufrufer, der keiner Person zugeordnet ist (Dienstschlüssel), fällt unter keine solche Regel und unter keine Ausnahme. Was eine Regel für eine Person bedeutet, zeigt explain-sign-in der Verwaltungsschnittstelle.

Nach Land. Das Land einer Anfrage liest der Dienst aus der Geodatenbank des Anmeldeprotokolls – im Arbeitsspeicher, ohne Netzzugriff, und nur, wenn eine Regel Länder nennt. Kein Land hat eine Anfrage, wenn keine Geodatenbank geladen ist, wenn sie von diesem Rechner, aus einem eigenen Netz (`Gateway:SignInLog:Networks`) oder einem privaten Netz kommt oder wenn die Datenbank die Adresse nicht kennt. Ein solches unbekanntes Land liegt im Bereich jeder Regel: „Datenzugriff nur aus Deutschland“ lehnt es ab. Die eigenen Netze nehmen Sie deshalb über ihre Adressen aus, nicht über ein Land:

{ "Scope": "Data", "Effect": "Deny", "Label": "nur Deutschland",
  "ExceptCountries": [ "DE" ], "ExceptFrom": [ "10.0.0.0/8" ] }

Wichtig: Ein Land, das aus einer Adresse abgeleitet ist, ist ein Hinweis, kein Beweis. Ein VPN, ein Proxy oder ein Mobilfunknetz verlegt die Herkunft in ein anderes Land, und Geodatenbanken irren bei einzelnen Netzen. Regeln nach Land sind eine zusätzliche Schicht neben Schlüsseln, Netzen und dem zweiten Faktor; sie ersetzen keine davon.

Eine Regel kann außerdem nach dem Netzbetreiber der Herkunft, nach dem Programm und nach der Uhrzeit fragen. Die drei Merkmale sind unterschiedlich verlässlich:

Ein unbekannter Betreiber oder ein fehlendes Programm liegt wie ein unbekanntes Land im Bereich der Regel und erfüllt kein Merkmal einer Ausnahme. Ein behauptetes Programm taugt deshalb, um einzuschränken („die Verwaltung nur aus WinHTTP“ lehnt einen Browser ab). Als Ausnahme allein befreit es jeden, der den Text sendet; verbinden Sie es dort mit Personen, Netzen oder einem Ende.

Ein Zeitfenster schreiben Sie als [Tage] [hh:mm-hh:mm]:

• Tage Mon, Tue, Wed, Thu, Fri, Sat, Sun als Liste (Sat,Sun) oder Bereich (Mon-Fri, auch Fri-Mon); ohne Tage gilt jeder Tag.
• Uhrzeiten mit ausschließlichem Ende; 24:00 ist das Tagesende; ohne Uhrzeit gilt der ganze Tag.
• Ein Fenster über Mitternacht (Mon-Fri 22:00-06:00) gehört zu dem Tag, an dem es beginnt: Freitag 22 Uhr bis Samstag 6 Uhr liegt darin, Montag 3 Uhr nicht.

„SQL-Anmeldung nur Montag bis Freitag, 6 bis 20 Uhr“:

{ "Method": "SqlLogin", "Effect": "Deny", "Label": "SQL nur Bürozeit",
  "ExceptHours": [ "Mon-Fri 06:00-20:00" ] }

„Von fremden Netzbetreibern nur mit zweitem Faktor, aus Werk 3 nie“:

{ "Scope": "Data", "Effect": "RequireTotp", "Label": "fremde Netze mit Code",
  "ExceptOperators": [ "AS3320" ], "ExceptFrom": [ "Werk 3" ] }

Eigene und private Netze haben keinen Netzbetreiber. Ohne ExceptFrom verlangte die Regel den Code deshalb auch im Werk.

Das Anmeldeereignis nennt in Signals den beurteilten Netzbetreiber (operator), das Programm (client) und unter trust je Signal, wie verlässlich es ist (observed, claimed, verified).

Befristete Ausnahmen. Die Listen ExceptPersons, ExceptCountries und ExceptFrom nehmen je für sich und auf Dauer aus: ExceptPersons: [Frank Mustermann] befreit Frank aus jedem Land. Eine Ausnahme in Exceptions befreit dagegen nur, wenn alle ihre Merkmale zugleich zutreffen – etwa „Frank Mustermann aus Thailand bis zum 2. November“:

{ "Scope": "Data", "Effect": "Deny", "Label": "nur Deutschland",
  "ExceptCountries": [ "DE" ], "ExceptFrom": [ "10.0.0.0/8" ],
  "Exceptions": [ { "Persons": [ "Frank Mustermann" ], "Countries": [ "TH" ],
                    "Until": "2026-11-02T00:00:00Z", "Label": "Urlaub" } ] }

• Mindestens ein Merkmal oder ein Ende. Eine Ausnahme ohne beides befreite jeden auf Dauer; die Startprüfung und die Verwaltungsschnittstelle lehnen sie ab.
• Nichtwissen befreit nie. Ein unbekanntes Land, eine unbekannte Herkunft, ein unbekannter Netzbetreiber, ein fehlendes Programm oder ein Aufrufer, der keiner Person zugeordnet ist, erfüllt kein Merkmal, das danach fragt. Fehlt die Geodatenbank, schließt eine Ausnahme nach Land also, statt die Regel zu öffnen.
• Das Ende wirkt sofort. Der Dienst vergleicht es bei jeder Anfrage mit seiner Uhr; dafür ist keine Änderung nötig. Bemerkt er den Ablauf, schreibt er ihn einmal ins Änderungsprotokoll (Entity exception-lapsed, Akteur Dienst (Ablauf), vorher Regel, Notiz und Ende). Eine abgelaufene Ausnahme bleibt stehen, bis sie entfernt wird.

Vorsicht beim Anlegen einer Ablehnung. Eine Regel wirkt, sobald sie gespeichert ist. Wer eine Ablehnung für alle Bereiche zuerst ohne Ausnahmen anlegt und die Merkmale danach ergänzt, sperrt sich in diesem Moment selbst aus. Ablehnungen deshalb mit save-sign-in-rule der Verwaltungsschnittstelle anlegen, der Regel und Ausnahmen in einer Änderung speichert; ist es passiert, hilft remove-sign-in-rule am Server.

Jede zutreffende Regel zählt, eine Ablehnung vor allem anderen; die Reihenfolge bedeutet nichts. Ausnahme: Den Austausch eines Codes und das Einrichten des Faktors (/auth/v1/totp, /auth/v1/enrol) beurteilt der Dienst nur nach Regeln mit Bereich All; eine Ablehnung nur für Data oder Admin verhindert dort keinen Versuch. Und eine SQL-Anmeldung prüft SQL Server, bevor die Richtlinie urteilt: Von einer abgelehnten Herkunft antwortet ein falsches Kennwort 401, ein richtiges 403 – ein Angreifer erfährt also, ob ein Kennwort stimmt, begrenzt nur durch die Fehlversuchsgrenze. Trifft keine Regel, entscheiden allein die Rechte. Nicht beurteilt wird der unangemeldete Betrieb der Entwicklungsumgebung; eine Richtlinie, die die Verwaltung ausgesperrt hat, reparieren die Befehle am Server. Ein neuer Speicher beginnt mit der Regel „Verwaltung nur mit zweitem Faktor“ (Scope: Admin, Effect: RequireTotp); sie lässt sich wie jede andere ändern oder löschen. Unabhängig davon verlangt die feste Untergrenze Gateway:Store:RequireAdminTotp (Vorgabe true) den zweiten Faktor für die Verwaltung und die Selbstbedienung, bei jedem Anmeldeverfahren und jeder Herkunft; auch ein Schlüssel mit TotpExempt hebt sie nicht auf. Abschalten lässt sie sich nur in der Konfigurationsdatei. Die Startprüfung lehnt RequireTotp für Dienstschlüssel ab – ein Dienst ist keine Person und hat keinen zweiten Faktor; dafür Deny schreiben.

Zweiter Faktor (TOTP). Zeitbasierte Codes nach RFC 6238 (6 Stellen, 30 Sekunden), wie jede Authenticator-App sie erzeugt. Der Faktor gehört einer Person: Ein persönlicher Schlüssel nennt sie; ein Windows-Konto und eine SQL-Anmeldung finden sie über ihr eigenes Konto (WindowsAccount) bzw. ihre eigene Anmeldung (SqlLogin); verglichen wird nur der Name der Anmeldung, ohne Groß- und Kleinschreibung, über alle Aliasse und Server hinweg, und eine so eröffnete Sitzung gilt nicht nur für den Alias, an dem der Code getauscht wurde. Eine Gruppe ist keine Person; eine Anmeldung, die zu keiner oder zu zwei Personen passt, erhält 403, wenn ein zweiter Faktor verlangt wird. Eingerichtet wird er von der Verwaltung (enroll-totp), am besten als Einmal-Link: Die Seite zeigt die otpauth://-Adresse als QR-Code und daneben den Schlüssel für die manuelle Eingabe. Das Geheimnis steht versiegelt im Speicher (eigener Zweck, eigener Hauptschlüssel-Wechsel über reseal-store).

Einrichten bei der ersten Anmeldung. Hat eine Person noch keinen zweiten Faktor, verlangt die Richtlinie aber einen, darf sie ihn eine Zeit lang selbst einrichten – mit ihrem ersten Faktor, der bis dahin nur dafür gilt:

POST /auth/v1/enrol[/{alias}]   erster Faktor wie beim Tausch eines Codes
Rumpf: { }                      200: { "person", "secret", "uri", "qrPng", "openUntil" }
Rumpf: { "code": "123456" }     201: wie beim Tausch - der Faktor ist eingerichtet, eine Sitzung eröffnet

• Wann. Innerhalb von totp_enrol_hours (Menge Settings, sonst Gateway:Security:TotpEnrolHours, Vorgabe 24, höchstens 168, 0 schaltet das Einrichten bei der Anmeldung ab) nach dem Ausstellen des Schlüssels, mit dem die Anfrage kommt; für eine Person ohne Schlüssel (Windows-Konto) bis zu der Zeit, die init-admin oder reset-totp am Server gesetzt hat.
• Warum eine Frist. Bis der Faktor eingerichtet ist, steht der Schlüssel allein für die Person. Wer ihn in dieser Zeit abfängt, könnte seine eigene Authenticator-App binden. Die Frist hält diese Zeit kurz; ein Schlüssel, der zu lange gewartet hat, muss neu ausgestellt werden.
• Einmal. Die Bestätigung beendet die Frist und steht im Änderungsprotokoll; einer Person mit Faktor wird die Einrichtung nicht mehr angeboten. Hat jemand anderes zuerst eingerichtet, merkt der rechtmäßige Inhaber es daran. Einen neuen Faktor richtet dann die Verwaltung ein.
• Zwei Schritte. Ohne Code zieht der Dienst ein Geheimnis und antwortet mit Adresse, Schlüssel zum Abtippen und QR-Code als PNG; versiegelt gespeichert wird es erst mit dem ersten passenden Code. Ein neuer Aufruf ohne Code ersetzt das gezogene Geheimnis.
• Jede andere Anfrage der Person beantwortet der Dienst bis dahin mit 401 und WWW-Authenticate: Wkl-Totp realm="Wkl.Data.Gateway", enrol="/auth/v1/enrol". Die Verwaltungsanwendung zeigt dann die Einrichtungskarte; die VBA-Klasse WklGatewayClient meldet gwErrEnrolmentRequired und bietet BeginTotpEnrolment/ConfirmTotpEnrolment.

Code gegen Sitzung. Ein Code lebt 30 Sekunden; ein Treiber, der durch eine Tabelle blättert, kann nicht mit jeder Anfrage einen erfragen. Der Code wird deshalb einmal gegen eine Sitzung getauscht, die danach jede Anfrage in der Kopfzeile X-Wkl-Session begleitet:

POST /auth/v1/totp            erster Faktor: persönlicher Schlüssel oder Windows-Konto
POST /auth/v1/totp/{alias}    erster Faktor: SQL-Anmeldung (Basic), geprüft an diesem Alias
Rumpf: { "code": "123456" }                  wahlweise mit "role": "vertrieb"
201:   { "session": "…", "id": "t…", "person": "…", "header": "X-Wkl-Session", "expiresAt": "…" }

Nennt der Rumpf role, ist die Sitzung an diese Datenbank-Identität gebunden: Eine Anfrage ohne eigene Wahl läuft unter ihr. Geprüft wird die Wahl bei jeder Anfrage, nicht beim Tausch.

• Die Sitzung ist keine Anmeldung. Jede Anfrage trägt weiter ihren ersten Faktor; die Sitzung gilt nur für die Person, das Verfahren und – bei einem Schlüssel – den Schlüssel, mit dem sie eröffnet wurde. Ein gestohlenes Token allein öffnet nichts. Deshalb eine eigene Kopfzeile statt Authorization: Bearer: Diese trägt bei Windows und Basic schon den ersten Faktor.
• Laufzeit totp_session_hours (Menge Settings, sonst Gateway:Security:TotpSessionHours), Vorgabe 10 Stunden, 1 bis 168.
• Ende: Ablauf; Revoked in SessionTokens; Sperren des Schlüssels; Abschalten der Person; neues Einrichten oder Entfernen ihres zweiten Faktors. Nachgeschlagen wird bei jeder Anfrage.
• Ein Code gilt einmal (sein Zeitschritt muss nach dem zuletzt angenommenen liegen) und einen Schritt (30 Sekunden) vor oder nach der Uhr des Dienstes; diese Toleranz ist fest und nicht einstellbar. Fünf falsche Codes je Person bzw. zwanzig je Herkunft in 15 Minuten führen zu 429. Die Zähler liegen im Arbeitsspeicher: Ein Neustart setzt sie zurück, und wer einen Namen kennt, kann die Person mit falschen Versuchen eine Zeit lang aussperren.
• Der Austausch nur über eine geschützte Verbindung (HTTPS, vertrauter Proxy mit https, eigener Rechner).

Clients ohne Dialog – Power BI, Excel, Skripte – können keinen Code erfragen. Für sie gibt es Schlüssel mit TotpExempt: von einem verlangten zweiten Faktor ausgenommen, nicht von einer Ablehnung, und nur als nur lesender Schlüssel zulässig. Mit Rechten, die die Person auf freigegebene Sichten beschränken, und auf Wunsch einer Netzbindung ist das der eng begrenzte Zugang für Berichte.

Eine neue Regel – vor allem eine Ablehnung – erproben Sie zuerst mit Mode = Report. Die Regel wird dann bei jeder Anmeldung wie eine durchgesetzte beurteilt, ändert aber nichts: Wer ohne sie zugelassen wäre, bleibt zugelassen. Das Anmeldeereignis nennt sie in Rules mit "mode": "report"; SignInRuleReports zählt je Regel und Version, wie viele Anmeldungen sie getroffen hätte, von wie vielen Personen und Herkünften, und welche eine Ausnahme befreit hätte (siehe Verwaltung). explain-sign-in zeigt sie getrennt unter tried.

Passt das Ergebnis, schalten Sie die Regel mit save-sign-in-rule und "mode": "Enforce" scharf; ab dann wirkt sie. Die Umschaltung steht im Änderungsprotokoll und ändert die Version der Regel, so dass Ereignisse aus der Probe und aus dem Betrieb unterscheidbar bleiben. Die Untergrenze der Verwaltung (RequireAdminTotp) ist keine Regel und lässt sich nicht erproben.

• Anmeldung und Weitergabe der Identität
• Konfiguration: Security
• So stufen Sie den Zugang nach Lage ab