ഒരു മാസം ഓഫ്‌ലൈനിന് ശേഷം ഡൊമെയ്ൻ ട്രസ്റ്റ് പരാജയപ്പെട്ടോ? ആദ്യം പരിശോധിക്കുക

ഒരു ലാപ്‌ടോപ്പ് ആറ് ആഴ്ച VPN-ന് പുറത്ത് നിൽക്കുന്നു, തിരികെ വരുന്നു, ഉപയോക്താവിന് ഡൊമെയ്ൻ അക്കൗണ്ട് ഉപയോഗിച്ച് ലോഗിൻ ചെയ്യാൻ കഴിയുന്നില്ല. പിശക് ട്രസ്റ്റ് ബന്ധത്തെ പരാമർശിക്കുന്നു, അതിനാൽ ആരോ കമ്പ്യൂട്ടർ അക്കൗണ്ട് പുനഃസജ്ജമാക്കുന്നു, അല്ലെങ്കിൽ ഉപയോക്താവിനെ പൂർണ്ണ ടണലിംഗിലേക്ക് നിർബന്ധിക്കുന്നു, പ്രശ്നം മാഞ്ഞുപോയതായി തോന്നുന്നു. രണ്ട് പ്രവർത്തനങ്ങളും എന്താണ് തകർന്നതെന്ന് തെളിയിച്ചില്ല. Windows അംഗത്തിന് സാധാരണ മെഷീൻ-പാസ്‌വേഡ് ഇടവേളയ്ക്ക് ഏറെ അപ്പുറവും ഓഫ്‌ലൈനിൽ തുടരാം, യാന്ത്രികമായി ട്രസ്റ്റ് നഷ്ടപ്പെടാതെ, അതിനാൽ ആദ്യ ജോലി എത്തിച്ചേരൽ പരാജയത്തെ യഥാർത്ഥ രഹസ്യ അസംഗതിയിൽ നിന്ന് വേർതിരിക്കുകയാണ്.

പിശക് ട്രസ്റ്റ് പോലെ തോന്നുന്നു, പക്ഷേ മൂന്ന് അവസ്ഥകൾ സമാനമാണ്

ഉപയോക്താവിന് കാഷ് ചെയ്ത ഡൊമെയ്ൻ വിവരങ്ങൾ ഉപയോഗിച്ച് സൈൻ ഇൻ ചെയ്യാം, വർക്ക്സ്റ്റേഷന് ഡൊമെയ്ൻ കൺട്രോളർ കണ്ടെത്താനാകില്ല, അല്ലെങ്കിൽ അംഗവും ഡൊമെയ്നും കമ്പ്യൂട്ടർ അക്കൗണ്ടിനെക്കുറിച്ച് യഥാർത്ഥത്തിൽ യോജിക്കുന്നില്ലായിരിക്കാം. കർശനമായ അർത്ഥത്തിൽ തകർന്ന ട്രസ്റ്റ് ബന്ധം മൂന്നാമത്തേത് മാത്രമാണ്.

AD റെപ്ലിക്കേഷൻ ആരോഗ്യം നാലാമത്തെ നിരീക്ഷണമാണ്, അത് ഈ വർക്ക്സ്റ്റേഷനുമായി യാതൊരു ബന്ധവുമില്ല. അത് ഡൊമെയ്ൻ കൺട്രോളർമാർ തമ്മിലുള്ള യോജിപ്പ് വിവരിക്കുന്നു, ആരോഗ്യകരമായ റെപ്ലിക്കേഷൻ ഡാഷ്ബോർഡ് ഈ മെഷീന്റെ പ്രാദേശിക രഹസ്യം അതിന്റെ കമ്പ്യൂട്ടർ അക്കൗണ്ടുമായി ഒത്തുപോകുന്നു എന്ന് തെളിയിക്കുന്നില്ല.

പരിചിതമായ 30 ദിവസത്തെ ഡിഫോൾട്ട് ഒരു മാറ്റ നയമാണ്, ഓഫ്‌ലൈൻ കാലഹരണപ്പെടൽ സമയപരിധിയല്ല. Microsoft-ന്റെ മെഷീൻ-അക്കൗണ്ട് പാസ്‌വേഡിനെക്കുറിച്ചുള്ള വിശദീകരണം ഏകോപിത മാറ്റ പ്രക്രിയ വിവരിക്കുന്നു, ഒരു സംഘടനയ്ക്ക് വ്യത്യസ്ത ഇടവേള ക്രമീകരിക്കാം.

VPN ഐക്കൺ സുരക്ഷിത ചാനലിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല

