LmCompatibilityLevel ഒരു Windows നയമാണ്, VPN പരിഹാരമല്ല

ഒരാൾക്ക് VPN വഴി ഫയൽ പങ്കിടലിൽ എത്താനാകുന്നില്ല, LmCompatibilityLevel കുറയ്ക്കുന്നത് NTLM പ്രശ്നങ്ങൾ പരിഹരിക്കുമെന്ന് വായിക്കുന്നു, പങ്കിട്ട സെർവറിൽ അത് മാറ്റുന്നു. അടുത്ത ദിവസം രാവിലെ മറ്റ് അപ്ലിക്കേഷനുകൾ പരാജയപ്പെടുന്നു, യഥാർത്ഥ പ്രശ്നം അതേപടി നിലനിൽക്കുന്നു. ഈ ക്രമീകരണം ഒരിക്കലും ടണലിന് പ്രത്യേക സ്വിച്ച് ആയിരുന്നില്ല; ഈ സിസ്റ്റം ഏത് പ്രാമാണീകരണ പ്രതികരണങ്ങൾ അയയ്ക്കും സ്വീകരിക്കും എന്നതിനെക്കുറിച്ചുള്ള യന്ത്രതല പ്രഖ്യാപനമാണ് ഇത്. ഒരു ലോഗിൻ ശരിയാക്കാൻ ഇത് മാറ്റുന്നത് യന്ത്രം നടത്തുന്ന ഓരോ ലോഗിനിന്റെയും നിയമങ്ങൾ വീണ്ടും എഴുതുന്നു.

രേഖപ്പെടുത്തിയ നിലകൾ വായിക്കുന്നതാണ് ഒരു നയ മൂല്യത്തെ മാന്ത്രിക സംഖ്യയായി കാണുന്നത് നിർത്താനുള്ള വേഗമേറിയ വഴി.

മൂന്ന് നിലകൾ, മൂന്ന് വ്യത്യസ്ത വാഗ്ദാനങ്ങൾ

നില 1 ക്ലയന്റിനെ LM, NTLM പ്രതികരണങ്ങൾ അയയ്ക്കാൻ നിർബന്ധിക്കുന്നു, ചർച്ച അനുവദിക്കുമ്പോൾ NTLMv2 സെഷൻ സുരക്ഷ ഉപയോഗിക്കുന്നു. നില 3 ക്ലയന്റിനെ NTLMv2 പ്രതികരണങ്ങൾ മാത്രം അയയ്ക്കാൻ നിർബന്ധിക്കുന്നു, ഇത് സ്വീകരിക്കുന്ന വശത്ത് എല്ലാ പഴയ പ്രതികരണങ്ങളും നിരസിക്കുന്നതിന് തുല്യമല്ല. നില 5 ക്ലയന്റിനെ NTLMv2 ൽ നിർത്തി, ഡൊമെയിൻ കൺട്രോളറുടെ രേഖപ്പെടുത്തിയ LM, NTLMv1 നിരസിക്കൽ കൂട്ടിച്ചേർക്കുന്നു. മൂന്ന് സംഖ്യകൾ, അവയ്ക്കിടയിലുള്ള വ്യത്യാസം മുൻഗണനയല്ല, നയ തീരുമാനമാണ്.

ആ വ്യത്യാസങ്ങളാണ് പ്രവർത്തിക്കുന്ന സാഹചര്യത്തിൽ നിന്ന് മൂല്യം പകർത്തുന്നത് എന്തിന് വിശ്വസനീയമല്ല എന്ന് വിശദീകരിക്കുന്നത്. തെറ്റായി ക്രമീകരിച്ച ക്ലയന്റിനെ 1 ൽ നിന്ന് അംഗീകൃത അടിസ്ഥാനരേഖയിലേക്ക് മാറ്റുന്നത് ശരിയായിരിക്കാം. ഒരു ഫോറം ത്രെഡ് 3 പരാമർശിച്ചതിന് മാത്രം കടുപ്പമുള്ള വിന്യാസം 5 ൽ നിന്ന് 3 ലേക്ക് താഴ്ത്തുന്നത് ആരോ ബോധപൂർവ്വം തിരഞ്ഞെടുത്ത അതിർത്തി അയച്ചുവിടുന്നു, യന്ത്രം സംസാരിക്കുന്ന ഓരോ സേവനത്തിനും അത് ചെയ്യുന്നു.

