VPN ਸਰਟੀਫਿਕੇਟ LDAP ਹਿੱਸੇ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ
ਇੱਕ ਐਨਕ੍ਰਿਪਟਿਡ ਕਲਾਇੰਟ ਸੈਸ਼ਨ ਗੇਟਵੇ ਦੇ LDAP ਕਨੈਕਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। StartTLS ਜਾਂ LDAPS ਚੁਣੋ ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਟ੍ਰਸਟ ਸਟੋਰ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰੋ।
ਡਾਇਰੈਕਟਰੀ ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਾਂਚਣ ਵਾਲਾ VPN ਲੌਗਇਨ ਦੋ ਵੱਖਰੇ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਦਾ ਗੇਟਵੇ ਨਾਲ ਕਨੈਕਸ਼ਨ VPN ਦੇ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੁਆਰਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਗੇਟਵੇ ਦਾ ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਕਨੈਕਸ਼ਨ ਆਪਣੀਆਂ TLS ਸੈਟਿੰਗਾਂ, ਆਪਣਾ ਟ੍ਰਸਟ ਸਟੋਰ ਅਤੇ ਆਪਣੇ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਢੰਗਾਂ ਵਾਲਾ ਦੂਜਾ ਸੈਸ਼ਨ ਹੈ। ਪਹਿਲੇ ਬਾਰੇ ਕੁਝ ਵੀ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਵੀ ਭਰੋਸਾ ਨਹੀਂ ਦਿੰਦਾ।
ਇਹੀ ਅਸਮਾਨਤਾ ਐਨਕ੍ਰਿਪਟਿਡ ਦਿਸਣ ਵਾਲੇ ਅਤੇ ਫਿਰ ਵੀ bind ਪਾਸਵਰਡ ਖੁੱਲ੍ਹਾ ਭੇਜਣ ਵਾਲੇ ਲੌਗਇਨ ਪਿੱਛੇ ਦੀ ਕਿਰਿਆਵਿਧੀ ਹੈ।
ਦੋ ਕਨੈਕਸ਼ਨ, ਦੋ ਭਰੋਸੇ ਦੇ ਫੈਸਲੇ
ਬਾਹਰੀ ਸੈਸ਼ਨ ਉਹ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰ ਦੇਖਦਾ ਹੈ: VPN ਹੋਸਟਨਾਮ ਨਾਲ ਬੱਝਿਆ ਸਰਟੀਫਿਕੇਟ, ਕਲਾਇੰਟ ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਤ, ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਢੋਣ ਵਾਲਾ। ਅੰਦਰੂਨੀ ਸੈਸ਼ਨ ਗੇਟਵੇ ਦੇ ਅੰਦਰਲੇ ਡਾਇਰੈਕਟਰੀ ਕਲਾਇੰਟ ਦਾ ਹੈ, ਜੋ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ TLS ’ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਹਰ ਪਾਸਾ ਆਪਣੇ ਸਾਹਮਣੇ ਵਾਲੇ ਨੂੰ ਦੂਜੀ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਦੀ ਸਮੱਗਰੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ। ਗਲਤ ਕੌਂਫਿਗਰ ਕੀਤਾ ਅੰਦਰੂਨੀ ਹਿੱਸਾ ਵਰਤੋਂਕਾਰ ਦੇ ਪਾਸਿਓਂ ਅਦਿੱਖ ਰਹਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਬਾਹਰੀ ਹਿੱਸਾ ਠੀਕ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਇਰਾਦਾ ਸੀ।
ਇਸੇ ਲਈ ਫੇਲ੍ਹ ਹੋਣਾ ਉੱਚੀ ਨਹੀਂ, ਖਾਮੋਸ਼ ਹੁੰਦਾ ਹੈ। ਜੋ ਗੇਟਵੇ ਕਦੇ ਡਾਇਰੈਕਟਰੀ ਦਾ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਜਾਂਚਦਾ, ਉਹ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਫਿਰ ਵੀ ਸਹੀ ਢੰਗ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ; ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਸ ਚੈਨਲ ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਜਿਸ ਦੀ ਉਸਨੇ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ।
StartTLS ਅਤੇ LDAPS, ਸੋਝੀ ਨਾਲ ਚੁਣੇ
StartTLS ਸਾਧਾਰਨ LDAP ਵਜੋਂ ਖੁੱਲ੍ਹਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਹੀ ਉੱਨਤ ਹੁੰਦਾ ਹੈ, ਆਮ ਤੌਰ ’ਤੇ ਪੋਰਟ 389 ’ਤੇ। LDAPS ਕਨੈਕਸ਼ਨ ਨਾਲ ਹੀ TLS ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਆਮ ਤੌਰ ’ਤੇ 636 ’ਤੇ। ਦੋਵੇਂ ਜਾਇਜ਼ ਹਨ ਅਤੇ ਅਡੈਪਟਰ ਨੂੰ ਡਾਇਰੈਕਟਰੀ ਵੱਲੋਂ ਦਿੱਤੇ ਜਾਣ ਵਾਲੇ ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। StartTLS ਦੀ ਮੰਗ ਕਰਨਾ ਇਸਨੂੰ ਅਜ਼ਮਾ ਕੇ ਉੱਨਤੀ ਫੇਲ੍ਹ ਹੋਣ ’ਤੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਵੱਖਰਾ ਹੈ, ਅਤੇ ਠੀਕ ਉਸੇ ਫ਼ਰਕ ਵਿੱਚ bind ਪਾਸਵਰਡ ਬਾਹਰ ਨਿਕਲ ਸਕਦਾ ਹੈ। ਸਖ਼ਤ ਮੋਡ ਕੌਂਫਿਗਰ ਕਰੋ, ਅਤੇ ਪਾਸਵਰਡ bind ਲਈ ਅਸੁਰੱਖਿਅਤ ਵਿਕਲਪੀ ਰਾਹ ਦੀ ਆਗਿਆ ਨਾ ਦਿਓ।
ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn
-ZZ ਵਿਕਲਪ ਹੀ ਪੂਰੀ ਗੱਲ ਹੈ: ਕਿਊਰੀ ਉੱਨਤੀ ਤੋਂ ਬਿਨਾਂ ਚੁੱਪਚਾਪ ਅੱਗੇ ਵਧਣ ਦੀ ਬਜਾਏ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਉਸ ਲਾਈਨ ਦੇ ਨਾਮ ਅਤੇ ਖਾਤੇ ਉਦਾਹਰਨ ਹਨ। OpenLDAP TLS ਦਸਤਾਵੇਜ਼ ਇਸਦੇ ਪਿੱਛੇ ਦੀਆਂ ਟ੍ਰਸਟ ਸੈਟਿੰਗਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।
LDAP ਕਲਾਇੰਟ ਕਿਹੜਾ ਟ੍ਰਸਟ ਸਟੋਰ ਪੜ੍ਹਦਾ ਹੈ?
OpenLDAP ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਆਪਣੀ ਟ੍ਰਸਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪੜ੍ਹਦੀ ਹੈ, ਭਾਵੇਂ ਸਿਸਟਮ ਫਾਈਲ ਤੋਂ ਹੋਵੇ ਜਾਂ ਪਲੱਗਇਨ-ਵਿਸ਼ੇਸ਼ ਸੈਟਿੰਗ ਤੋਂ। VPN ਦਾ CA ਨਿਰਦੇਸ਼ VPN ਸਾਥੀਆਂ ’ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ LDAP ਲਾਇਬ੍ਰੇਰੀ ਉਹੀ ਫਾਈਲ ਪੜ੍ਹਦੀ ਹੈ। ਉਹ ਡਾਇਰੈਕਟਰੀ ਹੋਸਟਨਾਮ ਵਰਤੋ ਜੋ ਸਰਟੀਫਿਕੇਟ ਅਸਲ ਵਿੱਚ ਕਵਰ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਉਹ ਜਾਰੀਕਰਤਾ ਚੇਨ ਜਿਸ ’ਤੇ ਲਾਇਬ੍ਰੇਰੀ ਭਰੋਸਾ ਕਰਦੀ ਹੈ। Active Directory ਵਿੱਚ, ਡਿਸਪਲੇ ਨਾਮ ਤੋਂ ਅਨੁਮਾਨ ਲਾਉਣ ਦੀ ਬਜਾਏ ਸਹੀ ਸਰਵਰ-ਪ੍ਰਮਾਣੀਕਰਨ ਵਰਤੋਂ ਨਾਲ ਡਾਇਰੈਕਟਰੀ-ਸੇਵਾ ਸਰਟੀਫਿਕੇਟ ਤੈਨਾਤ ਕਰੋ।
ਹਰ ਫੇਲਓਵਰ ਮੰਜ਼ਿਲ ਨੂੰ ਉਹੀ ਪਛਾਣ ਨੀਤੀ ਪੂਰੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜਿਸ ਵਾਤਾਵਰਨ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਪ੍ਰਮਾਣਿਤ ਹੈ ਅਤੇ ਸੈਕੰਡਰੀ ਨਹੀਂ, ਉਹ ਫੇਲਓਵਰ ਤੋਂ ਬਿਨਾਂ ਨਾਲੋਂ ਬੁਰਾ ਹੈ, ਕਿਉਂਕਿ ਕਮਜ਼ੋਰ ਰਾਹ ਸਿਰਫ਼ ਰੁਕਾਵਟ ਦੌਰਾਨ ਹੀ ਪਤਾ ਲੱਗਦਾ ਹੈ।
bind ਖਾਤਾ ਵੱਖਰੀ ਸਮੱਸਿਆ ਰਹਿੰਦਾ ਹੈ
ਟ੍ਰਾਂਸਪੋਰਟ ਦੀ ਸੁਰੱਖਿਆ bind ਖਾਤਾ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਨੂੰ ਘਟਾਉਂਦੀ ਨਹੀਂ। ਡਾਇਰੈਕਟਰੀ ਖੋਜ ਦਾਇਰਾ, ਸਮੂਹ ਅਧਿਕਾਰ ਅਤੇ ਸੇਵਾ ਖਾਤੇ ਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵੱਖਰੇ ਫੈਸਲੇ ਹਨ, ਅਤੇ TLS ਸਮਰੱਥ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਚੌੜਾ bind ਖਾਤਾ ਚੌੜਾ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਸਭ ਤੋਂ ਤੰਗ ਸੇਵਾ ਖਾਤਾ ਅਤੇ ਖੋਜ ਅਧਾਰ ਵਰਤੋ ਜੋ ਏਕੀਕਰਨ ਨੂੰ ਲੋੜੀਂਦੇ ਹਨ, ਅਤੇ ਐਂਡਪੌਇੰਟ, TLS ਮੋਡ, ਟ੍ਰਸਟ ਦਾ ਮਾਲਕ ਅਤੇ ਨਵੀਨੀਕਰਨ ਪ੍ਰਕਿਰਿਆ VPN ਕੌਂਫਿਗਰੇਸ਼ਨ ਨਾਲ ਰਿਕਾਰਡ ਕਰੋ।
ਜਦੋਂ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਬੇਮੇਲ ਦਿਸੇ, ਤਾਂ ਸਹੀ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਚੇਨ ਤੈਨਾਤ ਕਰੋ। ਪ੍ਰਮਾਣਿਕਤਾ ਬੰਦ ਕਰਨਾ ਦਿਸਣ ਵਾਲੀ ਬੇਮੇਲ ਨੂੰ ਅਦਿੱਖ ਬਣਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਭਰੋਸੇ ਦੇ ਸੰਬੰਧ ਨੂੰ ਬਿਨਾਂ ਪਰਖ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਦੋ ਕਨੈਕਸ਼ਨ, ਦੋ ਮਾਲਕ, ਦੋ ਨਵੀਨੀਕਰਨ ਤਾਰੀਖਾਂ। ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਹੀ ਲੌਗਇਨ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦਾ ਹੈ।