VPN-ൽ ഗ്രൂപ്പ് പോളിസി ഇല്ലേ? ടണലിന് മുമ്പ് പരിധി പരിശോധിക്കുക

ഓഫീസ് നെറ്റ്വർക്കിൽ ബാധകമായിരുന്ന ഒന്ന്, ഉപയോക്താവ് VPN വഴി ജോലി തുടങ്ങുന്ന ആഴ്ചയിൽ ബാധകമാകുന്നത് നിർത്തുന്നു, ആരും റിപ്പോർട്ട് തുറക്കുന്നതിന് മുമ്പ് ടണലിന് കുറ്റം ലഭിക്കുന്നു. ഏത് ക്രമീകരണങ്ങൾ Windows ഉപയോക്താവിനും കമ്പ്യൂട്ടറിനും എത്തുന്നു എന്ന് ഗ്രൂപ്പ് പോളിസി തീരുമാനിക്കുന്നു, ഡൊമെയ്നിൽ നിന്ന് വസ്തുക്കൾ എടുക്കുന്നു, ക്ലയന്റ് ഭാഗത്തുള്ള പ്രോസസ്സിംഗ് നടത്തുന്നു, ഈ മൂന്ന് ഘട്ടങ്ങൾ മൂന്ന് വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു. ടണൽ ക്ലയന്റിന് ഏത് വഴിയുണ്ടെന്ന് മാത്രം മാറ്റുന്നു. പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുന്നത് ഫയൽ അനുമതി പ്രശ്നത്തെ റൂട്ടിംഗ് പ്രശ്നമായി പിന്തുടരുന്നത് ഒഴിവാക്കുന്നു.

ടണലിൽ നിന്നല്ല, ക്രമീകരണത്തിൽ നിന്ന് തുടങ്ങുക

ഒരു പ്രതീക്ഷിത GPO-യും അതിനുള്ളിലെ ഒരു നിർദ്ദിഷ്ട ക്രമീകരണവും എഴുതുക, തുടർന്ന് ആ ക്രമീകരണം ഉപയോക്തൃ കോൺഫിഗറേഷനിലാണോ കമ്പ്യൂട്ടർ കോൺഫിഗറേഷനിലാണോ എന്ന് തീരുമാനിക്കുക. ഇത് അംഗീകൃത VPN-ൽ ഡൊമെയ്നിൽ ചേർന്ന അധികാരമുള്ള Windows ക്ലയന്റ് എന്ന് അനുമാനിക്കുന്നു, ഡൊമെയ്ൻ അംഗമാക്കുന്ന നിയന്ത്രിക്കപ്പെടാത്തതോ ക്ലൗഡ് മാത്രമുള്ളതോ ആയ ഉപകരണമല്ല. പരിധിയുടെ ഉത്തരം ഫലം ആർക്ക് വായിക്കാമെന്നും അധികാരം ഉയർത്തേണ്ടതുണ്ടോ എന്നും തീരുമാനിക്കുന്നു, അതിനാൽ എന്തെങ്കിലും പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് അത് തീർച്ചപ്പെടുത്തുക.

ഏത് ലിങ്ക്, ഒബ്ജക്റ്റ് സ്ഥാനം, സുരക്ഷാ ഫിൽട്ടറുകൾ, WMI ഫിൽട്ടറുകൾ എന്നിവ പ്രവർത്തനത്തിലുണ്ടാകണമെന്ന് ഡൊമെയ്ൻ അഡ്മിനിസ്ട്രേറ്ററോട് ചോദിക്കുക. പരീക്ഷണം വിജയിക്കാൻ ഈ നിയന്ത്രണങ്ങൾ മാറ്റുന്നത് വേറെ ഉടമയുള്ള വേറെ പദ്ധതിയാണ്.

ക്രമീകരണം ഉള്ള അക്കൗണ്ട് ഉപയോഗിച്ച് റിപ്പോർട്ട് വായിക്കുക

ബാധിക്കപ്പെട്ട ഉപയോക്താവിന്റെ സ്വന്തം സെഷനിൽ whoami /user ഉം തുടർന്ന് gpresult /scope user /r ഉം പ്രവർത്തിപ്പിക്കുക. VPN പ്രാമാണീകരിച്ച അക്കൗണ്ട് നിങ്ങൾ വായിക്കുന്ന നയത്തിന്റെ Windows അക്കൗണ്ട് സ്വയമേവയല്ല, അഡ്മിനിസ്ട്രേറ്റർ അക്കൗണ്ടിൽ നിന്നുള്ള പരിശോധന മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. അടിസ്ഥാന അവസ്ഥ പുതിയ ഫയൽനാമത്തിൽ സംരക്ഷിക്കുക, ഉദാഹരണത്തിന് %TEMP%\vpn-policy-user-before.html. gpresult റഫറൻസ് പരിധിയും ഔട്ട്പുട്ടും സ്വിച്ചുകൾ രേഖപ്പെടുത്തുന്നു, റിപ്പോർട്ട് സൃഷ്ടിക്കുന്നത് ഒന്നും പുതുക്കുന്നില്ല എന്ന് അറിയുന്നത് നല്ലതാണ്.

