NetworkManager trūkst OpenConnect TOTP uzvednes: četras pārbaudes

Vārteja pieņem paroli, pieprasa kodu, un dialogs tam nepiedāvā nevienu lauku. Nekas netika ievadīts nepareizi: NetworkManager spraudnis pabeidza noslēpuma apmaiņu, nepieprasot sešciparu vērtību. Veiciet četras pārbaudes zemāk secīgi, jo tikai viena no tām maina klientu. Pārējais saraksts izslēdz vārteju, kontu un spraudņa būvējumu.

Pirmā pārbaude: izlasiet, kur apstājās autentifikācija

Nepareiza parole neizdodas uzreiz. Trūkstošais otrais faktors neizdodas pēc akreditācijas datu soļa, parasti ar atkārtotu pieprasījumu vai taimautu vārtejas pusē. Laiks un vārtejas žurnāls parāda, kurš raunds palika bez atbildes.

Pirms pieskaraties profilam, izlasiet savienojuma žurnālu. Ja vārteja ziņo par nepilnīgu autentifikāciju vai izbeigušos izaicinājumu, klients kodu nekad nav nosūtījis. Ja tā ziņo par nederīgiem akreditācijas datiem, problēma ir parole, un neviena TOTP iestatīšana to nelabos.

Pierakstiet precīzo pieprasījumu secību, ko vārteja gaida: lietotājvārds, parole, tad kods, vai lietotājvārds, kods, tad parole. Dažas vārtejas pārkārto raundus, un klients, kas zina tikai pirmo secību, apstāsies otrajā.

Otrā pārbaude: izmantojiet klientu, kuram pieder izaicinājums

Pats OpenConnect īsteno visu sarunu, tostarp izaicinājuma raundu. Palaist to tieši ir visparedzamākais veids, kā apstiprināt, ka konts un vārteja darbojas:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

Klients jautā tādā secībā, kādā jautā vārteja. Lietotāja aģents ir svarīgs, jo dažas vārtejas pielāgo pieteikšanās plūsmu zināmam klientam, un vispārīga virkne var radīt īsāku plūsmu, kas nekad nepieprasa kodu. Palaidiet to vienreiz priekšplānā, pirms kārtojat jebkuru fona pakalpojumu.

Ja komandrinda jautā pareizi, konts, vārteja un otrais faktors ir kārtībā. Atlikušā problēma ir spraudņa dialogs, nevis autentifikācijas pakalpojums. Tas izolē bojāto komponentu, nepieskaroties serverim. Saglabājiet komandas izvadi kopā ar incidenta ierakstu.

Ja arī komandrinda izlaiž pieprasījumu, apstājieties un pārbaudiet vārtejas konfigurāciju kopā ar tās īpašnieku. Neviens galddatora klients nevar atbildēt uz izaicinājumu, ko serveris nekad nesūta.

Trešā pārbaude: apskatiet, vai spraudnis piedāvā TOTP režīmu

Daži NetworkManager OpenConnect būvējumi piedāvā marķiera režīmu un lietotāja aģenta lauku savienojuma Identity cilnē. Iestatiet lietotāja aģentu uz vērtību, ko gaida vārteja, izvēlieties manuālu TOTP ievadi un saglabājiet savienojumu.

Vai šie lauki pastāv, ir atkarīgs no spraudņa versijas un no tā, kuru savienojumu redaktoru izmanto galddators. Atsevišķs redaktors var rādīt opcijas, ko GNOME panelis slēpj, vai otrādi. Pirms meklējat paslēptu iestatījumu, pārbaudiet instalētās pakotnes versiju.

Ja marķiera režīms ir, bet pieprasījums joprojām neparādās, būvējumā trūkst izaicinājuma nodošanas starp spraudni un vispārīgo noslēpuma dialogu. Paroles atkārtota ievadīšana, tās pašas pakotnes pārinstalēšana vai atslēgu saišķa notīrīšana neizveidos lauku, ko būvējums neīsteno.

Ceturtā pārbaude: uz ģenerēto kodu skatieties kā uz kompromisu

Skripts var izsaukt oathtool pašreizējam kodam un padot lietotājvārdu, paroli un kodu nmcli connection up --ask ievadei. Secība darbojas, bet koplietotais noslēpums galu galā tiek glabāts vietā, ko var lasīt ikviens, kas spēj atvērt skriptu, un tas lasītājs var mūžīgi ģenerēt kodus. Tas ir pastāvīgs akreditācijas datu virsmas paplašinājums, nevis klienta labojums.

Ikviens, kas to izvēlas, noslēpuma failu ierobežo root, tur ģenerētās vērtības ārpus čaulas vēstures un izturas pret skriptu kā pret akreditācijas datu materiālu. Ietinējs, kas kodu atbalso terminālī, izmet otro faktoru. Vispirms pārbaudiet ietinēju ar vienreiz lietojamu kontu.

Skriptam jāievēro arī vārtejas pieprasījumu secība. Ja serveris pieprasa kodu pirms paroles, fiksēta ievades secība nosūta nepareizo vērtību nepareizajam pieprasījumam un rada to pašu nepilnīgo autentifikāciju. Vingrinieties ar testa kontu, pirms pievienojat to pieteikšanās darbam.

Apstipriniet to pašu vārteju un kontu

Pārbaudiet katru apiešanas risinājumu pret to pašu vārteju, to pašu kontu un to pašu tuneļa grupu. Vārteja, kas pieprasa arī ierīces sertifikātu, var noraidīt komandrindas klientu ar TOTP nesaistīta iemesla dēļ, un pieprasījumu secība var atšķirties no vingrinātās.

Pierakstiet klientu, tā versiju, lietotāja aģentu un pieprasījumu secību, kas darbojās. Šis ieraksts pasaka nākamajam cilvēkam, vai problēma ir spraudņa būvējumā, vārtejas plūsmā vai konta politikā, bez vēl viena paroļu atiestatīšanas raunda.

Pabeidziet, vienreiz atkārtoti pieslēdzoties pēc pilnīgas izrakstīšanās. Kešatmiņā saglabāts noslēpums var likt salūzušai plūsmai izskatīties salabotai līdz nākamajai sesijai, un tieši otrajā pieslēgšanās reizē pazudušais pieprasījums parasti atgriežas.