ਰਿਮੋਟ ਡੈਸਕਟਾਪ ਅਧਿਕਾਰਾਂ ਤੋਂ ਬਿਨਾਂ VPN ਪਹੁੰਚ: ਚਾਰ ਵੱਖਰੇ ਦਰਵਾਜ਼ੇ
ਰੱਦ ਕੀਤਾ RDP ਸੈਸ਼ਨ Windows ਲੌਗਆਨ ਅਧਿਕਾਰ ਹੈ, VPN ਖਰਾਬੀ ਨਹੀਂ। ਪ੍ਰਭਾਵੀ ਨੀਤੀ ਪੜ੍ਹੋ, ਸੰਜੀਵ ਸਮੂਹ ਦਿਓ ਅਤੇ ਨੈੱਟਵਰਕ ਮਾਰਗ ਵੱਖਰਾ ਰੱਖੋ।
ਇੱਕ ਵਰਤੋਂਕਾਰ VPN ਨਾਲ ਜੁੜਦਾ ਹੈ, ਫ਼ਾਈਲ ਸ਼ੇਅਰ ਅਤੇ ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਫਿਰ RDP ਕੋਸ਼ਿਸ਼ «ਵਰਤੋਂਕਾਰ ਖਾਤਾ ਦੂਰਸਥ ਲੌਗਇਨ ਲਈ ਅਧਿਕ੍ਰਿਤ ਨਹੀਂ ਹੈ» ਵਾਪਸ ਕਰਦੀ ਹੈ। ਉਸ ਸੁਨੇਹੇ ਵਿੱਚ ਟਨਲ ਬਾਰੇ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ। VPN ਖਾਤੇ ਅਤੇ ਇੰਟਰੈਕਟਿਵ ਡੈਸਕਟਾਪ ਵਿਚਕਾਰ ਚਾਰ ਸੁਤੰਤਰ ਦਰਵਾਜ਼ੇ ਹਨ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਆਖਰੀ ਨੇ ਪੈਦਾ ਕੀਤਾ। ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਖਾਤੇ ਨੂੰ Administrators ਵਿੱਚ ਜੋੜ ਕੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਜੋ ਡੈਸਕਟਾਪ ਤੋਂ ਬਹੁਤ ਵੱਧ ਦਿੰਦਾ ਹੈ ਅਤੇ ਜੇ ਸਮੂਹ ਨੀਤੀ ਮਨ੍ਹਾ ਕਰਦੀ ਹੈ ਤਾਂ ਦਰਵਾਜ਼ਾ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। ਇੱਥੇ ਹੈ ਕਿ ਹਰ ਦਰਵਾਜ਼ਾ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਮਨ੍ਹਾ ਕਰਨ ਵਾਲੇ ਦਰਵਾਜ਼ੇ ਨੂੰ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ।
ਚਾਰ ਦਰਵਾਜ਼ੇ ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ
ਗੇਟਵੇ ਪਹਿਲਾਂ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਪਛਾਣ ਟਨਲ ਬਣਾ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ: RADIUS ਨੀਤੀ, ਸਮੂਹ ਸ਼ਰਤ, ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ, Access Server ਇਜਾਜ਼ਤ। ਫਿਰ ਰੂਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਟਨਲ ਪੂਲ ਤੋਂ ਆਇਆ ਪੈਕੇਟ ਮੰਜ਼ਿਲ ਦੇ TCP 3389 ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਫਿਰ ਕਲਾਇੰਟ ਦਾ NLA ਹੈਂਡਸ਼ੇਕ ਮੰਜ਼ਿਲ ਸਾਹਮਣੇ ਖਾਤੇ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਤੋਂ ਬਾਅਦ ਹੀ ਸਥਾਨਕ ਸੁਰੱਖਿਆ ਅਥਾਰਟੀ ਜਾਂਚਦੀ ਹੈ ਕਿ ਖਾਤੇ ਕੋਲ ਇੰਟਰੈਕਟਿਵ ਦੂਰਸਥ ਸੈਸ਼ਨ ਲਈ ਲੋੜੀਂਦਾ ਲੌਗਆਨ ਅਧਿਕਾਰ ਹੈ ਜਾਂ ਨਹੀਂ।
ਕ੍ਰਮ ਨਿਸ਼ਚਿਤ ਹੋਣ ਕਰਕੇ, ਹਰ ਦਰਵਾਜ਼ਾ ਆਪਣੇ ਪਿੱਛੇ ਦੇ ਦਰਵਾਜ਼ੇ ਲੁਕਾਉਂਦਾ ਹੈ। ਅਸਫਲ ਟਨਲ ਰੂਟਿੰਗ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ; ਰੁਕਿਆ ਪੋਰਟ ਲੌਗਆਨ ਅਧਿਕਾਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ; ਸਫਲ ਪੋਰਟ ਟੈਸਟ ਪ੍ਰਵੇਸ਼ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਇਸ ਲਈ «VPN ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ RDP ਨਹੀਂ» ਇੱਕ ਸਮੱਸਿਆ ਨਹੀਂ ਸਗੋਂ ਇਨ੍ਹਾਂ ਦਰਵਾਜ਼ਿਆਂ ਵਿੱਚੋਂ ਦੋ ਵਿਚਕਾਰ ਸੀਮਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਗਲਤੀ ਦਾ ਟੈਕਸਟ ਤੁਸੀਂ ਕਿਸ ਦਰਵਾਜ਼ੇ 'ਤੇ ਟਕਰਾਏ ਇਹ ਜਾਣਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।
ਉਹ ਅਧਿਕਾਰ ਜੋ ਅਸਲ ਵਿੱਚ ਸੈਸ਼ਨ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ
ਰਿਮੋਟ ਡੈਸਕਟਾਪ ਵਿੱਚ ਸਾਈਨ-ਇਨ ਕਰਨ ਲਈ ਵਰਤੋਂਕਾਰ ਅਧਿਕਾਰ ਰਿਮੋਟ ਡੈਸਕਟਾਪ ਸੇਵਾਵਾਂ ਰਾਹੀਂ ਲੌਗਆਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਭਾਵ SeRemoteInteractiveLogonRight ਲੋੜੀਂਦਾ ਹੈ। ਇਹ ਲੌਗਆਨ ਸਮੇਂ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ, ਟਨਲ ਸਥਾਪਨਾ ਸਮੇਂ ਨਹੀਂ, ਇਸ ਲਈ ਖਾਤਾ ਘੰਟਿਆਂ ਤੱਕ ਨੈੱਟਵਰਕ ਵਿੱਚ ਘੁੰਮ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਡੈਸਕਟਾਪ ਤੋਂ ਵਾਂਝਾ ਰਹਿ ਸਕਦਾ ਹੈ। ਇਹ ਦਿਖਾਉਣ ਵਾਲਾ ਸੰਵਾਦ ਸਥਾਨਕ ਨੀਤੀਆਂ, ਵਰਤੋਂਕਾਰ ਅਧਿਕਾਰ ਨਿਯੁਕਤੀ ਅਧੀਨ ਹੈ, ਅਤੇ ਡੋਮੇਨ ਬਰਾਬਰ GPO ਵਿੱਚ ਹੈ।
ਡਿਫ਼ਾਲਟ ਮੈਂਬਰਸ਼ਿਪ ਮਸ਼ੀਨ ਦੀ ਭੂਮਿਕਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ: ਵਰਕਸਟੇਸ਼ਨ ਅਤੇ ਮੈਂਬਰ ਸਰਵਰ ਇਹ Administrators ਅਤੇ Remote Desktop Users ਨੂੰ ਦਿੰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਡੋਮੇਨ ਕੰਟਰੋਲਰ ਸਿਰਫ਼ Administrators ਨੂੰ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਤੱਥ ਬਹੁਤੀ ਉਲਝਣ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹੀ ਖਾਤਾ ਫ਼ਾਈਲ ਸਰਵਰ 'ਤੇ ਸਫਲ ਹੁੰਦਾ ਹੈ ਅਤੇ DC 'ਤੇ ਅਸਫਲ। ਇਨਕਾਰ ਅਧਿਕਾਰ ਸਮੂਹ ਮੈਂਬਰਸ਼ਿਪ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਸੰਬੰਧਿਤ ਇਜਾਜ਼ਤ ਅਧਿਕਾਰ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਜਿਸ ਖਾਤੇ ਨੂੰ ਇਜਾਜ਼ਤ ਅਤੇ ਇਨਕਾਰ ਦੋਵੇਂ ਹਨ ਉਹ ਰੱਦ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਵਿਆਪਕ ਇਨਕਾਰ ਸਮੂਹ ਉਪਕਾਰ ਵਜੋਂ ਜੋੜੇ ਗਏ ਪ੍ਰਬੰਧਕ ਨੂੰ ਵੀ ਫੜ ਸਕਦਾ ਹੈ।
ਪ੍ਰਭਾਵੀ ਨੀਤੀ ਪੜ੍ਹੋ, ਸਥਾਨਕ ਸੰਵਾਦ ਨਹੀਂ
ਸਥਾਨਕ ਨੀਤੀ ਨੂੰ ਉਹੀ ਅਧਿਕਾਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਾਲੀ ਕੋਈ ਵੀ ਡੋਮੇਨ GPO ਲਿਖਤੀ ਤੌਰ 'ਤੇ ਬਦਲ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਸਥਾਨਕ ਸਨੈਪ-ਇਨ ਸਹੀ ਦਿਖਣ ਵਾਲੀ ਸੂਚੀ ਦਿਖਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪ੍ਰਭਾਵੀ ਸਥਿਤੀ ਵੱਖਰੀ ਹੈ। ਮਸ਼ੀਨ ਅਸਲ ਵਿੱਚ ਕੀ ਲਾਗੂ ਕਰਦੀ ਹੈ ਨਿਰਯਾਤ ਕਰੋ, ਫਿਰ ਅਧਿਕਾਰ ਲੱਭੋ ਅਤੇ ਦਿਖਾਏ ਨਾਵਾਂ ਦੀ ਥਾਂ SID ਪੜ੍ਹੋ:
secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v
ਉਸ ਆਉਟਪੁੱਟ ਵਿੱਚ *S-1-5-32-544 ਮਤਲਬ Administrators ਅਤੇ *S-1-5-32-555 ਮਤਲਬ Remote Desktop Users।
ਜੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ ਦਿਸਦਾ, ਤਾਂ ਸਥਾਨਕ ਵਰਤੋਂਕਾਰ ਅਤੇ ਸਮੂਹ ਸੰਵਾਦ ਕੁਝ ਵੀ ਸੁਝਾਵੇ, ਨੀਤੀ ਧਾਰਕ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਡੈਸਕਟਾਪ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ। ਫਿਰ gpresult ਜਿੱਤਣ ਵਾਲੀ GPO ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਵਸਤੂ ਤੁਹਾਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨੀ ਹੈ; ਡੋਮੇਨ-ਜੁੜੀ ਮਸ਼ੀਨ 'ਤੇ ਸਥਾਨਕ ਨੀਤੀ ਬਦਲਣਾ ਪਰਖ ਹੈ, ਹੱਲ ਨਹੀਂ।
ਜੋ ਸਭ ਤੋਂ ਸੰਜੀਵ ਅਧਿਕਾਰ ਫਿੱਟ ਹੋਵੇ ਦਿਓ
ਆਮ ਜਵਾਬ ਮੰਜ਼ਿਲ 'ਤੇ Remote Desktop Users ਸਮੂਹ ਹੈ। ਇਹ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਅਧਿਕਾਰ ਰੱਖਦਾ ਹੈ, Administrators ਨਾਲੋਂ ਬਹੁਤ ਛੋਟਾ ਹੈ, ਅਤੇ «ਡੈਸਕਟਾਪ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ» ਨੂੰ «ਸਰਵਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਸਕਦਾ ਹੈ» ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਜਿੱਥੇ ਨੀਤੀ ਨੇ ਅਧਿਕਾਰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਮੁੜ ਵੰਡਿਆ ਹੈ, ਉੱਥੇ ਕਿਸੇ ਨੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਵਜੋਂ ਨਾ ਸੋਚੇ ਸਮੂਹ ਨੂੰ ਜੋੜਨ ਦੀ ਥਾਂ ਉਹ ਸਮੂਹ ਜਾਂ ਖਾਤਾ ਉਸ ਨੀਤੀ ਵਿੱਚ ਜੋੜੋ।
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"
ਕੁਝ ਵੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨਕਾਰ ਸੂਚੀ ਜਾਂਚੋ। ਜੇ ਇਨਕਾਰ ਅਧਿਕਾਰ ਉਸ ਸਮੂਹ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਹੈ, ਤਾਂ ਸਹੀ ਬਦਲਾਅ ਖਾਤੇ ਨੂੰ ਉਸ ਸਮੂਹ ਤੋਂ ਹਟਾਉਣਾ ਜਾਂ ਇਨਕਾਰ ਨੂੰ ਸੰਜੀਵ ਕਰਨਾ ਹੈ, ਕਿਤੇ ਹੋਰ ਦੂਜੀ ਇਜਾਜ਼ਤ ਜੋੜਨਾ ਨਹੀਂ। ਤੁਸੀਂ ਕਿਹੜਾ ਅਧਿਕਾਰ ਅਤੇ ਕਿੱਥੇ ਬਦਲਿਆ ਲਿਖੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਾਲਾ GPO ਰਿਫ਼੍ਰੈਸ਼ ਪਿਛਲੀ ਸਥਿਤੀ ਚੁੱਪਚਾਪ ਬਹਾਲ ਕਰੇਗਾ ਅਤੇ ਟਿਕਟ ਉਸੇ ਸੁਨੇਹੇ ਨਾਲ ਦੁਬਾਰਾ ਖੁੱਲ੍ਹੇਗੀ।
ਨੈੱਟਵਰਕ ਮਾਰਗ ਨੂੰ ਵੱਖਰਾ ਫ਼ੈਸਲਾ ਰੱਖੋ
VPN ਸਮੂਹ ਨੂੰ ਹਰ ਪੋਰਟ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਜਦੋਂ ਸਮੂਹ ਨੂੰ ਡੈਸਕਟਾਪ ਨਹੀਂ ਸਗੋਂ ਐਪਲੀਕੇਸ਼ਨ ਚਾਹੀਦੀ ਹੈ, ਟਨਲ ਪੂਲ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪੋਰਟ ਤੱਕ ਸੀਮਿਤ ਫਾਇਰਵਾਲ ਨਿਯਮ ਉਸ ਨੀਤੀ ਨੂੰ ਪ੍ਰਭਾਵ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਲੌਗਆਨ ਅਧਿਕਾਰ ਅਛੂਤ ਰਹਿੰਦਾ ਹੈ।
Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389
OpenVPN ਦਾ ਆਪਣਾ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਅਤੇ Access Server ਸਮੂਹ ਇਜਾਜ਼ਤਾਂ ਉਸੇ ਭਾਵਨਾ ਵਿੱਚ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫ਼ਿਕਸ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹਨ; ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ Windows ਲੌਗਆਨ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ ਲੌਗਆਨ ਅਧਿਕਾਰ ਪੋਰਟ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ। ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੀਆਂ ਬਦਲਾਅ ਵਿੰਡੋਜ਼ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਪੋਰਟ ਨਿਯਮ ਅਤੇ ਅਧਿਕਾਰ ਵੱਖਰੇ ਲੋਕ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹਨ।
ਦਰਵਾਜ਼ੇ ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਤਸਦੀਕ ਕਰੋ: ਖਾਤਾ ਟਨਲ ਸਥਾਪਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਸੈਸ਼ਨ ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਕਲਾਇੰਟ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਖਾਤੇ ਕੋਲ ਅਧਿਕਾਰ ਹੈ। ਪੋਰਟ ਟੈਸਟ ਸਫਲ ਹੋਣ ਸਮੇਂ ਅਸਫਲ ping ICMP ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਹੈ, RDP ਰੁਕਿਆ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ। Microsoft ਦਾ ਲੌਗਆਨ ਅਧਿਕਾਰ ਸੰਦਰਭ ਮਸ਼ੀਨ ਭੂਮਿਕਾ ਅਨੁਸਾਰ ਡਿਫ਼ਾਲਟ ਅਤੇ ਇਨਕਾਰ ਇਜਾਜ਼ਤ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ ਨਿਯਮ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ।