VPN MFA વિનંતી નકારી: ક્લાયન્ટે શું કરવું જોઈએ
નકારેલી MFA વિનંતી એ નિષ્ફળ લોગિન છે, ફરી પ્રયાસનું લૂપ નહીં. વિનંતી ઓળખો, નિષ્ફળતા દૃશ્યમાન રાખો અને સપોર્ટ શું માંગશે તે નોંધો.
નકારેલી MFA વિનંતી નેટવર્ક સમસ્યા જેવી લાગે છે અને તે નથી. સર્વરે બીજું પરિબળ માંગ્યું, પરિબળ નકારાત્મક રીતે પાછું આવ્યું અથવા ક્યારેય પહોંચ્યું નહીં, અને કોઈ ટનલ અસ્તિત્વમાં આવે તે પહેલાં સત્ર નકારી કાઢવામાં આવ્યું. તે પછી શું થાય છે તે ક્લાયન્ટના વર્તનનો પ્રશ્ન છે: નિષ્ફળતા દર્શાવો અને વપરાશકર્તાને સ્વચ્છ પ્રયાસ શરૂ કરવા દો, અથવા એવી રીતે ફરી પ્રયાસ કરો જે વધુ વિનંતીઓ બનાવે અને આખરે એકાઉન્ટ સુરક્ષા સક્રિય કરે. બીજો માર્ગ એ છે જેમાં એક ખોટી ટાઇપ કરેલી કોડ લૉક થયેલું એકાઉન્ટ બને છે.
કઈ વિનંતી નિષ્ફળ ગઈ તે તપાસો
કઈ વિનંતી નિષ્ફળ ગઈ તે ઓળખીને શરૂ કરો. પુશ સૂચના, TOTP કોડ, FIDO પ્રમાણ અને SAML પ્રવાહ દરેક અલગ રીતે નિષ્ફળ જાય છે, અને ક્લાયન્ટ સામાન્ય રીતે જાણે છે કે તેણે કઈ માંગી હતી. નકાર, સમાપ્ત થયેલો પડકાર અને ઉપકરણ સુધી ક્યારેય ન પહોંચેલી ડિલિવરી નિષ્ફળતા—બધા એક જ સામાન્ય ભૂલમાં પૂરા થાય છે, તેથી તફાવત ઘણી વાર ફક્ત ક્લાયન્ટની પોતાની સ્થિતિમાં જ ટકી રહે છે.
એ સ્થિતિ ચોકસાઈથી લોગ કરવા યોગ્ય છે. પડકાર ઓળખકર્તા અથવા વ્યવહાર સંદર્ભ, પરિબળનો પ્રકાર, સમયછાપ અને પરિણામ નોંધો, પણ કોડ કે પ્રમાણ ક્યારેય નહીં. પડકાર ઓળખકર્તા એ છે જે વ્યવસ્થાપકને ઓળખ પ્રદાતાની બાજુએ ઘટના શોધવા દે છે; તેના વિના સપોર્ટ વાતચીત “છેલ્લા કલાકમાં ક્યાંક” થી શરૂ થાય છે અને સામાન્ય રીતે ત્યાં જ પૂરી થાય છે. તેને ગુપ્ત માહિતી નહીં, નિદાન મેટાડેટા તરીકે ગણો.
નવા પડકાર સાથે એક વાર, જાણી જોઈને ફરી પ્રયાસ કરો
ફરી પ્રયાસ નવા પડકાર સાથેનો નવો પ્રયાસ હોવો જોઈએ, જૂનાનું પુનરાવર્તન નહીં. જ્યારે ક્લાયન્ટ અગાઉનો પડકાર ફરી વાપરે છે, ત્યારે ઓળખ પ્રદાતા તેને જૂનો ગણીને નકારે છે અથવા, વધુ ખરાબ, અગાઉના પ્રયાસ માટે ધારેલી મંજૂરી સ્વીકારે છે. નવો પડકાર માંગો, તેને દર્શાવો અને વપરાશકર્તાને હમણાં સ્ક્રીન પર રહેલા પડકાર પર કાર્ય કરવા દો.
વચ્ચે ટૂંકા વિરામ સાથે બે પ્રયાસ વાજબી ડિફૉલ્ટ છે; અનંત લૂપ નહીં. જો બીજો પ્રયાસ એ જ રીતે નિષ્ફળ જાય, તો ચાલુ રાખવાને બદલે થોભો અને જાણ કરો.
ક્લાયન્ટે શું ન કરવું જોઈએ
ક્લાયન્ટે એવી ઘણી બાબતો ન કરવી જોઈએ જે મદદરૂપ લાગે છે અને છે નહીં. જ્યાં સુધી કોઈ “મંજૂર” પર ટૅપ ન કરે ત્યાં સુધી પુશ સૂચનાઓ મોકલવાનું ચાલુ ન રાખવું જોઈએ, કારણ કે તે વપરાશકર્તાઓને એવી વિનંતીઓ મંજૂર કરવાનું શીખવે છે જે તેમણે શરૂ કરી ન હતી, અને ફિશિંગ કિટ્સ બરાબર એ જ વર્તન પર આધાર રાખે છે. મજબૂત પરિબળ નિષ્ફળ ગયું તેથી નબળા પરિબળ પર પાછા ન જવું જોઈએ, અને તે જ સમયે દેખાયેલી પ્રમાણપત્ર ફરિયાદને ટાળવા સર્વર-ઓળખ તપાસ બંધ ન કરવી જોઈએ. એ ત્રણ ટૂંકા રસ્તાઓમાંથી દરેક પ્રમાણીકરણની નિષ્ફળતાને સુરક્ષા ઘટનામાં ફેરવે છે.
તેમજ નિષ્ફળતાને ચૂપચાપ ગળી ન લેવી જોઈએ. જે ક્લાયન્ટ જોડાણ બંધ કરીને સ્પિનર દર્શાવે છે તે વપરાશકર્તાને ફરી પ્રયાસ કરવો, રાહ જોવી કે સપોર્ટને ફોન કરવો—એની કોઈ કલ્પના વિના છોડી દે છે. પરિબળના પ્રકાર અને ટૂંકા કોડ સાથે નિષ્ફળતા દર્શાવો, સંદેશને ગુપ્ત માહિતીથી મુક્ત રાખો અને ફરી પ્રયાસની ક્રિયાને સ્વયંસંચાલિત નહીં, સ્પષ્ટ બનાવો.
જો વિનંતી કીબોર્ડ પરની વ્યક્તિએ શરૂ ન કરી હોય, તો યોગ્ય ક્રિયા તેને નકારેલી રાખવી અને ચકાસાયેલા સપોર્ટ માર્ગ દ્વારા જાણ કરવી છે. ઘોંઘાટ બંધ કરવા વિનંતી મંજૂર કરવી એ નિષ્ફળતાની પેટર્ન છે, ઉપાય નહીં.
સપોર્ટ માટે શું નોંધવું
સપોર્ટ માટે ઉપયોગી રેકોર્ડ નાનો છે. સમય ક્ષેત્ર સાથે અંદાજિત સમય, એકાઉન્ટ, ક્લાયન્ટ અને આવૃત્તિ, પરિબળનો પ્રકાર, અને દરેક પ્રયાસની બિન-ગુપ્ત સ્થિતિ: માંગવામાં આવી, નકારી, સમય પૂરો થયો, મંજૂર પણ નીતિથી નકારી.
ક્લાયન્ટ અને સર્વરની ઘડિયાળો પણ ધ્યાનમાં રાખો. TOTP સમય-વિન્ડોની તપાસ છે, તેથી જે ઉપકરણની ઘડિયાળ ખસી ગઈ છે તે માન્ય દેખાતા કોડ બનાવે છે જે દર વખતે નિષ્ફળ જાય છે, અને જે ક્લાયન્ટ ખસેડાવાની નોંધ લીધા વિના અમાન્ય કોડની જાણ કરે છે તે લોકોને એવા ઓળખપત્રો રીસેટ કરવા મોકલે છે જે ક્યારેય ખોટા ન હતા. જે વપરાશકર્તાનું લોગિન વારંવાર નિષ્ફળ જાય છે તેણે વધુ વિનંતીઓ બનાવતા પહેલાં સમર્થિત ક્લાયન્ટ આવૃત્તિ, નોંધણીની સ્થિતિ અને દસ્તાવેજીકૃત પુનઃપ્રાપ્તિ પ્રવાહ તપાસવો જોઈએ.
પુનઃપ્રાપ્તિનો માર્ગ લોગિનના માર્ગ જેટલી જ કાળજી લાયક છે. ખોવાયેલા ઉપકરણ માટેનો કાર્યપ્રવાહ બરાબર એ માટે અસ્તિત્વમાં છે કે નકાર પ્રમાણીકરણ ટાળવાની પરવાનગી ન બને, અને ક્લાયન્ટે પોતાનો શોધવાને બદલે સંસ્થાની દસ્તાવેજીકૃત પ્રક્રિયાની લિંક આપવી જોઈએ.
જે નિયમ સામે નિર્માણ કરવું તે છે: નકાર એ પરિણામ છે, અવરોધ નહીં. તેની એક વાર, સ્પષ્ટપણે, કાર્ય કરવા પૂરતા સંદર્ભ સાથે જાણ કરો, અને આગળનો પ્રયાસ નવો થવા દો. ફિશિંગ-પ્રતિરોધક MFA અંગે CISAનું માર્ગદર્શન સમજાવે છે કે “મંજૂરી મળે ત્યાં સુધી પૂછો” પેટર્ન શરૂઆતથી જ કેમ જોખમી છે, અને કોઈ ફરી પ્રયાસનું લૂપ સૂચવે ત્યારે તે જ ટાંકવા લાયક સંદર્ભ છે. નકાર પછી ક્લાયન્ટ જે ઉમેરે તે બધું આગળનો નિર્ણય માણસ માટે સરળ બનાવવો જોઈએ, નિર્ણય તેની પાસેથી લઈ લેવો નહીં.