Diagnostika

Za vsak simptom en vnos. Okolje je povsod ta namestitev DokuWiki z nameščenim paketom wkidentity, razen kjer je navedeno drugače. Kratica 2FA pomeni drugi dejavnik avtentikacije.

Okolje: račun z vpisanim dejavnikom, Microsoft Authenticator ali Google Authenticator.

Vzrok: Vrednost digits ali period odstopa od 6 oziroma 30. Obe aplikaciji teh parametrov ne bereta in vedno računata s šestimi števkami in tridesetimi sekundami, zato ustvarjata druge kode, kot jih pričakuje strežnik. Drugi možni vzrok je ura, ki odstopa bolj, kot dopušča window.

Rešitev: Vrnite digits na 6 in period na 30 ali preidite na aplikacijo, ki oba parametra bere. Pri odstopanju ure zvišajte window (dovoljeno od 0 do 10). Najprej z do=wkidentity_debug preverite, ali se izračuna sploh ujemata.

Koliko računov je prizadetih, je že diagnoza. Če gre za posamezen račun, je skoraj vedno kriva ura na njegovi napravi – to uporabnik odpravi sam; napotite ga na Izgubljena aplikacija za preverjanje ali pokvarjen telefon, odsek »Koda iz aplikacije je zavrnjena«. Stran je berljiva brez prijave in jo je zato mogoče poslati tudi nekomu, ki prav zdaj ne more noter. Če so hkrati prizadeti vsi vpisani računi, je kriva strežniška ura – edina, ki si jo delijo vsi, in edini primer, ko napačen čas naenkrat zapre ven celoten obseg.

Okolje: enforce_login je nastavljen na 1, prijave pa tečejo z golim geslom.

Vzrok: Nastavitev deluje samo pri računih, ki dejavnik že imajo vpisan. Kdor ga ni nikoli vpisal, je ne občuti. Tako je zasnovana namenoma, sicer bi vklop čez noč zaprl ven vse obstoječe uporabnike.

Rešitev: Za račune brez dejavnika je zahteva ob prijavi napačno orodje. Nastavite pravilnik, glejte Kako: zahtevati drugi dejavnik.

Okolje: Skrbništvo → Drugi dejavnik, zavihek Uporabniki, račun je vpisan na seznam. Uporabnik vidi opozorilni pas, nikjer pa ni zavrnjen.

Vzrok: Ta seznam poganja samo opozorilni pas čez stran. Dostopa ne zapira in tega tudi ni nikoli počel.

Rešitev: Za pravo zavezo dodajte vnos obsega vrste user ali group v conf/wkidentity-policy.json. Skrbniški zaslon teh vnosov ne zapisuje.

Okolje: predpona je vpisana v zavihku Namespaces, dostop pa je kljub temu dovoljen.

Vzrok: Zajeta je vpisana oznaka in vse, kar se začne z njo in dvopičjem. Prazna vrstica ne pomeni celotnega wikija, predpona brez ustreznega imenskega prostora pa ne zajame ničesar.

Rešitev: Primerjajte predpono z resnično oznako strani. Če naj obveznost velja ne glede na imenski prostor, jo vežite na skupino ali račun; oba se preverita pri vsaki pravici.

Okolje: Skrbništvo → Povabila in odprti postopki, obrazec je izpolnjen, oddaja pa je zavrnjena.

Vzrok: Zavrneta se dva primera: prijavno ime je že zasedeno ali pa zanj že teče odprt postopek.

Rešitev: V prvem primeru postopka ne potrebujete, saj račun obstaja; potrebna je ponastavitev gesla. V drugem uporabite odprti postopek – pošljite kodo znova ali popravite naslov. Oboje razveljavi prejšnjo kodo.

Okolje: prijavljen račun z vpisanim dejavnikom, dostop do vsebine z obveznostjo.

Vzrok: Potrditev seje zapade po assurance_ttl sekundah (privzeto 3600) in seja pade nazaj med navadne prijavljene. Sama prijava ostane, izgubi se le potrditev dejavnika.

Rešitev: Če je razmik prekratek, zvišajte assurance_ttl. Vrednost je omejena namenoma: včerajšnja potrditev naj danes ne velja tiho naprej.

Okolje: račun z vpisanim drugim dejavnikom. Telefon je izgubljen, ukraden, pokvarjen, ponastavljen ali je bila aplikacija za preverjanje izbrisana – štirje povodi, ena ugotovitev: do skrivnega ključa ni več dostopa. Odprte seje ni nikjer, sicer to ne bi bil primer za skrbništvo.

Vzrok: Skrivni ključ je izključno v aplikaciji in šifriran na strežniku; nikjer ga ni mogoče poiskati in nikjer ni prikazan. Nadomestnih kod, ki bi jih hranil uporabnik, v tem paketu ni – primer se namenoma zapre prek skrbništva in ne s kodami, ki bi jih moral nekdo shraniti.

