Тоа поле за потврда при најавата изгледа како поставка на клиентот, но на управуван компјутер често е одлука за политика. Контролата за запомнување на Viscosity го чува акредитивот во приврзокот за клучеви на macOS кога распоредувањето дозволува чување. Мит е дека полето за потврда секогаш е ваше за поставување. Во практиката три одделни работи можат да го блокираат, и само една од нив е за лозинката.

Што всушност чува полето за потврда

Избирањето на опцијата за запомнување бара од клиентот да ја задржи вредноста за таа една врска и сметка. Ставката завршува во приврзокот за клучеви, и подоцнежните најави ја користат повторно преку поддржаната покана, а не преку скриена поставка. Ништо не се запишува во самата датотека за врска. Тоа одвојување е и причината зошто подоцнежното отстранување на ставката дава покана наместо расипан профил.

Зачуваната вредност е влез за автентикацијата што серверот и онака ќе ја извршеше. Таа не менува што бара портата, не заобиколува втор фактор и не го претвора еднократниот код во тајна што може повторно да се користи. Она што го скратува е пишувањето, а не политиката што распоредувањето ја применува на таа сметка.

Зошто контролата може да недостасува

Администраторот може да го оневозможи чувањето акредитиви за управувана инсталација, и SparkLabs ја документира контролата за запомнување заедно со нејзиното однесување во приврзокот за клучеви во упатството за чување акредитиви. Кога полето за потврда недостасува, тоа не е расипано, и трагањето по команда за поставки што го заобиколува е погрешен одговор.

Прашајте го сопственикот кој поддржан работен тек важи наместо тоа. Распоредување што забранува чување обично има причина, а причината често е што сметката е споделена, уредот не е доверлив или акредитивот треба да истече според распоред. Заобиколувањето на поставката ја претвора намерната контрола во инцидент, а инцидентот обично доаѓа со туѓа ревизија прикачена.

На неуправувана инсталација, контролата што недостасува е прашање за поддршка со број на верзија. Испратете ја инсталираната верзија на клиентот и што поканата всушност прикажува, наместо претпоставка за скриени стандардни вредности.

Три покани што не се истата покана

Еднократниот код не е лозинка, лозинката не е овластување на приврзокот за клучеви, а одбивањето од серверот не е ниту едно од трите. Нивното мешање создава дефекти што се читаат како погрешни акредитиви, додека вистинскиот проблем е поле, дијалог или маршрута.

Дијалогот на приврзокот за клучеви е локален по дизајн. Тој прашува дали оваа апликација смее да ја чита оваа ставка на овој компјутер, а неговото одобрување не му кажува ништо на VPN серверот.

Затоа одбивањето на дијалогот создава дефект на страната на клиентот што серверот никогаш не го гледа, додека погрешната лозинка создава одбивање на страната на серверот за кое клиентот може само да извести. Прочитајте го дијалогот пред да одговорите и проверете дали апликацијата што бара е клиентот што го очекувате, а не инсталатер или помошен процес. Разликата е најважна на споделени компјутери, каде што ставката може да биде достапна за повеќе од една сметка.

Вториот фактор стои надвор од сето ова. Чувањето лозинка не го чува кодот, и распоредување што го бара кодот сѐ уште го бара при секоја врска. Држете го тој чекор видлив за време на тестирањето, бидејќи тек што тивко го прескокнува не е текот што сте го конфигурирале.

Враќање на еден акредитив без ресетирање на останатите

Ако автентикацијата не успее по промена на лозинката, користете го документираниот пат на клиентот за повторна покана и ажурирање за таа една врска наместо рачно да го уредувате приврзокот за клучеви. Прочитајте ја пораката пред да замените нешто, бидејќи истекот на времето, одбивањето на сертификатот или маршрутата што недостасува не се поправаат со препишување на зачуваната лозинка. Повторувањето на тоа главно ве учи да ја игнорирате грешката што ја прикажува клиентот. Ажурирајте го засегнатиот акредитив, потоа поврзете се повторно и гледајте која покана се појавува.

Целосното ресетирање на приврзокот за клучеви што го предлагаат форумите за поддршка е многу поголема промена од проблемот. Зачуваната лозинка на една врска нема никаква врска со сертификатот на друга, и бришењето на сѐ претвора една застарена ставка во цело попладне на повторно регистрирање.

Завршете со исклучување и повторно поврзување преку вообичаените контроли, потврдувајќи дека се користи предвидената сметка и дека отстранувањето на зачуваната ставка дава покана наместо дефект. Предвидливо повторно користење со еден јасен начин за ажурирање или отстранување на акредитивот е исходот што вреди да се тестира.

Поврзани статии