Fehlerdiagnose

Ein Eintrag je Symptom; Umgebung jeweils: diese DokuWiki-Instanz mit installiertem Paket wkidentity, sofern nicht anders angegeben.

Umgebung: Konto mit eingerichtetem Faktor, Microsoft Authenticator oder Google Authenticator.

Ursache: digits oder period weichen von 6 beziehungsweise 30 ab. Beide Apps werten diese Parameter aus der Einrichtungs-Adresse nicht aus und rechnen immer mit sechs Ziffern und dreißig Sekunden — die App erzeugt dann systematisch andere Codes, als der Server erwartet. Zweite mögliche Ursache: Uhrendrift jenseits der Toleranz window.

Lösung: digits auf 6 und period auf 30 zurücksetzen, oder auf eine App wechseln, die beide Parameter auswertet. Bei Drift window anheben (Bereich 0 bis 10). Vorher mit do=wkidentity_debug prüfen, ob Server- und App-Rechnung überhaupt übereinstimmen.

Wie viele Konten betroffen sind, ist die Diagnose. Trifft es ein einzelnes Konto, ist es fast immer dessen Geräteuhr — das behebt der Betreffende selbst; schicken Sie ihn auf Authenticator verloren oder Telefon defekt, Abschnitt „Der Code aus der App wird abgelehnt„. Die Seite ist ohne Anmeldung lesbar und lässt sich deshalb auch jemandem schicken, der gerade nicht hineinkommt. Trifft es alle eingerichteten Konten gleichzeitig, ist es die Serveruhr — die eine Uhr, die sich alle teilen, und der einzige Fall, in dem eine falsche Zeit den gesamten Bestand auf einmal aussperrt.

Umgebung: enforce_login steht auf 1, Anmeldungen laufen unverändert einstufig durch.

Ursache: Die Erzwingung greift ausschließlich bei Konten, die bereits einen Faktor eingerichtet haben. Wer nie einen eingerichtet hat, ist von der Einstellung vollständig unberührt — das ist beabsichtigt, sonst sperrte das Einschalten den gesamten Bestand aus.

Lösung: Wenn Konten ohne Faktor gebunden werden sollen, ist die Anmelde-Erzwingung das falsche Werkzeug. Eine Richtlinie setzen, siehe How to: Einen zweiten Faktor verlangen.

Umgebung: Verwaltung → Zweiter Faktor, Reiter Benutzer, Konto eingetragen; der Betreffende sieht ein Hinweisbanner, wird aber nirgends abgewiesen.

Ursache: Diese Liste speist ausschließlich das seitenweite Hinweisbanner. Sie ist als warnend gebaut und sperrt nichts.

Lösung: Für eine wirksame Bindung einen Geltungsbereich-Eintrag vom Typ user oder group in conf/wkidentity-policy.json anlegen. Der Verwaltungsbildschirm schreibt diese Einträge nicht.

Umgebung: Namensraum-Präfix im Reiter Namespaces eingetragen, Zugriff wird trotzdem gewährt.

Ursache: Getroffen wird die eingetragene Kennung selbst und alles, was mit ihr plus Doppelpunkt beginnt. Ein leerer Eintrag wirkt nicht als Platzhalter für das gesamte Wiki, und ein Präfix ohne den passenden Namensraum trifft nichts.

Lösung: Das Präfix gegen eine tatsächliche Seitenkennung prüfen. Soll die Pflicht unabhängig vom Namensraum gelten, gehört sie auf die Gruppe oder das Konto — beide werden bei jeder Rechteprüfung mit ausgewertet.

Umgebung: Verwaltung → Einladungen und offene Vorgänge, Formular ausgefüllt, Absenden wird abgelehnt.

Ursache: Zwei Fälle werden abgewiesen — der Anmeldename ist bereits vergeben, oder für ihn steht bereits ein Vorgang offen.

Lösung: Im ersten Fall ist kein Vorgang nötig: Das Konto besteht, gebraucht wird ein Zurücksetzen. Im zweiten Fall den offenen Vorgang benutzen — nachschicken oder Adresse korrigieren; beides macht den vorherigen Code ungültig.

Umgebung: Angemeldetes Konto mit eingerichtetem Faktor, Zugriff auf einen pflichtigen Geltungsbereich.

Ursache: Der Nachweis einer Sitzung verfällt nach assurance_ttl Sekunden (Vorgabe 3600) und fällt auf angemeldet zurück. Die Anmeldung selbst bleibt bestehen; nur der zusätzliche Faktornachweis gilt nicht mehr.

Lösung: Ist der Abstand zu kurz, assurance_ttl anheben. Der Wert ist bewusst begrenzt: Eine Aufstufung von gestern soll heute nicht stillschweigend weitergelten.

Umgebung: Konto mit eingerichtetem zweiten Faktor. Das Telefon ist verloren, gestohlen, defekt, zurückgesetzt oder die Authenticator-App wurde gelöscht — vier Anlässe, ein Befund: Auf das Geheimnis besteht kein Zugriff mehr. Eine offene Sitzung besteht nirgends, sonst wäre es kein Fall für die Verwaltung.

Ursache: Das Geheimnis liegt ausschließlich in der App und verschlüsselt auf dem Server; es ist nirgends nachschlagbar und wird nirgends angezeigt. Vom Nutzer aufbewahrte Ersatzcodes gibt es in diesem Paket nicht — der Fall wird bewusst durch die Verwaltung geschlossen und nicht durch Codes, die jemand hätte aufheben müssen.

