Protected Users લેપટોપને સાઇન-ઇન પહેલાં VPN કેમ જરૂરી છે

લેપટોપ, કાર્યક્ષમ ખાતું અને હોટેલ નેટવર્ક મળીને સાઇન-ઇન લૂપ બનાવે છે જેને કોઈ પુનઃપ્રયાસ તોડતું નથી. ખાતું Protected Users માં છે, જે Windowsને એ ચકાસક સંગ્રહિત કરવાથી રોકે છે જે વપરાશકર્તાને ઑફલાઇન પ્રમાણિત કરવા માટે જરૂરી હોય. «પહેલાં સાઇન ઇન કરો, પછી ટનલ જોડો» જેવી કોઈપણ યોજનામાં ક્રમ ઉલટો છે, અને સુરક્ષા બરાબર એ જ કરે છે જેનું વચન તે આપે છે. આગળનું સમર્થિત Windows હોસ્ટ પર પરંપરાગત Active Directory ખાતું ધારે છે.

સુરક્ષા ખરેખર શું દૂર કરે છે

Windows સામાન્ય રીતે ચકાસક કૅશ કરે છે જેથી ડોમેન ખાતું ડોમેન કંટ્રોલર અપ્રાપ્ય હોય ત્યારે પણ સાઇન ઇન કરી શકે. Protected Users ખાતા માટે તેને અવરોધે છે, જે ઑફલાઇન ડોમેન સાઇન-ઇનને બિનવિશ્વસનીય બનાવવાને બદલે શક્યતા તરીકે દૂર કરે છે.

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

ટનલ ડેસ્કટોપ પહેલાં કેમ હોવી જોઈએ

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

એન્ડપૉઇન્ટ અને ઓળખ માલિકો સાથે સંમત સમર્થિત પૂર્વ-લૉગિન ગોઠવણ વાપરો. કમ્પ્યુટર પ્રમાણપત્ર સાથે પ્રમાણિત Always On VPN ઉપકરણ ટનલ ત્યારે યોગ્ય છે જ્યારે સંચાલિત ઉપકરણ તે જમાવટની પૂર્વશરતો પૂરી કરે. વેન્ડરનું સમર્થિત સાઇન-ઇન સ્ક્રીન એકીકરણ બીજો વિકલ્પ છે. સ્વયં ટ્રિગર સાથેની સામાન્ય વપરાશકર્તા પ્રોફાઇલ એ બેમાંથી કોઈ નથી, ક્લાઇન્ટ ઇન્ટરફેસમાં ગમે તેટલી સમાન લાગે.

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

પ્રાપ્યતા પ્રમાણીકરણ સુસંગતતા નથી

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

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

પ્રમાણીકરણના પુરાવા વાંચો

એક જ પ્રયાસ માટે ક્લાઇન્ટ અને ડોમેન કંટ્રોલર બંનેમાંથી ઘટનાઓ એકત્ર કરો, ફક્ત એક બાજુથી નહીં. Protected Users ના લૉગ Applications and Services Logs\Microsoft\Windows\Authentication હેઠળ છે, અને કંઈ પણ નોંધાય તે પહેલાં વ્યવસ્થાપકે લૉગ ચાલુ કરવો પડી શકે. સમયછાપોને ટનલના પોતાના જોડાણ લૉગ સાથે સહસંબંધિત કરો, કારણ કે ક્રમની ભૂલ બંને બાજુથી ક્રેડેન્શિયલ ખામી જેવી લાગે છે.

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

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

ઠંડા બૂટથી સીમા સાબિત કરો

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

1. કોઈ સાઇન ઇન કરે તે પહેલાં ઉપકરણ ડોમેન કંટ્રોલર શોધી શકે છે તે nltest /dsgetdc:corp.example.com વડે પુષ્ટિ કરો.
2. ડોમેન સાઇન-ઇનનો પ્રયાસ કરો, પછી klist વડે પૂછો કે ટિકિટ મળી હતી કે નહીં.
3. ઉપકરણ જે પ્રમાણીકરણ લૉગ નોંધે છે તે ઉપરના બે આદેશોથી વાંચો, અને પૅકેજ તથા નિષ્ફળતાની શરત નોંધો.
4. મંજૂર પુનઃપ્રાપ્તિ ક્રેડેન્શિયલ હજી સાઇન-ઇન સ્ક્રીનથી કામ કરે છે તે પુષ્ટિ કરો, કારણ કે સીમા પરીક્ષણ નિષ્ફળ જાય તો પાછા ફરવાનો એ જ એકમાત્ર રસ્તો છે.

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

Protected Users દસ્તાવેજીકરણ ચકાસકના વર્તન અને આ રચના જે ડોમેન નિયંત્રણો પર આધારિત છે તે બંનેનું વર્ણન કરે છે. કોઈ મુસાફરી કરે તે પહેલાં પુનઃપ્રાપ્તિ પ્રક્રિયાનું આયોજન કરો, કારણ કે ઠંડા-બૂટ પરીક્ષણ એ જ એકમાત્ર જગ્યા છે જ્યાં તેનો અભ્યાસ થાય છે.