ഏതെങ്കിലും പരിശോധനയ്ക്ക് അർത്ഥമാകുന്നതിന് മുമ്പ് കണക്റ്റിവിറ്റി ഡൊമെയ്ൻ സേവനങ്ങളിൽ എത്താൻ മതിയായ നല്ലതായിരിക്കണം. അതായത് ഉദ്ദേശിച്ച ഡൊമെയ്ൻ DNS റിസോൾവർ, കണ്ടെത്താവുന്ന കൺട്രോളർ, എത്താവുന്ന പ്രാമാണീകരണ സേവനങ്ങൾ, Kerberos-ന് മതിയായ അടുത്തുള്ള ക്ലോക്ക്.

പൂർണ്ണ ടണലിംഗ് ഇവിടെ പൂർണ്ണമായി സാധുവായ രൂപകൽപ്പനയാകാം. വിഭജിത ടണലിംഗിലേക്ക് മാറുന്നത് ആരോഗ്യകരമായ ഡൊമെയ്ൻ ബന്ധത്തിന്റെ മുൻവ്യവസ്ഥയല്ല, അതിനെ അങ്ങനെ കണക്കാക്കുന്നത് രോഗനിർണ്ണയത്തെ വാസ്തുവിദ്യാ മാറ്റമാക്കി മാറ്റുന്നു. വർക്ക്സ്റ്റേഷൻ യഥാർത്ഥത്തിൽ ഏത് കൺട്രോളർ തിരഞ്ഞെടുക്കുന്നു എന്ന് പരിശോധിക്കുക, ആ പേര് പിശകിനൊപ്പം സൂക്ഷിക്കുക.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

DNS സെർവർ, പരിഹരിച്ച കൺട്രോളർ, പിശകിന്റെ കൃത്യമായ പാഠം എന്നിവ രേഖപ്പെടുത്തുക. കണക്റ്റുചെയ്തതായി റിപ്പോർട്ട് ചെയ്യുന്ന VPN ക്ലയന്റ് ടണൽ നിലവിലുണ്ടെന്ന് പറയുന്നു, ഡൊമെയ്ൻ പാത പ്രവർത്തിക്കുന്നു എന്നല്ല. Kerberos പോർട്ടിൽ ഉത്തരം നൽകുകയും ഡയറക്ടറി പോർട്ടിൽ നൽകാതിരിക്കുകയും ചെയ്യുന്ന കൺട്രോളർ ഫയർവാൾ കണ്ടെത്തലാണ്, ട്രസ്റ്റ് കണ്ടെത്തലല്ല.

നന്നാക്കുന്നതിന് മുമ്പ് അംഗം പരിശോധിക്കുക

അധികാരമുള്ള Windows ഡൊമെയ്ൻ അംഗത്തിൽ, Test-ComputerSecureChannel -Verbose മെഷീനും ഡൊമെയ്നും ഇടയിലുള്ള ചാനലിന്റെ വായന-മാത്ര പരിശോധനയാണ്. നിങ്ങൾ അന്വേഷിക്കുന്ന മെഷീന്റെ സന്ദർഭത്തിൽ അത് പ്രവർത്തിപ്പിക്കുക, ഡൊമെയ്ൻ കൺട്രോളറിൽ നിന്നല്ല, കാരണം അതിന് വ്യത്യസ്ത പങ്കും വ്യത്യസ്ത വീണ്ടെടുക്കൽ നിയമങ്ങളുമുണ്ട്. പാസ് അല്ലെങ്കിൽ ഫെയിൽ എന്ന വാക്കിന് പകരം ഔട്ട്പുട്ടും എക്സിറ്റ് നിലയും രേഖപ്പെടുത്തുക. ആ ബിൽഡിൽ cmdlet ഇല്ലെങ്കിൽ, മൊഡ്യൂൾ വേറിട്ട പ്രശ്നമാണ്.

ഫലത്തിന് ഇപ്പോഴും സന്ദർഭം വേണം. മെഷീനിന് തിരഞ്ഞെടുത്ത കൺട്രോളറിൽ എത്താനോ അവിടെ പ്രാമാണീകരിക്കാനോ കഴിയുന്നില്ലെങ്കിൽ, പരാജയപ്പെട്ട പരിശോധന ഓഫ്‌ലൈൻ പാസ്‌വേഡ് കാലഹരണപ്പെട്ടു എന്നതിന്റെ സ്വതന്ത്ര തെളിവല്ല. യഥാർത്ഥ പിശകും ഉപയോഗിച്ച കൺട്രോളറും സൂക്ഷിക്കുക, പാത അറിയപ്പെടുന്ന നല്ലതായാൽ പരിശോധന ആവർത്തിക്കുക.

സംഭവത്തിന് ചുറ്റും അംഗത്തിലും ബന്ധപ്പെട്ട കൺട്രോളറിലും Netlogon ഇവന്റുകൾ പരസ്പരം ബന്ധിപ്പിക്കുക. മെഷീന്റെ പേര്, ഉറവിട വിലാസം, സമയം, അക്കൗണ്ട് മാറ്റത്തിന്റെ ഏതെങ്കിലും തെളിവ് എന്നിവ സംരക്ഷിക്കുക. മറ്റൊരു ഉപയോക്താവിന്റെ വിജയകരമായ ലോഗിൻ, അല്ലെങ്കിൽ ആരോഗ്യകരമായ കൺട്രോളർ ഡാഷ്ബോർഡ്, ഈ മെഷീന്റെ കൈമാറ്റത്തിന് പകരമാകാൻ കഴിയില്ല.

