റിമോട്ട് ഡെസ്ക്ടോപ്പ് അവകാശങ്ങളില്ലാതെ 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-ന്റെ ലോഗോൺ അവകാശ റഫറൻസ് യന്ത്ര റോൾ അനുസരിച്ചുള്ള ഡിഫോൾട്ടുകളും നിഷേധം അനുമതിയെ തോൽപ്പിക്കുന്നു എന്ന നിയമവും പട്ടികപ്പെടുത്തുന്നു.