കമ്പ്യൂട്ടർ നയത്തിന് സ്വന്തം പരിധിയും അനുമതി സന്ദർഭവുമുണ്ട്, അതിനാൽ ആവശ്യമായ അധികാരം ഉയർത്തി അത് വെവ്വേറെ പരിശോധിക്കുക. രണ്ട് പരിധികളും ഒരു റിപ്പോർട്ടിൽ ചേർക്കുന്നതാണ് ഉപയോക്തൃ ക്രമീകരണം ഒരിക്കലും ആ പരിധിയിൽ ഇല്ലാതിരുന്നിട്ടും കാണാത്തതായി പ്രഖ്യാപിക്കുന്ന വഴി.

കണ്ടെത്തൽ പ്രവേശനമല്ല: ആദ്യം SRV റെക്കോർഡുകൾ, പിന്നെ SMB

അംഗീകൃത VPN ബന്ധിപ്പിച്ചിരിക്കുമ്പോൾ, ക്ലയന്റ് ഡൊമെയ്ൻ കൺട്രോളറുകളെ ഉദ്ദേശിച്ച DNS വഴിയിലൂടെ പരിഹരിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക; ലോഡ് ചെയ്യുന്ന പൊതു വെബ്സൈറ്റ് കൺട്രോളർ കണ്ടെത്തലിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഉദാഹരണ ഡൊമെയ്ൻ corp.example-ന് nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. തിരികെ നൽകിയ സേവന റെക്കോർഡ് കണ്ടെത്തലിന്റെ തെളിവ് മാത്രമാണ്, കാരണം തിരഞ്ഞെടുത്ത കൺട്രോളറുടെ വിലാസം ആവശ്യമായ പ്രാമാണീകരണത്തോടും അനുവദിച്ച ഡയറക്ടറി സേവനങ്ങളോടും കൂടി ഇപ്പോഴും എത്താവുന്നതായിരിക്കണം. നയ വസ്തുക്കൾ പിന്നീട് SYSVOL-ൽ നിന്ന് വരുന്നു, അത് അതേ കൺട്രോളറിനെതിരായ SMB വായനയാണ്, ICMP പരിശോധനയല്ല.

ദുർബലമായ തെളിവിനെ തെളിവായി തെറ്റിദ്ധരിക്കാൻ എളുപ്പമാണ്. ഒരു കൺട്രോളറിൽ നിന്നുള്ള ICMP മറുപടി, നയ ടെംപ്ലേറ്റിന്റെ നിരസിച്ച വായനയ്ക്കൊപ്പം, ആരും ഇതുവരെ ബന്ധിപ്പിക്കാത്ത ഒരു കാരണത്താൽ ശൂന്യമായി തോന്നുന്ന റിപ്പോർട്ട് സൃഷ്ടിക്കുന്നു.

വിന്യാസത്തിന്റെ AD സേവന അനുമതികൾ, തിരിച്ചുവരവ് വഴികൾ, സമയ സമന്വയം എന്നിവ സ്ഥിരതയോടെ സൂക്ഷിക്കുക, അവയെ സർവ്വവ്യാപിയായ ഫയർവാൾ തുറക്കലോ പൊതു DNS സെർവറോ ഉപയോഗിച്ച് മാറ്റുന്നതിന് പകരം. കൺട്രോളറുകൾക്കിടയിൽ വ്യത്യാസമുള്ള നയ ഡാറ്റ ഡയറക്ടറി ഉടമയ്ക്കുള്ള പകർപ്പ് ചോദ്യമാണ്.

ഒരു പുതുക്കൽ, രണ്ട് റിപ്പോർട്ടുകൾ, ഒരു താരതമ്യം