പ്രാബല്യത്തിലുള്ള നയം വായിക്കുക, ഒരു രജിസ്ട്രി മൂല്യമല്ല

പ്രാദേശിക മൂല്യത്തിലേക്കുള്ള വായന-മാത്ര കാഴ്ച ന്യായമായ തുടക്കമാണ്: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. മൂല്യം ഇല്ലാതിരിക്കുന്നത് പ്രാബല്യത്തിലുള്ള നയം പൂജ്യമാണ് എന്നർത്ഥമാക്കുന്നില്ല, കാരണം ഡൊമെയിൻ അല്ലെങ്കിൽ പ്രാദേശിക സുരക്ഷാ നയത്തിന് അത് മറ്റൊരിടത്ത് സജ്ജമാക്കാം, യന്ത്രത്തിന്റെ പങ്ക് ആ സംഖ്യയുമായി അത് എന്ത് ചെയ്യുന്നു എന്ന് മാറ്റുന്നു.

എന്തെങ്കിലും തീരുമാനിക്കുന്നതിന് മുമ്പ് നിർവ്വഹിത നയം, സിസ്റ്റത്തിന്റെ പങ്ക്, യഥാർത്ഥ build എന്നിവ പരിശോധിക്കുക. ഒരേ മൂല്യമുള്ള വർക്ക്സ്റ്റേഷനും ഡൊമെയിൻ കൺട്രോളറും മുകൾഭാഗത്ത് വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു, രണ്ട് യന്ത്രങ്ങളെ താരതമ്യം ചെയ്യുമ്പോൾ ആളുകൾ മറക്കുന്നത് ആ ഭാഗമാണ്.

യഥാർത്ഥത്തിൽ ഏത് പ്രാമാണീകരണമാണ് പരാജയപ്പെട്ടതെന്ന് കണ്ടെത്തുക

Kerberos ടിക്കറ്റ് പ്രശ്നങ്ങൾ, NTLM നിരസിക്കലുകൾ, VPN പ്രവേശന പരാജയങ്ങൾ എന്നിവയ്ക്ക് വ്യത്യസ്ത തെളിവുകൾ വേണം. ലക്ഷ്യ സേവനം, അക്കൗണ്ട്, കൃത്യമായ പിശക് എന്നിവ ഒരൊറ്റ കുറിപ്പിൽ ഒരുമിച്ച് സൂക്ഷിക്കുക, തുടർന്ന് ക്ലയന്റ് എന്താണ് ഇഷ്ടപ്പെടുന്നത് എന്നതല്ല, സേവനം എന്താണ് ആവശ്യപ്പെട്ടത് എന്ന് നോക്കുക. ആ ഒരു കുറിപ്പ് ഏറ്റവും സാധാരണ തെറ്റായ തിരിവിനെ തടയുന്നു, അതായത് സെർവർ വശത്തെ നിരസിക്കലിന് മറുപടിയായി ക്ലയന്റ് വശത്തെ മൂല്യം മാറ്റുന്നത്.

പൊതുവായ ലോഗിൻ പിശക് അപ്രത്യക്ഷമാകുന്നതുവരെ നയം ആവർത്തിച്ച് താഴ്ത്തുന്നത് രോഗനിർണ്ണയമല്ല; അത് തെളിവ് മറയ്ക്കുന്ന മാറ്റമാണ്. അപ്ലിക്കേഷൻ Kerberos ഉപയോഗിക്കുന്നുവെങ്കിൽ, NTLM അനുയോജ്യതാ നില പ്രസക്തമായ നിയന്ത്രണവുമല്ല, നിങ്ങൾ അതിർത്തി വെറുതെ അയച്ചുവിട്ടു.

ചില പ്രോട്ടോക്കോൾ പിന്തുണ വീണ്ടെടുക്കാനാവില്ല

