બે લોગિન ચકાસણી એ બે પરિબળ નથી: VPN અને RADIUS

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

બીજું બેકએન્ડ ખરેખર શું સાબિત કરે છે

સ્થાનિક ખાતાની શોધ સાબિત કરે છે કે નામ ડેટાબેઝમાં છે અને પાસવર્ડ તેની સાથે મેળ ખાતો હતો. RADIUS આદાન-પ્રદાન સાબિત કરે છે કે RADIUS સર્વર મળેલા લક્ષણો માટે Access-Accept પરત કર્યું. બંનેમાંથી કોઈ વિધાન પરિબળ પ્રકારનો ઉલ્લેખ કરતું નથી, કારણ કે બંને જ્ઞાનની ચકાસણી કરે છે. અને NIST ની ડિજિટલ ઓળખ માર્ગદર્શિકા અલગ પરિબળ પ્રકારો અને તેમના પ્રમાણકોની ગણતરી કરે છે, સર્વર કે સૂચનાઓની નહીં.

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

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

AND, OR અને ફોલબેક અલગ ઉત્પાદનો છે

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

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

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

OpenVPN ની બમણી ચકાસણી એક ઠોસ કિસ્સો છે

સમુદાય OpenVPN 2.6 જ્યારે બંને સક્ષમ હોય ત્યારે ક્લાયન્ટ પ્રમાણપત્ર અને ગોઠવેલ auth-user-pass-verify સ્ક્રિપ્ટ બંનેની જરૂર રાખે છે. તે પ્રમાણપત્ર ચકાસણી અને ઓળખપત્ર સ્ક્રિપ્ટ વચ્ચેનું દસ્તાવેજીકૃત AND છે, અને તે ખરેખર બે ચકાસણી છે. તે હજી પણ આપમેળે બે પરિબળ પ્રકાર નથી, કારણ કે સ્ક્રિપ્ટ ફક્ત પાસવર્ડની માન્યતા ચકાસી શકે છે.

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

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

ઉપકરણ ઉત્પાદકો પોતાની પ્લમ્બિંગ બનાવે છે, ઘણી વખત વેબ કન્સોલ પાછળ PAM મોડ્યુલ અથવા RADIUS પ્લગઇન. સમુદાયનું વર્તન ડબલ ચકાસણી કેવી દેખાય છે તેનો સંદર્ભ છે, ઉપકરણ તેમને કેવી રીતે જોડે છે તેનું વર્ણન નહીં.

તમારા ગેટવે પર સંયોજન ચકાસો

કન્સોલ સારાંશ પર ભરોસો કરતાં પહેલાં કન્ફિગરેશન વાંચો. નીતિ નક્કી કરતી લીટીઓ પ્રમાણપત્ર મોડ, ઓળખપત્ર સ્ક્રિપ્ટ અને પ્લગઇન ક્રમ છે.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep દર્શાવે છે કે પ્રમાણપત્ર જરૂરી છે કે નહીં અને તેના પછી કઈ સ્ક્રિપ્ટ ચાલે છે, અને ક્રમ નામો સૂચવે તેના કરતાં વધુ મહત્ત્વનો છે. પ્રમાણપત્ર ડમ્પ ગેટવે જે ઓળખ જોશે તે આપે છે, જેમાં સંકળાયેલા નકશા માટે જરૂરી CN અને અનુક્રમ નંબરનો સમાવેશ થાય છે. RADIUS પરીક્ષા નકારાત્મક કિસ્સો છે: ખોટા પાસવર્ડે Access-Reject અને સાચાએ Access-Accept આપવું જોઈએ. જો નકારેલું ઓળખપત્ર હજી પણ સત્ર આપે, તો સ્ક્રિપ્ટ પ્રમાણીકરણ માર્ગ પર જ નથી.

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

જરૂરિયાતને નકારાત્મક કિસ્સાઓ તરીકે લખો

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

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

કોઈપણ પ્લગઇન કે ફર્મવેર ફેરફાર પછી ચાર નકાર ફરી ચલાવો. તેઓ સસ્તા છે, અને જે નીતિનું તેઓ રક્ષણ કરે છે તે જ હુમલાખોર પહેલાં તપાસે છે.