FortiGate VPN MFA: స్థానిక టోకెన్, 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 ప్రారంభించబడింది» అనేదాన్ని మరొకరు నిర్వహించగల డిజైన్గా మారుస్తుంది.