Windows 11 24H2, Windows Server 2025 എന്നിവയിൽ ഇനി NTLMv1 നെറ്റ്വർക്ക് പ്രാമാണീകരണം അടങ്ങിയിട്ടില്ല. build ഇനി നടപ്പിലാക്കാത്ത ഒരു പ്രോട്ടോക്കോളിനെ ഒരു അനുയോജ്യതാ സംഖ്യയും തിരികെ കൊണ്ടുവരില്ല, അതിനാൽ പഴയ പതിപ്പിൽ സഹായിച്ച ഡൗൺഗ്രേഡ് പുതിയതിൽ വെറുതെ പരാജയപ്പെടും. Microsoft ആ നീക്കം നയ ക്രമീകരണത്തിൽ നിന്ന് വേർതിരിച്ച് രേഖപ്പെടുത്തുന്നു, രണ്ടും കൂട്ടിക്കലർത്തുന്നത് പ്രവർത്തിക്കാനാവാത്ത ഉപദേശം ഉണ്ടാക്കുന്നു.

ബന്ധപ്പെട്ടതെങ്കിലും വ്യത്യസ്തമായ ഒരു പരിമിതി MSCHAPv2 അധിഷ്ഠിത ഏക സൈൻ-ഓൺ ഉപയോഗിക്കുന്ന NTLMv1 ൽ നിന്ന് ഉരുത്തിരിഞ്ഞ ക്രെഡൻഷ്യലുകൾക്ക് ബാധകമാണ്. ഇത് ഉരുത്തിരിഞ്ഞ ക്രെഡൻഷ്യലുകളുടെ ചോദ്യമാണ്, നെറ്റ്വർക്ക് പ്രോട്ടോക്കോളിന്റെതല്ല, ഈ ഒരു രജിസ്ട്രി മൂല്യത്തിന്റെതുമല്ല. മൂന്നിനെയും ഒരേ വിഷയമായി കാണുന്നതാണ് സ്ഥാപനങ്ങൾ ഒരു നിയന്ത്രണം ദുർബലമാക്കി മറ്റൊന്ന് ശരിയാക്കാൻ ശ്രമിക്കുമ്പോൾ എത്തുന്ന വഴി.

ഉടമയിലൂടെ അത് മാറ്റുക, തുടർന്ന് രണ്ട് ദിശകളും പരിശോധിക്കുക

തിരുത്തൽ യഥാർത്ഥത്തിൽ ആവശ്യമാണെങ്കിൽ, അടിസ്ഥാനരേഖ സുസ്ഥിരമായിരിക്കാൻ നയ ഉടമയിലൂടെ ചെയ്യുക, എന്തുകൊണ്ടെന്ന് രേഖപ്പെടുത്തുക. തുടർന്ന് പുതിയ ക്രമീകരണത്തിൽ അനുവദനീയമായ ഒരു അപ്ലിക്കേഷനും ബോധപൂർവ്വം വിലക്കിയ പ്രാമാണീകരണ കേസും പരിശോധിക്കുക, കാരണം ഒരു പങ്കിടൽ ശരിയാക്കി മറ്റൊരിടത്ത് പഴയ പ്രതികരണങ്ങൾ നിശ്ശബ്ദമായി അനുവദിക്കുന്ന മാറ്റം വിജയമല്ല. പ്രവർത്തിക്കുന്ന VPN കണക്ഷൻ പ്രവേശനം വിജയിച്ചുവെന്ന് തെളിയിക്കുന്നു. അത് യന്ത്രത്തിന്റെ പ്രാമാണീകരണ നയം സാധൂകരിക്കുന്നില്ല, അതിന് പിന്നിലുള്ള ഓരോ സേവനവും ഇപ്പോഴും രൂപകൽപ്പന ചെയ്തതുപോലെ പ്രവർത്തിക്കുന്നു എന്ന് ഉറപ്പായും കാണിക്കുന്നില്ല.

പരാജയപ്പെടുന്ന സേവനം Kerberos അധിഷ്ഠിതമാണെങ്കിൽ, ഈ ക്രമീകരണം നോക്കുന്നത് പൂർണ്ണമായി നിർത്തുക. അത് യഥാർത്ഥത്തിൽ കൂടുതൽ നന്നായി ചെയ്യാനാവാത്ത പഴയ ഉപകരണമാണെങ്കിൽ, ആ ഒഴിവാക്കൽ രേഖപ്പെടുത്തി അതിന്റെ പരിധി നിർണ്ണയിക്കുക, കാരണം ബദൽ ആരും അംഗീകരിച്ചതായി ഓർക്കാത്ത നിശ്ശബ്ദമായി ദുർബലമാക്കിയ അടിസ്ഥാനരേഖയാണ്.