Windows પર EAP-TLS સાથે PIV લોગિન નિષ્ફળ? સહી કરવાનો માર્ગ તપાસો

દરેક Windows સંવાદમાં PIV કાર્ડનું પ્રમાણપત્ર બતાવો અને VPN લોગિન તો પણ નિષ્ફળ થઈ શકે છે, કારણ કે દૃશ્યતા અને ઉપયોગક્ષમતા અલગ ગુણધર્મો છે. પ્રમાણપત્ર જાહેર વસ્તુ છે; લોગિનને કાર્ડ દ્વારા તેના પોતાના પ્રવેશ નિયમો હેઠળ કરવામાં આવતી ખાનગી કીની ક્રિયાની જરૂર છે. આ બે હકીકતો વચ્ચે ચાર તબક્કા છે જે ચાર જુદી રીતે નિષ્ફળ જાય છે: પ્રોફાઇલ પસંદગી, પ્રમાણપત્ર પસંદગી, સ્થાનિક સહી અને સર્વર બાજુની માન્યતા. તેમને ક્રમમાં પસાર કરવાથી સામાન્ય હેન્ડશેક ભૂલ આગળના ભાગના માલિક માટે ચોક્કસ પ્રશ્નમાં ફેરવાય છે.

પ્રોફાઇલ અને EAP પદ્ધતિથી શરૂ કરો

કનેક્શનના ગુણધર્મો ખોલો અને વાંચો કે પ્રોફાઇલ ખરેખર કઈ EAP પદ્ધતિ વાપરે છે, પછી વાંચો કે પદ્ધતિ કયું પ્રમાણપત્ર પસંદ કરવા માટે ગોઠવાયેલી છે. ઘણા ડિપ્લોયમેન્ટમાં પ્રમાણપત્ર આધારિત બાહ્ય પદ્ધતિ અને આંતરિક પદ્ધતિ બંને હોય છે, અને કનેક્શન સ્તરે ગોઠવાયેલું પ્રમાણપત્ર આપોઆપ EAP-TLSની અંદર રજૂ થતું નથી. જો પ્રોફાઇલ જારીકર્તા અથવા વિષય ફિલ્ટર દ્વારા પ્રમાણપત્ર પસંદ કરે, તો તે ફિલ્ટર સંબંધિત સ્ટોરમાં Windows જે જોઈ શકે તેમાંથી પસંદ કરે છે, કાર્ડમાં જે છે તેમાંથી નહીં. કંઈપણ સાથે ન મેળ ખાતું ફિલ્ટર પ્રોફાઇલની ગોઠવણી પ્રમાણે પ્રોમ્પ્ટ અથવા શાંત નિષ્ફળતા તરફ પાછું જાય છે, તેથી કોઈપણ ફેરફાર પહેલાં પસંદ કરેલી થમ્બપ્રિન્ટ નોંધવી યોગ્ય છે.

એ પણ નક્કી કરો કે કનેક્શન સાઇન-ઇન કરેલા વપરાશકર્તા તરીકે ચાલે છે કે મશીન તરીકે. તે એક જ હકીકત નક્કી કરે છે કે કયા પ્રમાણપત્ર સ્ટોર અવકાશમાં છે અને કયો સુરક્ષા સંદર્ભ સહી કરે છે.

કયું પ્રમાણપત્ર પસંદ થયું તેની ખાતરી કરો

Windows એ પસંદ કરેલી થમ્બપ્રિન્ટની જરૂરિયાત સાથે સરખામણી કરો: ક્લાયન્ટ પ્રમાણીકરણ માટેનો ઉપયોગ, વિશ્વસનીય મૂળમાં પૂરી થતી સાંકળ, પ્રમાણીકરણ સર્વરની નીતિ મેપ કરે તેવી ઓળખ, અને પ્રયાસની વાસ્તવિક ક્ષણને આવરી લેતો માન્યતા સમયગાળો. આ અલગ તપાસો છે અને છેલ્લી લોકો ધારે તેના કરતાં વધુ આશ્ચર્ય પકડે છે, ખાસ કરીને રોલિંગ ધોરણે જારી થતાં પ્રમાણપત્રો અને કેશ થયેલી પ્રોફાઇલ સાથે જે હજુ ગઈકાલની પસંદગી તરફ ઈશારો કરે છે.

વપરાશકર્તા અને મશીન સંદર્ભ તપાસનો બીજો અડધો ભાગ છે. વપરાશકર્તાના વ્યક્તિગત સ્ટોરમાંનું પ્રમાણપત્ર મશીન તરીકે ચાલતી સેવા માટે અદૃશ્ય છે, અને મશીન પ્રમાણપત્ર પ્રોફાઇલ કહે ત્યાં સુધી વપરાશકર્તા મોડ EAP વિનિમય દ્વારા રજૂ થતું નથી. પ્રમાણપત્રને ખોટા સ્ટોરમાં ફરી આયાત કરવાથી દૃશ્ય પ્રમાણપત્ર અને અદૃશ્ય લોગિન ક્રેડેન્શિયલ બને છે. પ્રોફાઇલમાં સ્ટોરનો માર્ગ વાંચો, આકસ્મિક રીતે ખૂલેલા સંવાદનો નહીં.

PIN અનુમાન કર્યા વિના કીની ક્રિયા ચકાસો