വഴി തെളിയിച്ചതിന് ശേഷം, ബന്ധപ്പെട്ട പുതുക്കൽ gpupdate /target:user ഉപയോഗിച്ച് അഭ്യർത്ഥിക്കുക, അനുമാനിക്കുന്നതിന് പകരം ഫലം വായിക്കുക. ഡിഫോൾട്ട് പുതുക്കൽ മാറ്റിയ നയം പ്രയോഗിക്കുന്നു, /force വീണ്ടും പ്രയോഗിക്കാൻ അഭ്യർത്ഥിക്കുന്നു; രണ്ടും DNS, ഫയൽ അനുമതികൾ, ഫിൽട്ടറിംഗ് എന്നിവ ശരിയാക്കുന്നില്ല. ചില വിപുലീകരണങ്ങൾ പിന്നീടുള്ള സൈൻ-ഇന്നിലോ മറ്റൊരു ഫോർഗ്രൗണ്ട് ഇവന്റിലോ മാത്രം പൂർത്തിയാകുന്നു, അതിനാൽ ഒരു പ്രവർത്തനം വിധിയല്ല. ദൂരെയുള്ള ഉപയോക്താവിന്റെ സെഷനിൽ ലോഗ്ഓഫ് അല്ലെങ്കിൽ റീസ്റ്റാർട്ട് സ്വിച്ചുകൾ സാധാരണ ഡയഗ്നോസ്റ്റിക്സായി ചേർക്കുന്നത് അവർ തുറന്നുവെച്ചത് വലിച്ചെറിയുന്നു.

മറ്റൊരു ഫയൽനാമത്തിൽ രണ്ടാമത്തെ റിപ്പോർട്ട് സൃഷ്ടിച്ച് പ്രോസസ്സിംഗ് സമയം, പ്രതീക്ഷിത GPO, അതിന്റെ പ്രയോഗിച്ച അല്ലെങ്കിൽ നിരസിച്ച നില, ക്രമീകരണം എന്നിവ താരതമ്യം ചെയ്യുക. മുൻ വിജയകരമായ സെഷനിലെ റിപ്പോർട്ട് ഈ പുതുക്കലിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ഫിൽട്ടർ ചെയ്ത് പുറത്തായ നയം കൈമാറ്റത്തെയല്ല, ബാധകതയെ സൂചിപ്പിക്കുന്നു, അത് അടുത്ത ഘട്ടം ആരുടേതെന്ന് മാറ്റുന്നു.

പരാജയം ഒരൊറ്റ പ്രവർത്തനത്തിൽ ബന്ധിപ്പിക്കുക

ഇവന്റ് വ്യൂവറിൽ സിസ്റ്റം ലോഗിലെ ഗ്രൂപ്പ് പോളിസി മുന്നറിയിപ്പിൽ നിന്നോ പിശകിൽ നിന്നോ തുടങ്ങുക, തുടർന്ന് ആപ്ലിക്കേഷനുകളുടെയും സേവനങ്ങളുടെയും ലോഗുകൾക്ക് കീഴിലുള്ള GroupPolicy പ്രവർത്തന ലോഗിലേക്ക് പോകുക. ആ പ്രവർത്തന ലോഗ് നിങ്ങൾ ഇപ്പോൾ പ്രവർത്തിപ്പിച്ച പുതുക്കലിന്റെ പ്രവർത്തന ഐഡന്റിഫയർ ഉപയോഗിച്ച് ഫിൽട്ടർ ചെയ്യുക, കാരണം പുതിയ പുതുക്കലിന് പുതിയ ഐഡന്റിഫയർ ലഭിക്കുന്നു, ഇന്നലത്തെ ഇവന്റുകളുമായി കലർത്തുന്നത് ആത്മവിശ്വാസമുള്ളതും തെറ്റായതുമായ നിഗമനം നൽകുന്നു. സമയം, ഉപയോക്താവ് അല്ലെങ്കിൽ കമ്പ്യൂട്ടർ സന്ദർഭം, തിരഞ്ഞെടുത്ത കൺട്രോളർ, GPO, പിശക് കോഡ്, പരാജയപ്പെട്ട ആശ്രിതത്വം എന്നിവ രേഖപ്പെടുത്തുക.

ആ രേഖയാണ് നെറ്റ്വർക്ക് അല്ലെങ്കിൽ ഡയറക്ടറി ഉടമയ്ക്ക് നടപടിയെടുക്കാനാകുന്നത്. VPN-ലേക്ക് ബന്ധിപ്പിച്ചിരിക്കുന്നതും gpupdate പലതവണ പ്രവർത്തിപ്പിച്ചതും തെളിവല്ല, രണ്ടും കൈമാറ്റത്തെ അതിജീവിക്കുന്നില്ല.

HTML റിപ്പോർട്ടുകൾ സ്വകാര്യമായി സൂക്ഷിക്കുക, കാരണം അവ ആന്തരിക നാമങ്ങൾ, ഗ്രൂപ്പ് അംഗത്വം, സുരക്ഷാ കോൺഫിഗറേഷൻ എന്നിവ വെളിപ്പെടുത്തുന്നു. ക്രമീകരണം സ്ഥിരീകരിച്ചതിന് ശേഷം, ചേർത്ത താൽക്കാലിക അനുമതികൾ അവിടെ വെക്കുന്നതിന് പകരം നീക്കം ചെയ്യുക.