AWS Client VPN SAML ਅਤੇ Google Workspace: ਕਾਲਬੈਕ ਦਾ ਖੱਪਾ

app_not_configured_for_user ਸਫ਼ਾ Google Workspace ਤੋਂ ਆਉਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵੀ ਟਨਲ ਪੈਕਟ ਦੀ ਗੱਲਬਾਤ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਕ੍ਰਮ ਪੂਰਾ ਨਿਦਾਨ ਹੈ। ਕਲਾਇੰਟ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨਾ, ਪ੍ਰੋਫ਼ਾਈਲ ਸੋਧਣਾ ਜਾਂ ਰੂਟ ਜਾਂਚਣਾ VPN ਐਂਡਪੌਇੰਟ ਵੱਲੋਂ ਅਜੇ ਨਾ ਦੇਖੇ ਸਫ਼ੇ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਕਦਮ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੀ ਆਪਣੀ ਮਸ਼ੀਨ ਉੱਤੇ ਸੁਣਨ ਵਾਲੇ ਵਿਚਕਾਰ ਬ੍ਰਾਊਜ਼ਰ ਹਸਤਾਂਤਰਣ ਹੈ, ਅਤੇ ਉਸ ਹਸਤਾਂਤਰਣ ਵਿੱਚ ਠੀਕ ਤਿੰਨ ਚੀਜ਼ਾਂ ਜਾਂਚਣ ਯੋਗ ਹਨ।

ਸਫ਼ੇ ਨੂੰ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਦੇ ਬਿਆਨ ਵਜੋਂ ਪੜ੍ਹੋ

Google ਇਹ ਤਦ ਭੇਜਦਾ ਹੈ ਜਦੋਂ ਸਾਈਨ ਇਨ ਕੀਤੇ ਖਾਤੇ ਲਈ SAML ਐਪਲੀਕੇਸ਼ਨ ਸਮਰੱਥ ਨਹੀਂ ਹੁੰਦਾ। ਐਪ ਬੰਦ ਹੋ ਸਕਦਾ ਹੈ, ਵਰਤੋਂਕਾਰ ਦਿੱਤੀ ਸੰਗਠਨਾਤਮਕ ਇਕਾਈ ਜਾਂ ਸਮੂਹ ਤੋਂ ਬਾਹਰ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਬੇਨਤੀ ਨਾਲ ਮੇਲ ਨਾ ਖਾਂਦੀਆਂ ਹੋਣ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਰਟੀਫਿਕੇਟ, ਰੂਟ ਜਾਂ ਟਨਲ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ, ਭਾਵੇਂ ਵਰਤੋਂਕਾਰ ਨੇ ਇਹ VPN ਕਲਾਇੰਟ ਵਿੱਚ ਵੇਖੀ ਹੋਵੇ।

ਕਲਾਇੰਟ ਵੱਲੋਂ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਦੋ ਮੁੱਲ

AWS Client VPN ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤਾ SAML ਵਟਾਂਦਰਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਬ੍ਰਾਊਜ਼ਰ ਖੋਲ੍ਹਦਾ ਹੈ, ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਦਾਤਾ ਦਸਤਖ਼ਤ ਕੀਤਾ ਦਾਅਵਾ Assertion Consumer Service URL ਉੱਤੇ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। AWS ਵੱਲੋਂ ਦਿੱਤੇ ਡੈਸਕਟਾਪ ਕਲਾਇੰਟ ਲਈ ਉਹ URL loopback ਉੱਤੇ ਸੁਣਨ ਵਾਲਾ ਹੈ, ਆਮ ਤੌਰ ਉੱਤੇ ਪੋਰਟ 35001, ਅਤੇ ਉਮੀਦ ਕੀਤੇ ਦਰਸ਼ਕ Client VPN SAML ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇਕਾਈ ਪਛਾਣ ਹਨ, AWS ਕੰਸੋਲ ਦੀ ਸਾਈਨ-ਇਨ ਇਕਾਈ ਨਹੀਂ।

ਦੋਵੇਂ ਮੁੱਲ ਕਲਾਇੰਟ ਦੀ ਉਮੀਦ ਨਾਲ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ: ਦਾਅਵਾ ਕਿੱਥੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਿਸ ਨੂੰ ਸੰਬੋਧਿਤ ਹੈ। ਕੰਸੋਲ ਦੀ SSO ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਕਾਪੀ ਕੀਤੀ ਸੰਰਚਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰੋਸੇਯੋਗ ਲੱਗ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਗਲਤ ਜੋੜੀ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾ ਸਕਦੀ ਹੈ।

