ಬಳಕೆದಾರರೊಬ್ಬರು 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 ನ ಲಾಗ್ಆನ್ ಹಕ್ಕು ಉಲ್ಲೇಖ ಯಂತ್ರ ಪಾತ್ರದ ಪ್ರಕಾರ ಡೀಫಾಲ್ಟ್ಗಳನ್ನು ಮತ್ತು ನಿರಾಕರಣೆ ಅನುಮತಿಯನ್ನು ಸೋಲಿಸುತ್ತದೆ ಎಂಬ ನಿಯಮವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು