VPN വഴി SMB അതിഥി ലോഗിൻ: Windows ഇപ്പോഴും ഒരു ഐഡന്റിറ്റി ആവശ്യപ്പെടുന്നു
പ്രവർത്തിക്കുന്ന VPN ടണൽ അജ്ഞാത SMB ലോഗിൻ പ്രമാണീകരിച്ചതാക്കുന്നില്ല. ക്ലയന്റ് നയം വായിക്കുക, ഇവന്റ് 31017 സ്ഥിരീകരിക്കുക, തുടർന്ന് പേരുള്ള ഷെയർ അക്കൗണ്ട് ഉപയോഗിക്കുക.
ഓഫീസ് VPN-ലേക്ക് ചേരുമ്പോൾ ഫയൽ സെർവർ ലഭ്യമാകും, എന്നിട്ടും ഷെയർ പ്രവേശനം നിഷേധിക്കുന്നു, ഇത് ടണൽ തകർന്നു എന്ന നിഗമനത്തിലേക്ക് നയിക്കുന്നു. സാധാരണയായി അങ്ങനെയല്ല. SMB ഓരോ സെഷനും വെവ്വേറെ പ്രമാണീകരിക്കുന്നു, അജ്ഞാത ലോഗിൻ എന്ന നിലയിൽ എന്ത് സ്വീകരിക്കണം എന്നതിൽ Windows കൂടുതൽ കർശനമാകുന്നു. നെറ്റ്വർക്ക് പാതയും ഉപയോക്തൃ ഐഡന്റിറ്റിയും വ്യത്യസ്ത ആവശ്യകതകളാണ്, പിശക് രണ്ടാമത്തേതിനെക്കുറിച്ചാണ്.
ടണലിന് SMB ഐഡന്റിറ്റിയെ പകരാൻ കഴിയാത്തത് എന്തുകൊണ്ട്
ഒരു സെർവറുമായി സബ്നെറ്റ് പങ്കിടുന്നത് അതിന്റെ ഫയലുകൾ വായിക്കാനുള്ള അനുമതി എന്നർത്ഥമാക്കിയിട്ടില്ല; അത് റൂട്ടിംഗ് പ്രശ്നം മാത്രം ഒഴിവാക്കുന്നു. ക്ലയന്റ് സുരക്ഷിതമല്ലാത്ത അതിഥി ലോഗിൻ തടയുമ്പോൾ Windows ഇവന്റ് 31017 രേഖപ്പെടുത്തുന്നു, അത് സെർവറിലല്ല, നിങ്ങളുടെ യന്ത്രത്തിൽ എടുക്കുന്ന തീരുമാനമാണ്. ടണൽ SMB പാക്കറ്റുകൾ വിശ്വസ്തതയോടെ കൊണ്ടുപോകുന്നു, അതിഥി സെഷൻ നിരസിക്കപ്പെടുന്നു. സമാനമായ വീട്ടു നെറ്റ്വർക്കുകളിൽ ഒരു ലാപ്ടോപ്പ് പ്രവർത്തിക്കുകയും മറ്റൊന്ന് പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുന്നത് അതുകൊണ്ടാണ്.
ഇവന്റിനെ നെറ്റ്വർക്ക് തകരാറായല്ല, നയത്തിന്റെ തെളിവായി കാണുക. പരിഹാരം ഐഡന്റിറ്റിയിലോ ഉപകരണത്തിലോ ആണ്.
ക്ലയന്റ് നയവും നിരസിക്കൽ ഇവന്റും വായിക്കുക
രണ്ട് ഔട്ട്പുട്ടുകൾ ചോദ്യം വേഗത്തിൽ തീർക്കുന്നു: ഫലപ്രദമായ ക്ലയന്റ് കോൺഫിഗറേഷനും സമീപകാല നിരസിക്കൽ ഇവന്റുകളും.
Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017തെറ്റായ അതിഥി ക്രമീകരണവും ഒപ്പിടൽ ആവശ്യകതയും ചേർന്ന് കൂടുതൽ അന്വേഷണത്തിന് മുൻപ് തന്നെ പരാജയം വിശദീകരിക്കുന്നു. ക്ലയന്റാണ് സെഷൻ നിരസിച്ചതെന്ന് ഇവന്റ് ലോഗ് സ്ഥിരീകരിക്കുന്നു, സെർവർ ക്രെഡൻഷ്യൽ നിരസിച്ചു എന്നല്ല. മറ്റൊരു യന്ത്രത്തിലെ വിജയകരമായ ശ്രമത്തിൽ ഉപയോഗിച്ച ഷെയർ പാതയും അക്കൗണ്ടും എഴുതി വയ്ക്കുക, കാരണം കാഷ് ചെയ്ത സെഷൻ രണ്ട് പരിശോധനകളെ ഒരുപോലെ കാണിക്കാം, അവ ഒരുപോലെയല്ലെങ്കിലും. നിലവിലുള്ള കണക്ഷനുകൾ net use ഉപയോഗിച്ച് മായ്ക്കുക, തുടർന്ന് താരതമ്യം ചെയ്യുക, പഴയ സെഷൻ പുതിയതിനുവേണ്ടി ഉത്തരം നൽകാതിരിക്കാൻ.
പേരുള്ള അക്കൗണ്ട് ഉപയോഗിക്കുക, ഒപ്പിടൽ നിലനിർത്തുക
ദീർഘകാല പരിഹാരം സെർവറിന് അറിയാവുന്ന ഒരു അക്കൗണ്ട് വ്യക്തമായി നൽകുക എന്നതാണ്, ഒപ്പിടൽ, എൻക്രിപ്ഷൻ നയങ്ങൾ അതേപടി നിലനിർത്തി. ഡയലോഗിൽ ഏതോ പേര് ടൈപ്പ് ചെയ്യുന്നതിന് പകരം കണക്ഷനിൽ ക്രെഡൻഷ്യൽ നൽകുക.
net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnectionപേരുള്ള ലോഗിൻ സെർവറിന് ഓഡിറ്റ് ചെയ്യാവുന്ന ഒരു സെഷൻ സൃഷ്ടിക്കുന്നു, Get-SmbConnection ഡയലക്ടും ഒപ്പിടൽ സജീവമാണോ എന്നും കാണിക്കുന്നു. അതിഥി സെഷനുകൾക്ക് ഒപ്പിടൽ അല്ലെങ്കിൽ എൻക്രിപ്ഷൻ ആവശ്യകതകൾ നിറവേറ്റാൻ കഴിയില്ല, അതിനാൽ അതിഥി ഫ്ലാഗ് സജീവമാക്കുന്നത് അവ ആവശ്യപ്പെടുന്ന നയത്തെ രക്ഷിക്കില്ല. പഴയ ഉപകരണത്തിന് അക്കൗണ്ട് മാതൃകയില്ലെങ്കിൽ, അതിഥി പ്രവേശനത്തെ മാറ്റിസ്ഥാപിക്കൽ പദ്ധതിയോടെ വ്യക്തമായി രേഖപ്പെടുത്തിയ ഒഴിവാക്കലായി കാണുക. ഒരു ഉപകരണത്തിന് വേണ്ടി എല്ലാ കണക്ഷനുകളിലും ഒപ്പിടൽ ദുർബലമാക്കരുത്.
ഉപകരണത്തിന് അതിഥിയെ മാത്രം അറിയാവുന്നപ്പോൾ
ചില ഉപഭോക്തൃ NAS ബോക്സുകൾ അക്കൗണ്ട് എന്ന ആശയമില്ലാതെ ഷെയറുകൾ നൽകുന്നു, ഇത് രണ്ട് സത്യസന്ധമായ ഓപ്ഷനുകൾ അവശേഷിപ്പിക്കുന്നു: ഉപകരണം ഒറ്റപ്പെടുത്തുക അല്ലെങ്കിൽ മാറ്റിസ്ഥാപിക്കുക. സംവേദനക്ഷമമായ ഒന്നിലേക്കും റൂട്ടില്ലാത്ത ഒരു സെഗ്മെന്റിൽ ഇടുക, സൗകര്യാർത്ഥമുള്ള ഒരു ഒഴിവാക്കൽ മുഴുവൻ ക്ലയന്റിന്റെയും സ്ഥിരസ്ഥിതിയാകാൻ അനുവദിക്കരുത്. ബാക്കപ്പുകളോ ക്രെഡൻഷ്യലുകളോ ഉള്ള അതിഥി ഷെയർ Windows-ന്റെ ശല്യമല്ല, ഡാറ്റ വെളിപ്പെടുന്ന പ്രശ്നമാണ്. ഫേംവെയർ അപ്ഡേറ്റ് ഉപയോക്തൃ അക്കൗണ്ടുകൾ ചേർക്കുന്നുവെങ്കിൽ, അതാണ് വിലകുറഞ്ഞ ദീർഘകാല ഉത്തരം.
സ്വീകരിച്ച അക്കൗണ്ടും നയ മൂല്യങ്ങളും ടിക്കറ്റിൽ രേഖപ്പെടുത്തുക. അല്ലെങ്കിൽ അടുത്ത വ്യക്തി വീണ്ടും ടണൽ പരിശോധന നടത്തി അതേ നിരസിക്കലിൽ എത്തും.