നിങ്ങൾ തെളിയിച്ച ബന്ധം മാത്രം നന്നാക്കുക

കണക്റ്റിവിറ്റി സ്ഥിരമായതിനും നന്നാക്കൽ ഉചിതമാണെന്ന് അഡ്മിൻ സ്ഥിരീകരിച്ചതിനും ശേഷം, അധികാരമുള്ള ക്രെഡൻഷ്യലുകളുള്ള cmdlet-ന്റെ -Repair മോഡ് അംഗം വർക്ക്സ്റ്റേഷനുള്ള ഒരു പിന്തുണയ്ക്കുന്ന പ്രവർത്തനമാണ്. അത് ബന്ധം മാറ്റുന്നു, അത് മറ്റൊരു വായന-മാത്ര പരിശോധനയല്ല.

മാറ്റത്തിന് മുമ്പ് അംഗീകൃത പ്രാദേശിക വീണ്ടെടുക്കൽ അക്കൗണ്ടും മാനേജ്മെന്റ് പാതയും തയ്യാറാക്കുക. ഡൊമെയ്ൻ കൺട്രോളർമാർക്ക് വ്യത്യസ്ത വീണ്ടെടുക്കൽ പങ്കുണ്ട്, ഈ നടപടിക്രമം അവരെ സാധാരണ വർക്ക്സ്റ്റേഷനുകളായി കാണരുത്. ഒന്നിലധികം റീസെറ്റ് ടൂളുകൾ ക്രമത്തിൽ പ്രവർത്തിപ്പിച്ച് അവയിലൊന്ന് ശരിയാകുമെന്ന് പ്രതീക്ഷിക്കുന്നതിന് പകരം സംഘടനയുടെ വീണ്ടെടുക്കൽ പ്രവാഹം ഉപയോഗിക്കുക.

നന്നാക്കിയ ശേഷം പുതിയ സുരക്ഷിത-ചാനൽ പരിശോധനയും യഥാർത്ഥ ഡൊമെയ്ൻ പ്രവർത്തനവും സ്ഥിരീകരിക്കുക. ഉപയോക്തൃ പ്രൊഫൈലുകളും ആപ്ലിക്കേഷൻ നിലയും സംരക്ഷിക്കുക, നീക്കംചെയ്ത്-വീണ്ടും-ചേരൽ ആദ്യത്തെ വിശദീകരിക്കാത്ത പ്രവർത്തനമാക്കരുത്.

പരാജയം തിരികെ വരുമ്പോൾ എന്ത് പരിശോധിക്കണം

പരാജയം തിരികെ വന്നാൽ, അതേ അക്കൗണ്ട് വീണ്ടും പുനഃസജ്ജമാക്കുന്നതിന് പകരം റോൾബാക്ക്, ഇരട്ട ഐഡന്റിറ്റി, അക്കൗണ്ട് മാറ്റങ്ങളുടെ സമയം എന്നിവ നോക്കുക. പുനഃസ്ഥാപിച്ച ഇമേജ്, സ്നാപ്പ്ഷോട്ട്, ക്ലോൺ ചെയ്ത മെഷീൻ ഐഡന്റിറ്റി, അല്ലെങ്കിൽ മറ്റെവിടെ ചെയ്ത കമ്പ്യൂട്ടർ-അക്കൗണ്ട് റീസെറ്റ്—എല്ലാം അന്വേഷണത്തിന് അർഹമാണ്.

താൽക്കാലികമായി വിജയകരമായ റീസെറ്റ് ഉപയോഗപ്രദമായ വീണ്ടെടുക്കൽ തെളിവാണ്, പക്ഷേ ഇടയ്ക്കിടെ നിലയ്ക്കുന്ന VPN യഥാർത്ഥ അസംഗതിക്ക് കാരണമായി എന്നതിന്റെ തെളിവല്ല. കാരണം ഒരിക്കലും നീക്കം ചെയ്യപ്പെട്ടോ എന്ന് അടുത്ത സംഭവമാണ് പറയുന്നത്.

കൺട്രോളർ, DNS സെർവർ, പരിശോധനാ ഔട്ട്പുട്ട് എന്നിവ ടിക്കറ്റിൽ എഴുതുക. ആ രേഖയാണ് യഥാർത്ഥ ട്രസ്റ്റ് പരാജയത്തെ ഡൊമെയ്ൻ കണ്ടെത്താനാകാത്ത ലാപ്‌ടോപ്പിൽ നിന്ന് വേർതിരിക്കുന്നത്.