ਕੀ OpenConnect ਵਿੱਚ --key-password ਤੁਹਾਡਾ VPN ਖਾਤਾ ਪਾਸਵਰਡ ਹੈ?

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

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

ਦੋ ਭੇਦ, ਦੋ ਵੱਖਰੇ ਕੰਮ

ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਫਾਈਲ ਪਹੁੰਚ ਅਤੇ ਨੈੱਟਵਰਕ ਪ੍ਰਵੇਸ਼ ਵਜੋਂ ਪੜ੍ਹੋ। ਕੁੰਜੀ ਪਾਸਵਰਡ --sslkey ਵਿੱਚ ਦਿੱਤੀ PEM ਨਿੱਜੀ ਕੁੰਜੀ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ TLS ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕੀਤਾ ਜਾ ਸਕੇ। ਉਹ ਡੀਕ੍ਰਿਪਸ਼ਨ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ, ਕਲਾਇੰਟ ਪ੍ਰਕਿਰਿਆ ਦੇ ਅੰਦਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪਾਸਫਰੇਜ਼ ਆਪ ਕਦੇ ਵੀ ਗੇਟਵੇ ਤੱਕ ਨਹੀਂ ਜਾਂਦਾ। ਗੇਟਵੇ ਜੋ ਦੇਖਦਾ ਹੈ ਉਹ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਕੁੰਜੀ ਨਾਲ ਬਣਿਆ ਦਸਤਖ਼ਤ ਹੈ। OpenConnect ਦਾ ਮੈਨੂਅਲ --key-password ਨੂੰ --certificate ਅਤੇ --sslkey ਦੇ ਕੋਲ ਰੱਖਦਾ ਹੈ, ਅਤੇ TPM ਵਿੱਚ ਰੱਖੀ ਕੁੰਜੀ ਵਰਤ ਸਕਣ ਵਾਲੇ ਬਿਲਡਾਂ ਵਿੱਚ ਉਹੀ ਵਿਕਲਪ ਇਸ ਦੀ ਥਾਂ ਸਟੋਰੇਜ ਦੀ ਰੂਟ ਕੁੰਜੀ ਦਾ ਪਾਸਵਰਡ ਰੱਖਦਾ ਹੈ।

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

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

ਕੁੰਜੀ ਪਾਸਵਰਡ ਅਸਲ ਵਿੱਚ ਕਦੋਂ ਲੋੜੀਂਦਾ ਹੈ

ਵਿਕਲਪ ਦਾ ਅਰਥ ਸਿਰਫ਼ ਤਦ ਹੈ ਜਦੋਂ ਖੋਲ੍ਹਣ ਲਈ ਐਨਕ੍ਰਿਪਟਿਡ ਕੁੰਜੀ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਨਾਲ ਅਤੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਤੋਂ ਬਿਨਾਂ ਜੁੜਦੇ ਹੋ, ਤਾਂ --key-password ਕੋਲ ਕੰਮ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਜੇ ਤੁਸੀਂ --certificate ਅਤੇ --sslkey ਨਾਲ ਜੁੜਦੇ ਹੋ, ਤਾਂ ਪਾਸਫਰੇਜ਼ ਬਿਲਕੁਲ ਮੰਗਿਆ ਜਾਵੇਗਾ ਜਾਂ ਨਹੀਂ ਇਹ ਕੁੰਜੀ ਫਾਈਲ ਦਾ ਆਪਣਾ ਫਾਰਮੈਟ ਤੈਅ ਕਰਦਾ ਹੈ।

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

ਲਾਭਦਾਇਕ ਨਿਦਾਨ ਇਹ ਵੇਖਣਾ ਹੈ ਕਿ ਅਸਫਲਤਾ ਕਦੋਂ ਹੁੰਦੀ ਹੈ। ਜੇ ਕੋਈ ਨੈੱਟਵਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੁੰਜੀ ਫਾਈਲ, ਉਸ ਦਾ ਫਾਰਮੈਟ ਜਾਂ ਪਾਸਫਰੇਜ਼ ਉੱਤੇ ਸ਼ੱਕ ਕਰੋ। ਜੇ TLS ਸੈਸ਼ਨ ਸਥਾਪਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਗੇਟਵੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਕੁੰਜੀ ਨੇ ਆਪਣਾ ਕੰਮ ਕੀਤਾ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਖਾਤਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਵਿੱਚ ਹੈ।