પસંદગી નક્કી થયા પછી પ્રશ્ન એ છે કે કાર્ડ સહી કરશે કે નહીં. ખાનગી કી સુધી પહોંચવા માટે Windows ને સમર્થિત કાર્ડ પ્રદાતા અથવા મિનિડ્રાઇવરની જરૂર છે, અને ઉપકરણ તેની પોતાની PIN અને હાજરીના નિયમો ક્રિયા પર લાગુ કરે છે. દરેક સહી માટે સ્પર્શની માંગ કરતું કાર્ડ સત્ર માટે ચકાસણી કેશ કરતા કાર્ડથી અલગ વર્તે છે, અને બંને કાયદેસર ગોઠવણીઓ છે જે પ્રોમ્પ્ટ ક્યારે દેખાય તે બદલે છે. તે તફાવત સમજાવે છે કે નવા નાખ્યા પર લોગિન સફળ થાય અને ફરી શરૂ કર્યા પછી નિષ્ફળ જાય, કોઈ પ્રમાણપત્ર ખોટું હોવા વિના.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

પ્રથમ આદેશ કાર્ડની યાદી બનાવે છે અને રીડર તથા પ્રદાતાની સ્થિતિ જણાવે છે, જે Microsoftના સ્માર્ટ-કાર્ડ ડિબગિંગ માર્ગદર્શનમાં દસ્તાવેજીકૃત છે. બીજો આદેશ યાદી બનાવે છે કે વપરાશકર્તા સંદર્ભ ખરેખર શું જોઈ શકે છે. કોઈ પણ સફળ પ્રમાણીકરણ સાબિત કરતું નથી; બંને ક્યાં અટક્યું તે સાંકડું કરે છે.

PIN અનુમાન કરશો નહીં. કાર્ડ ફરી પ્રયાસની મર્યાદા લાદે છે, અને થોડા આશાવાદી પ્રયાસો પરવાનગીની સમસ્યાને વહીવટી પુનઃપ્રાપ્તિની જરૂર પડતા અવરોધિત ક્રેડેન્શિયલમાં ફેરવે છે. સ્થાનિક સહી નિષ્ફળ જાય તો વિકલ્પો અજમાવવાને બદલે પ્રદાતાની સ્થિતિ અને કાર્ડની સ્થિતિ કેપ્ચર કરો. તે જ પ્રોફાઇલ, તે જ પ્રમાણપત્ર અને જાણીતા સારા રીડર માર્ગ સાથે પ્રયાસ એક વાર પુનરાવર્તિત કરો, પછી બંને રેકોર્ડની સરખામણી કરો; એકસાથે ઘણા ચલ બદલવાથી પરિણામને બદલે વાર્તા બને છે.

હેન્ડશેકની બંને બાજુ વાંચો

પૂર્ણ થયેલી સહી હજુ પ્રવેશ નથી. પ્રમાણીકરણ સર્વરે સાંકળ સ્વીકારવી, રદ કરવાની ચકાસણી કરવી, તેના વર્તમાન નિયમો હેઠળ ઓળખ મેપ કરવી અને વિનંતીને અધિકૃત કરવી જોઈએ; ક્લાયન્ટે બદલામાં પ્રોફાઇલ માંગે તેમ સર્વરના પ્રમાણપત્રની માન્યતા કરવી જોઈએ. સર્વર દ્વારા ઉત્પન્ન થયેલી TLS ચેતવણી ક્લાયન્ટના લોગમાં સ્થાનિક રીતે ઉત્પન્ન થયેલી જેવી જ દેખાય છે, તેથી ચેતવણીના લખાણ કરતાં જે બાજુ તેને બહાર કાઢે છે તે વધુ મહત્ત્વની છે.

સંરેખિત ટાઇમસ્ટેમ્પ સાથે Windows ઘટનાઓ અને સર્વર બાજુની ઘટનાઓ એકત્ર કરો, પછી નક્કી કરો કે પ્રથમ નિષ્ફળતા કઈ બાજુએ ઉત્પન્ન કરી. RFC 5216 EAP-TLSમાં કબજાના પુરાવાના પગલાનું વર્ણન કરે છે, અને સામાન્ય હેન્ડશેક ચેતવણી પોતાની રીતે સ્થાનિક કી કારણનું નામ લેતી નથી. ટાઇમસ્ટેમ્પની સરખામણી જ બે લોગને ક્રમમાં ફેરવે છે.

અહેવાલમાં સીમાઓ સીધી રાખો

અહેવાલ ચાર તબક્કા તરીકે લખો, દરેક માટે એક ચુકાદો: કઈ પ્રોફાઇલ અને સંદર્ભ ચાલ્યા, Windows કયું પ્રમાણપત્ર પસંદ કર્યું, કાર્ડે સહી કરી કે નહીં, અને સર્વરે શું નક્કી કર્યું. તે માળખું આગળનું પગલું સ્પષ્ટ કરે છે અને કોઈએ ઓળખ ન કરેલા તબક્કાને પાર કરવા માન્યતા બંધ કરવાની સામાન્ય મરામત અટકાવે છે.

કામચલાઉ સરખામણી તરીકે સોફ્ટવેર પ્રમાણપત્ર કાયદેસર વ્યવસ્થાપક પરીક્ષણ છે, પરંતુ તે ક્રેડેન્શિયલ અને ખાતરીનું નમૂનો બદલે છે, તેથી તેનું સ્થાન મંજૂર થયેલા ફેરફારમાં છે, ઉત્પાદનમાં શાંત વિકલ્પમાં નહીં. તે જ શિસ્ત PIN પ્રયાસો અને નિષ્ફળ તબક્કો જાણીતો થાય તે પહેલાં ક્રેડેન્શિયલ ફરી જારી કરવા પર લાગુ પડે છે. સમાન રીતે નિષ્ફળ થતું બદલીનું કાર્ડ એ ખર્ચાળ પુરાવો છે કે સમસ્યા કદી કાર્ડ પર ન હતી.