Rešitev: Najprej ugotovite istovetnost zunaj tega wikija, po poti, ki ni odvisna ne od izgubljene naprave ne od nabiralnika: povratni klic na že znano številko, osebni obisk, potrditev nadrejenega. Prošnja po e-pošti ni dokaz – kdor je prevzel nabiralnik, napiše enako e-pošto. Klik je lahki del, varovalo je preverjanje.

Zatem, s pravico superuser:

1. Odprite do=admin, postavka Dvostopenjsko preverjanje (TOTP) – ali neposredno do=admin&page=wkidentity.
2. Izberite zavihek Uporabniki.
3. V izbirnem stolpcu označite vrstico računa; polje Iskanje uporabnikov skrajša dolge sezname.
4. V ukazni vrstici kliknite Ponastavi registracijo.
5. Vprašanje Ponastaviti registracijo? potrdite z Da, ponastavi.

Kaj ponastavitev natanko naredi: odstrani vse vpisane dejavnike tega računa – aplikacijo za preverjanje in kodo po e-pošti skupaj, ne posamično – skupaj z morebitno odprto kodo po e-pošti. Geslo, račun, skupine in pravice ostanejo nedotaknjeni, tekoče seje se ne končajo. Ponastavitev zato ne nadomešča zamenjave gesla, kadar velja, da je bil račun prevzet.

Zatem: račun ni več vpisan, zahteva ob prijavi pa velja izključno za vpisane račune – naslednja prijava torej teče z golim geslom. Novega vpisa pri tem nič ne izsili; dejavnik znova nastavi uporabnik sam, glejte naslednji vnos.

Uporabnika napotite na Izgubljena aplikacija za preverjanje ali pokvarjen telefon. Ta stran je berljiva brez prijave in jo je zato mogoče poslati tudi nekomu, ki prav zdaj ne more noter.

Okolje: registracija je bila ponastavljena, prijava spet teče z golim geslom, območje z obveznim dejavnikom pa še naprej odgovarja z zavrnitvijo.

Vzrok: To je obveznost pri delu in ne ostanek ponastavitve. Obveznost imenskega prostora, skupine ali računa zahteva vpisan in v tej seji potrjen dejavnik. Ponastavljen račun ga nima, zato je zavrnjen – z razlogom »ni vpisa« in povezavo na profil.

Rešitev: Uporabnik dejavnik znova nastavi: do=profile, odsek Dvostopenjsko preverjanje (TOTP), gumb Nastavi dvostopenjsko preverjanje, poskeniranje kode QR, vnos kode, Potrdi in vklopi. Povezava na strani z zavrnitvijo vodi neposredno tja.

Do takrat je območje za ta račun upravičeno zaprto. Obveznost, ki bi po ponastavitvi začasno mirovala, bi pomenila, da jo ponastavitev razveljavi.

Okolje: račun s pravico superuser je vpisan, njegove naprave ni več, drugega računa s to pravico ni. Skrbniški zaslon, ki bi ponastavitev opravil, je s tem nedosegljiv.

Vzrok: Skrbniška pot predpostavlja prijavo, ki se ustavi prav ob dejavniku, ki naj bi bil ponastavljen. To ni napaka, ampak posledica namestitve z natanko enim skrbnikom.

Rešitev: Prek ukazne vrstice, z dostopom do strežnika. Najprej poglejte, nato ponastavite:

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

reset-factor odstrani vse dejavnike računa in s tem ustreza natanko gumbu na skrbniškem zaslonu. Geslo ostane nedotaknjeno – če je izgubljeno tudi to, je druga polovica php bin/plugin.php wkidentity code <prijavno-ime>, postopka pa nimata drug z drugim nič. Drugi klic na že ponastavljenem računu stvarno sporoči, da ni bilo česa storiti.

Kdor ima ta dostop, ima tako ali tako že vse datoteke wikija – pot ne podeli pravic, ki jih prej ne bi bilo. Česar ne zmore, je preverjanje istovetnosti. Ukazna vrstica ne vpraša, kdo je prosil; to mora biti razjasnjeno prej, in sicer stran od izgubljene naprave in stran od nabiralnika računa. Ukaz to ob izvedbi še enkrat pove sam.

Preventiva, in ta je prava rešitev: drugi račun s pravico superuser, še preden se vklopi zahteva ob prijavi. To je razlika med obnovitvijo prek wikija in obnovitvijo prek datotečnega sistema. Kot takojšen zasilni ukrep je mogoče v upravitelju nastavitev postaviti enforce_login na 0: prijava za vse pade na eno stopnjo, ne da bi se izgubil kateri koli vpis – brez izgube in kadar koli povratno, dokler velja, pa zniža zaščito celotnega wikija.

• Izgubljena aplikacija za preverjanje ali pokvarjen telefon – navodila za prizadete, berljiva brez prijave
• Pregled
• Vpis drugega dejavnika in zahteva ob prijavi
• Kako: povabiti nekoga, ki še nima računa