ਦੋਵੇਂ ਭੇਦ ਸ਼ੈੱਲ ਇਤਿਹਾਸ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

ਕਮਾਂਡ-ਲਾਈਨ ਆਰਗਿਊਮੈਂਟ ਹੋਰ ਸਥਾਨਕ ਵਰਤੋਂਕਾਰਾਂ ਵੱਲੋਂ ਪ੍ਰਕਿਰਿਆ ਸਾਰਣੀ ਰਾਹੀਂ ਪੜ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਅਕਸਰ ਸ਼ੈੱਲ ਇਤਿਹਾਸ, ਸਕ੍ਰਿਪਟਾਂ ਅਤੇ ਸਹਾਇਤਾ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਕੈਦ ਹੋ ਜਾਂਦੇ ਹਨ। OpenConnect --passwd-on-stdin ਨਾਲ ਮਿਆਰੀ ਇਨਪੁਟ ਤੋਂ ਖਾਤਾ ਪਾਸਵਰਡ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੁੰਜੀ ਪਾਸਫਰੇਜ਼ ਆਰਗਿਊਮੈਂਟ ਦੀ ਥਾਂ ਇੰਟਰਐਕਟਿਵ ਪ੍ਰੋਂਪਟ ਜਾਂ ਏਜੰਟ ਤੋਂ ਆ ਸਕਦਾ ਹੈ। ਕੋਈ ਵੀ ਤਰੀਕਾ ਭੇਦ ਨੂੰ ਆਪਣੇ ਆਪ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਪਰ ਦੋਵੇਂ ਇਸਨੂੰ ਸਭ ਤੋਂ ਖੁੱਲ੍ਹੀਆਂ ਥਾਵਾਂ ਤੋਂ ਦੂਰ ਰੱਖਦੇ ਹਨ।

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

ਨਿਦਾਨ ਆਉਟਪੁਟ ਹੀ ਸ਼ਾਂਤ ਲੀਕ ਹੈ। ਵਧੇਰੇ ਵਿਸਥਾਰ ਉੱਤੇ ਕਲਾਇੰਟ ਲੌਗ ਬੇਨਤੀ ਦੇ ਮੁੱਖ ਹਿੱਸੇ ਜਾਂ ਵਿਕਲਪ ਮੁੱਲ ਦਿਖਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਨਕਲ ਕੀਤੀ ਟਰਮੀਨਲ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਟਿਕਟ ਵਿੱਚ ਪੇਸਟ ਕਰਨੀ ਸੌਖੀ ਹੈ, ਇਸ ਲਈ ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਉਟਪੁਟ ਪੜ੍ਹੋ।

ਮੁਰਦਾ ਡੈਸਕਟਾਪ ਬਟਨ ਇੱਕ ਹੋਰ ਖਰਾਬੀ ਹੈ

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

ਜਦੋਂ GUI ਜੁੜਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ ਤਾਂ ਸਰਟੀਫਿਕੇਟ ਪੜਤਾਲ ਢਿੱਲੀ ਕਰਨਾ ਜਾਂ ਜਾਂਚ ਬੰਦ ਕਰਨਾ ਲੁਭਾਉਣਾ ਲੱਗਦਾ ਹੈ। ਇਹ ਕਲਾਇੰਟ ਏਕੀਕਰਨ ਦੀ ਖਰਾਬੀ ਨੂੰ ਸੁਰੱਖਿਆ ਘਟਾਓ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਸਮੱਸਿਆ ਘੱਟ ਹੀ ਠੀਕ ਕਰਦਾ ਹੈ। ਸਰਵਰ ਪੜਤਾਲ ਨੂੰ ਅਟੁੱਟ ਰੱਖੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰੋਫਾਈਲ ਇੱਛਤ ਗੇਟਵੇ ਵੱਲ ਹੈ, ਅਤੇ ਜਾਂਚੋ ਕਿ GUI ਜਿਸ ਸਹਾਇਕ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਉਹ ਸੱਚਮੁੱਚ ਸਥਾਪਿਤ ਹੈ।

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