ਦੋਵੇਂ ਮੁੱਲ Client VPN SAML ਦੀਆਂ ਲੋੜਾਂ ਤੋਂ ਲਵੋ, ਆਮ AWS ਸਿੰਗਲ ਸਾਈਨ-ਆਨ ਗਾਈਡ ਤੋਂ ਨਹੀਂ। ਕੰਸੋਲ ਦੀ SSO ਇਕਾਈ ਲਾਲਚ ਦੇਣ ਜਿੰਨੀ ਮਿਲਦੀ ਹੈ। ਇਹ ਵੱਖਰੇ ਦਰਸ਼ਕਾਂ ਵਾਲੀ ਵੱਖਰੀ ਐਪਲੀਕੇਸ਼ਨ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਬਿਨਾਂ ਵਿਆਖਿਆ ਕੀਤੇ ਦਾਅਵਾ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਜੋੜੀ ਇੱਕ ਵਾਰ ਕਾਪੀ ਕਰੋ ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਦੇ ਕੋਲ ਰੱਖੋ।

Google ਸਧਾਰਨ HTTP ਕਾਲਬੈਕ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੇਗਾ

ਪ੍ਰਬੰਧਕ ਕੰਸੋਲ HTTPS ACS URL ਮੰਗਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਕਾਲਬੈਕ loopback ਉੱਤੇ ਸਧਾਰਨ HTTP ਹੈ। ਉਹ ਮੁੱਲ Workspace ਐਪ ਸੰਰਚਨਾ ਵਿੱਚ ਲਿਖਿਆ ਹੀ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਕੁਝ ਟੀਮਾਂ TLS ਖ਼ਤਮ ਕਰਕੇ ਸਥਾਨਕ ਸੁਣਨ ਵਾਲੇ ਵੱਲ ਭੇਜਣ ਵਾਲਾ ਉਲਟਾ ਪ੍ਰੌਕਸੀ ਅਜ਼ਮਾਉਂਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਅਸੰਗਤੀ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀ: ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਮੂਲ ਵੇਖਦਾ ਹੈ, ਕਲਾਇੰਟ ਦੂਜਾ ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਾਪਸ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਗਲਤ ਮੰਜ਼ਿਲ ਉੱਤੇ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।

ਜੋ ਪ੍ਰਬੰਧ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਦਲਾਲ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਹੈ। ਦਲਾਲ ਕੋਲ ਦੀ SAML ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ loopback ਕਾਲਬੈਕ ਅਤੇ AWS ਦਰਸ਼ਕ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਦਲਾਲ Workspace ਖਾਤੇ ਨੂੰ ਉੱਪਰ ਵੱਲ ਫੈਡਰੇਟ ਕਰਦਾ ਹੈ। Google ਦਾ HTTPS ਨਿਯਮ ਪੂਰਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਦਾਅਵਾ ਅਜੇ ਵੀ ਉਮੀਦ ਕੀਤੇ ਪਤੇ ਅਤੇ ਦਰਸ਼ਕਾਂ ਦਾ ਨਾਂ ਲੈਂਦਾ ਹੈ।

ਉਹ ਦਲਾਲ ਪ੍ਰਬੰਧਕੀ ਨਿਰਭਰਤਾ ਹੈ ਜਿਸ ਦੀ ਮਾਲਕੀ ਕੋਈ ਲੈਣਾ, ਨਿਗਰਾਨੀ ਕਰਨਾ ਅਤੇ ਨੌਕਰੀ ਛੱਡਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਇਹ ਦੂਜੀ ਥਾਂ ਵੀ ਹੈ ਜਿੱਥੇ ਰੁਕਾਵਟ ਲੌਗਇਨ ਅਸਫਲਤਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਡਿਜ਼ਾਈਨ ਦਾ ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਦੀ ਕੀਮਤ ਲਾਓ। ਜੇ ਕੋਈ ਇਸ ਦੀ ਮਾਲਕੀ ਨਹੀਂ ਲੈਂਦਾ, ਤਾਂ ਇਮਾਨਦਾਰ ਜਵਾਬ ਇਹ ਹੈ ਕਿ AWS ਕਲਾਇੰਟ Workspace ਨੂੰ ਆਪਣੇ ਇੱਕੋ ਇੱਕ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਵਜੋਂ ਵਰਤ ਨਹੀਂ ਸਕਦਾ।