Lösung: Zuerst die Identität außerhalb dieses Wikis feststellen, auf einem Weg, der weder am verlorenen Gerät noch am Postfach hängt: Rückruf unter einer bereits bekannten Nummer, persönliche Vorsprache, Bestätigung durch Vorgesetzte. Eine E-Mail-Bitte ist kein Nachweis — wer das Postfach übernommen hat, schreibt dieselbe E-Mail. Der Klick ist der einfache Teil, die Prüfung ist der Schutz.

Danach, mit Superuser-Recht:

1. do=admin öffnen, Eintrag Zwei-Faktor-Authentifizierung (TOTP) — oder unmittelbar do=admin&page=wkidentity.
2. Reiter Benutzer wählen.
3. Die Zeile des Kontos in der Auswahlspalte ankreuzen; das Feld Benutzer suchen grenzt lange Listen ein.
4. In der Befehlsleiste auf Enrollment zurücksetzen klicken.
5. Die Rückfrage Enrollment zurücksetzen? mit Ja, zurücksetzen bestätigen.

Was das Zurücksetzen genau tut: Es entfernt alle eingerichteten Faktoren dieses Kontos — Authenticator-App und E-Mail-Code gemeinsam, nicht einzeln — samt einem eventuell offenen E-Mail-Code. Kennwort, Konto, Gruppen und Rechte bleiben unberührt, laufende Sitzungen werden nicht beendet. Ein Zurücksetzen ersetzt deshalb keine Kennwortänderung, wenn ein Konto als übernommen gilt.

Danach: Das Konto ist nicht mehr eingerichtet, und die Anmelde-Erzwingung greift ausschließlich bei eingerichteten Konten — die nächste Anmeldung läuft also einstufig, allein mit Kennwort. Ein neues Enrollment wird dabei nicht erzwungen; der Betreffende richtet den Faktor selbst neu ein, siehe den nächsten Eintrag.

Weisen Sie den Betreffenden auf Authenticator verloren oder Telefon defekt hin. Diese Seite ist ohne Anmeldung lesbar und lässt sich deshalb auch jemandem schicken, der gerade nicht hineinkommt.

Umgebung: Das Enrollment wurde zurückgesetzt, die Anmeldung läuft wieder einstufig, ein Bereich mit Faktorpflicht antwortet aber weiterhin mit einer Ablehnung.

Ursache: Das ist die Pflicht bei der Arbeit und kein Rest des Zurücksetzens. Eine Namensraum-, Gruppen- oder Kontopflicht verlangt einen eingerichteten und in dieser Sitzung bewiesenen Faktor. Ein zurückgesetztes Konto hat keinen, wird also abgewiesen — mit der Begründung „nicht enrollt“ und einem Verweis auf das Profil.

Lösung: Der Betreffende richtet den Faktor neu ein: do=profile, Abschnitt Zwei-Faktor-Authentifizierung (TOTP), Knopf Zwei-Faktor-Authentifizierung einrichten, QR-Code einlesen, Code eintragen, Bestätigen und aktivieren. Der Verweis auf der Ablehnungsseite führt unmittelbar dorthin.

Bis dahin ist der Bereich für dieses Konto zu Recht gesperrt. Eine Pflicht, die nach einem Zurücksetzen vorübergehend aussetzte, wäre die Aussage, dass ein Zurücksetzen sie aufhebt.

Umgebung: Das Konto mit Superuser-Recht ist eingerichtet, sein Gerät ist weg, ein zweites Superuser-Konto besteht nicht. Der Verwaltungsbildschirm, der das Zurücksetzen erledigen würde, ist damit unerreichbar.

Ursache: Der Verwaltungsweg setzt eine Anmeldung voraus, die an genau dem Faktor scheitert, der zurückgesetzt werden soll. Das ist keine Fehlfunktion, sondern die Folge einer Installation mit genau einem Administrator.

Lösung: Über die Kommandozeile, mit Zugriff auf den Server. Erst nachsehen, dann zurücksetzen:

php bin/plugin.php wkidentity factors      <anmeldename>
php bin/plugin.php wkidentity reset-factor <anmeldename>

reset-factor entfernt alle Faktoren des Kontos und entspricht damit genau der Schaltfläche im Verwaltungsbildschirm. Das Kennwort bleibt unberührt — ist auch das verloren, ist php bin/plugin.php wkidentity code <anmeldename> die andere Hälfte, und die beiden Vorgänge haben nichts miteinander zu tun. Ein zweiter Aufruf auf einem bereits zurückgesetzten Konto meldet sachlich, dass nichts zu tun war.

Wer diesen Zugriff hat, besitzt ohnehin bereits sämtliche Dateien des Wikis — der Weg verschafft keine Rechte, die vorher nicht bestanden. Was er nicht leisten kann, ist die Identitätsprüfung. Die Kommandozeile fragt nicht, wer gebeten hat; das muss vorher geklärt sein, und zwar abseits des verlorenen Geräts und abseits des Kontopostfachs. Der Befehl sagt das beim Ausführen selbst noch einmal.

Vorbeugung, und sie ist die eigentliche Lösung: ein zweites Konto mit Superuser-Recht, bevor die Erzwingung eingeschaltet wird. Es ist der Unterschied zwischen einer Wiederherstellung durch das Wiki und einer über das Dateisystem. Als sofortige Notmaßnahme lässt sich außerdem enforce_login im Konfigurationsmanager auf 0 setzen: Die Anmeldung fällt für alle auf eine Stufe zurück, ohne dass ein Enrollment verloren geht — verlustfrei und jederzeit umkehrbar, senkt aber die Absicherung des gesamten Wikis, solange es gilt.

• Authenticator verloren oder Telefon defekt — die Anleitung für Betroffene, ohne Anmeldung lesbar
• Überblick
• Tutorial: Einen zweiten Faktor einrichten und beim Anmelden verlangen
• How to: Jemanden einladen, der noch kein Konto hat