FortiGate VPN MFA: સ્થાનિક ટોકન, RADIUS કે SAML?

ગેટવે, RADIUS બેકએન્ડ અથવા SAML પ્રદાતા દરેક પરિબળ ચકાસી શકે છે, અને દરેક જુદી રીતે નિષ્ફળ જાય છે. સેવા, ક્લાયન્ટ અને પુનઃપ્રાપ્તિ માર્ગ મેળવો.

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

લોગિન વિધિ નક્કી કરે છે કે પરિબળ કોની પાસે છે

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

આ તફાવત નક્કી કરે છે કે તમે કયા પુરાવા એકત્ર કરી શકો છો. જ્યારે ગેટવે ચકાસે છે, ત્યારે તેનું પોતાનું ડિબગ આઉટપુટ તમને કહે છે કે શું થયું. જ્યારે ઓળખ પ્રદાતા ચકાસે છે, ત્યારે ગેટવેને ફક્ત એટલું ખબર હોય છે કે દાવો આવ્યો, અને «MFA ખરેખર જરૂરી હતું કે નહીં» તેનો જવાબ પ્રદાતાના લોગમાં હોય છે, ફાયરવોલના લોગમાં નહીં. ખોટો લોગ વાંચવો એ ડિઝાઇન પ્રમાણે જ ચાલતી તૈનાતીને ખોટી રીતે નિદાન કરવાનો સૌથી સામાન્ય માર્ગ છે. સેવા પોતે પણ વિધિને મર્યાદિત કરે છે: FortiOS 7.6.3 SSL VPN ટનલ મોડ દૂર કરે છે અને IPsec તરફ જાય છે, જ્યારે વેબ મોડ સપોર્ટેડ મોડેલો પર Agentless VPN તરીકે ચાલુ રહે છે, તેથી એક સેવામાં સાબિત થયેલી વિધિ આપોઆપ બીજીમાં ઉપલબ્ધ નથી.

સ્થાનિક ચકાસણી: ટોકન અને ઇમેઇલ કોડ

FortiGate દ્વારા સંચાલિત પરિબળો વપરાશકર્તા ઑબ્જેક્ટ સાથે જોડાય છે. FortiToken અથવા દસ્તાવેજીકૃત ટોકન એકીકરણને નોંધણી, સપોર્ટેડ ચકાસણી વિધિ, જ્યાં લાગુ પડે ત્યાં લાઇસન્સ અને બદલી પ્રક્રિયાની જરૂર છે. ઇમેઇલ કોડને કામ કરતો SMTP માર્ગ અને એવું મેઇલબોક્સ જોઈએ જ્યાં ટનલ બનતા પહેલા વપરાશકર્તા પહોંચી શકે; આ એવી અવલંબન છે જેનો ક્રિપ્ટોગ્રાફી સાથે કોઈ સંબંધ નથી અને કોઈ લોગિન કરી શકે છે કે નહીં તેની સાથે પૂરો સંબંધ છે.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

ખાતરીની આવશ્યકતાઓ પણ અહીં આવે છે, ઉત્પાદન પસંદગી પહેલાં. NIST SP 800-63B ઇમેઇલને આઉટ-ઓફ-બેન્ડ પ્રમાણીકરણ માટે અસ્વીકાર્ય માને છે, તેથી અનુરૂપતાનો દાવો કરતી તૈનાતી ઇમેઇલ કોડને બીજા પરિબળ તરીકે વાપરી શકતી નથી, ભલે તે ગમે તેટલો અનુકૂળ હોય. ઉપકરણ પર સુવિધા હોવી એ એવું નિવેદન નથી કે સુવિધા આપેલા ધોરણને પૂર્ણ કરે છે.

RADIUS: ગેટવે પૂછે છે, બેકએન્ડ નક્કી કરે છે

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

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

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

diagnose debug application fnbamd -1
diagnose debug enable

SAML: બ્રાઉઝર ગેટવે છોડે છે

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

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

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

પુનઃપ્રાપ્તિ મિકેનિઝમનો ભાગ છે

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

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

સંબંધિત લેખો