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 ਸਮਰੱਥ ਹੈ» ਨੂੰ ਅਜਿਹੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਹੋਰ ਚਲਾ ਸਕੇ।