ਅਲਾਟ ਅਤੇ ਦੋ-ਪੜਾਅ ਪੁਸ਼ਟੀ

ਕੁਝ ਵੀ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਐਪ ਸਹੀ ਸੰਗਠਨਾਤਮਕ ਇਕਾਈ ਜਾਂ ਸਮੂਹ ਲਈ ਚਾਲੂ ਹੈ, ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ SAML ਐਪਾਂ ਕੋਲ Google ਪਾਸੇ ਦੀ ਐਪ ਸੂਚੀ ਤੋਂ ਵੱਖਰੇ ਆਪਣੇ ਅਲਾਟ ਨਿਯੰਤਰਣ ਹਨ।

ਇਹ ਵੀ ਜਾਂਚੋ ਕਿ ਖਾਤੇ ਉੱਤੇ ਦੋ-ਪੜਾਅ ਪੁਸ਼ਟੀ ਚਾਲੂ ਹੈ ਜਾਂ ਨਹੀਂ। Google ਇਸ ਨੂੰ SAML ਐਪ ਦੇ ਵਰਤੋਂਕਾਰ ਲਈ ਵਰਤੋਂਯੋਗ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਮੰਗ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੂਲ ਥ੍ਰੈਡ ਵਿੱਚ ਇੱਕ ਜਵਾਬ ਠੀਕ ਇਸੇ ਤਰ੍ਹਾਂ ਹੱਲ ਹੋਇਆ ਸੀ। ਇਸ ਨੂੰ ਬਾਹਰ ਰੱਖਣਾ ਸਭ ਤੋਂ ਸਸਤਾ ਅਤੇ ਅਖ਼ੀਰ ਵਿੱਚ ਲੱਭਣਾ ਸਭ ਤੋਂ ਖਿਝ ਭਰਿਆ ਹੈ।

ਸਾਫ਼ ਸੈਸ਼ਨ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ

ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਨਵੀਂ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਸਾਫ਼ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਨਾਲ ਟੈਸਟ ਕਰੋ। ਕੈਸ਼ ਕੀਤੇ ਦਾਅਵੇ ਅਤੇ ਮੁੜ ਵਰਤੇ ਸੈਸ਼ਨ ਲੁਕਾਉਂਦੇ ਹਨ ਕਿ ਸੁਧਾਰ ਹੋਇਆ ਜਾਂ ਨਹੀਂ।

ਫਿਰ ਦੋ ਰਿਕਾਰਡ ਨਾਲ-ਨਾਲ ਰੱਖ ਕੇ ਤੁਲਨਾ ਕਰੋ: ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਦੀ ਆਡਿਟ ਘਟਨਾ ਅਤੇ ਕਲਾਇੰਟ ਲੌਗ। ਟਨਲ ਤੋਂ ਬਿਨਾਂ ਸਫਲ ਸਾਈਨ-ਇਨ ਕਾਲਬੈਕ ਜਾਂ ਦਰਸ਼ਕਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਜੁੜਿਆ ਟਨਲ ਪਰ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਸਰੋਤ ਰੂਟਿੰਗ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਿਸੇ ਹੋਰ ਥਾਂ ਦੀ ਹੈ।

ਕੀ ਨਾ ਬਦਲੋ

ਸਫ਼ਾ ਲੰਘਣ ਲਈ ਪ੍ਰੋਫ਼ਾਈਲ ਤੋਂ auth-federate ਨਾ ਹਟਾਓ ਅਤੇ ਨਾ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਬੰਦ ਕਰੋ। ਦੋਵੇਂ ਅਸਫਲ ਕਾਲਬੈਕ ਦੀ ਥਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਡਿਜ਼ਾਈਨ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਆਮ ਤੌਰ ਉੱਤੇ ਅਗਲੇ ਕਲਾਇੰਟ ਅੱਪਡੇਟ ਵਿੱਚ ਟੁੱਟ ਜਾਂਦੇ ਹਨ।

ਇਸ ਦੀ ਥਾਂ ਹਸਤਾਂਤਰਣ ਠੀਕ ਕਰੋ, ਅਤੇ ਦਲਾਲ, ਦਰਸ਼ਕ ਅਤੇ loopback ਪੋਰਟ ਦਾ ਨਾਂ ਦੱਸਣ ਵਾਲੀ ਟਿੱਪਣੀ ਛੱਡੋ। ਸਫ਼ਾ ਵੇਖਣ ਵਾਲੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਤਿੰਨੇ ਚਾਹੀਦੇ ਹੋਣਗੇ।