നിങ്ങളുടെ Mac RDP വഴി തെറ്റായ Windows അക്കൗണ്ട് അയക്കുന്നു
ആരോഗ്യകരമായ ടണലും നിരസിക്കപ്പെട്ട ഡെസ്ക്ടോപ്പ് ലോഗിനും വെവ്വേറെ പാളികളാണ്. കീചെയ്നിൽ നിന്ന് എന്തെങ്കിലും ഇല്ലാതാക്കുന്നതിന് മുൻപ് ആ റിമോട്ട് പിസിക്കായി സൂക്ഷിച്ച അക്കൗണ്ട് പരിശോധിക്കുക.
ടണൽ വീണ്ടും കണക്ട് ചെയ്യുന്നു, Mac വീണ്ടും ഓഫീസ് നെറ്റ്വർക്കിൽ എത്തുന്നു, എന്നിട്ടും Remote Desktop ലോഗിൻ പരാജയത്തോടെയാണ് മറുപടി നൽകുന്നത്. ആ പിശക് VPN ന്റേതല്ല. ടണൽ Mac-നെ അംഗീകൃത നെറ്റ്വർക്കിലേക്ക് എത്തിക്കുന്നു; റിമോട്ട് കമ്പ്യൂട്ടറിലേക്ക് സൈൻ ഇൻ ചെയ്യുന്നത് Windows അക്കൗണ്ടാണ്, ഒപ്പം കണക്ഷൻ എൻട്രി മാസങ്ങൾക്ക് മുൻപ് ഉപയോഗിക്കുന്നത് നിർത്തിയ അക്കൗണ്ട് അയച്ചുകൊണ്ടിരിക്കാം.
കീചെയ്ൻ തൊടുന്നതിന് മുൻപ് എൻട്രി പരിശോധിക്കുക.
VPN അക്കൗണ്ടും Windows അക്കൗണ്ടും വ്യത്യസ്ത കാര്യങ്ങളാണ്
VPN ഐഡന്റിറ്റി ടണലിന്റെ ഗേറ്റ്വേയിൽ ഉപകരണത്തെയോ വ്യക്തിയെയോ പ്രാമാണീകരിക്കുന്നു. ഏത് Windows അക്കൗണ്ട് റിമോട്ട് ഹോസ്റ്റ് സ്വീകരിക്കുമെന്ന് അത് പറയുന്നില്ല, അതിന് പകരമാകാനും കഴിയില്ല. ടണൽ ആരോഗ്യകരവും ഡെസ്ക്ടോപ്പ് ലോഗിൻ നിരസിക്കുന്നതുമാകുമ്പോൾ, പ്രശ്നം ഇതിനകം നെറ്റ്വർക്ക് പാളി കടന്നിരിക്കുന്നു. രണ്ട് പ്രാമാണീകരണങ്ങളെയും വെവ്വേറെ ലോഗുകളുള്ള വെവ്വേറെ സംഭവങ്ങളായി കാണുക. ഗേറ്റ്വേ ശുദ്ധമായ സെഷൻ കാണിക്കുമ്പോൾ Windows സെക്യൂരിറ്റി ലോഗ് തികച്ചും വ്യത്യസ്ത കാരണത്താൽ ലോഗിൻ പരാജയം രേഖപ്പെടുത്തിയേക്കാം.
അഡ്മിൻസ്ട്രേറ്റർ EXAMPLE\alex ഉപയോഗിക്കാൻ പറഞ്ഞു, സൂക്ഷിച്ച എൻട്രി ഇപ്പോഴും വെറും alex തിരഞ്ഞെടുക്കുന്നു എന്ന് കരുതുക. ഇവ വ്യത്യസ്ത അക്കൗണ്ടുകളാണ്. യോഗ്യതയില്ലാത്ത പേര് റിമോട്ട് കമ്പ്യൂട്ടറിന്റെ ലോക്കൽ അക്കൗണ്ടുകൾക്കെതിരെ പരിഹരിക്കപ്പെടുന്നു, ഡൊമെയ്നിൽ ചേർത്ത മെഷീനിൽ അത് ഡൊമെയ്ൻ ഐഡന്റിറ്റിയിലേക്ക് പരിഹരിക്കപ്പെടണമെന്നില്ല.
അതിനാൽ ഡൊമെയ്ൻ പ്രിഫിക്സ് നീക്കം ചെയ്യുന്നത് പൊതുവായ അറ്റകുറ്റപ്പണിയല്ല. ഏത് അക്കൗണ്ട് ആവശ്യപ്പെടുന്നു എന്ന് അത് മാറ്റുന്നു, പാസ്വേഡ് ഒരിക്കലും പ്രശ്നമല്ലാതിരുന്നപ്പോൾ പാസ്വേഡ് പ്രശ്നം പോലെ തോന്നുന്ന നിരസിക്കൽ അത് ഉണ്ടാക്കിയേക്കാം.
കണക്ഷൻ എൻട്രി തുറക്കുക, മുഴുവൻ കീചെയ്നല്ല
macOS-നുള്ള നിലവിലെ Windows App-ൽ, ഉപകരണങ്ങൾ വിഭാഗത്തിൽ റിമോട്ട് പിസി കണ്ടെത്തി, അതിന്റെ എഡിറ്റ് പ്രവർത്തനം തുറന്ന് ആ പ്രത്യേക എൻട്രിയോട് ബന്ധിപ്പിച്ച അക്കൗണ്ട് നോക്കുക. മറ്റൊരു സൂക്ഷിച്ച അക്കൗണ്ട് തിരഞ്ഞെടുക്കാനോ കാലഹരണപ്പെട്ടത് നീക്കാനോ അനുവദിക്കുന്ന സേവ് ചെയ്ത ക്രെഡൻഷ്യൽ നിയന്ത്രണങ്ങൾ അപ്ലിക്കേഷൻ നൽകുന്നു. തിരഞ്ഞെടുപ്പ് ശരിയാക്കാനുള്ള പിന്തുണയുള്ള സ്ഥലം ഇതാണ്. ഒരു സമയത്ത് ഒരു സവിശേഷത മാറ്റുക, ഏത് മാറ്റമാണ് യഥാർത്ഥത്തിൽ പ്രധാനമായതെന്ന് അറിയാൻ. ക്രെഡൻഷ്യൽ മാറ്റവും ഹോസ്റ്റ്നെയിം മാറ്റവും ഒരുമിച്ച് ചെയ്താൽ ആർക്കും ആരോപിക്കാനാകാത്ത ഫലം ലഭിക്കും.
പേരിൽ സെർവർ നാമമുള്ള എല്ലാ കീചെയ്ൻ ഇനങ്ങളും ഇല്ലാതാക്കി തുടങ്ങരുത്. കീചെയ്ൻ ഇനങ്ങൾ അപ്ലിക്കേഷനുകൾക്കിടയിൽ പങ്കിടപ്പെടുന്നു, വിശാലമായ ഇല്ലാതാക്കൽ Windows വശത്ത് ഒന്നും മാറ്റാതെ ബന്ധമില്ലാത്ത ആക്സസ് നീക്കം ചെയ്തേക്കാം. യഥാർത്ഥ പ്രശ്നം ഹോസ്റ്റ്നെയിം, റൂട്ട് അല്ലെങ്കിൽ RDP സേവനമാണെന്ന് തെളിഞ്ഞാൽ ആവശ്യമാകുന്ന തെളിവുകളും അത് നശിപ്പിക്കുന്നു.
ഒരു സൂക്ഷിച്ച ക്രെഡൻഷ്യൽ പല റിമോട്ട് പിസികൾ ഉപയോഗിക്കുന്നുവെങ്കിൽ, നീക്കം ചെയ്യുന്നതിന് മുൻപ് ആ ആശ്രിതത്വങ്ങൾ പരിശോധിക്കുക. ഒരു പിസിയുടെ എൻട്രി എഡിറ്റ് ചെയ്യുന്നത് പഴയപടിയാക്കാം; പങ്കിട്ട ക്രെഡൻഷ്യൽ ഇല്ലാതാക്കുന്നത് വിശാലമായ സ്വാധീനവും മോശം ഓഡിറ്റ് ട്രെയിലുമുള്ള മാറ്റമാണ്.
അഡ്മിൻസ്ട്രേറ്റർ നൽകിയ അക്കൗണ്ട് രൂപം ഉപയോഗിക്കുക
അക്കൗണ്ട് നൽകിയത് എങ്ങനെയോ അതേപടി, പരിസ്ഥിതി പ്രതീക്ഷിക്കുന്ന രൂപത്തിൽ ടൈപ്പ് ചെയ്യുക: NetBIOS ശൈലിയിലുള്ള ഡൊമെയ്നിന് DOMAIN\user, അല്ലെങ്കിൽ ഡയറക്ടറി user principal name ഉപയോഗിക്കുന്നുവെങ്കിൽ അത്. തുടർന്ന് ഇത് ഈ പിസിക്കായി സൂക്ഷിച്ച് ഒരു ബോധപൂർവമായ കണക്ഷൻ ശ്രമം നടത്തുക.
സൈൻ-ഇൻ പ്രോംപ്റ്റ് ഏത് അക്കൗണ്ട് കാണിക്കുന്നു എന്ന് ശ്രദ്ധിക്കുക. ഇതിനകം മറ്റൊരു പേരുള്ള പ്രോംപ്റ്റ് എന്നാൽ സൂക്ഷിച്ച തിരഞ്ഞെടുപ്പ് മാറ്റിയിട്ടില്ല, ഇപ്പോൾ നടത്തിയ ശ്രമം വീണ്ടും പഴയ ക്രെഡൻഷ്യൽ പരിശോധിച്ചു.
പാസ്വേഡ് കുറിപ്പുകൾ, ടിക്കറ്റുകൾ, സ്ക്രീൻഷോട്ടുകൾ എന്നിവയിൽ നിന്ന് അകറ്റി നിർത്തുക. പകരം അക്കൗണ്ട് പേരും കൃത്യമായ പിശക് കോഡും രേഖപ്പെടുത്തുക, കാരണം കോഡ് മോശം ക്രെഡൻഷ്യലിനെ നയപരമായ നിരസിക്കൽ, കാലഹരണപ്പെട്ട പാസ്വേഡ്, അല്ലെങ്കിൽ RDP സ്വീകരിക്കാത്ത മെഷീൻ എന്നിവയിൽ നിന്ന് വേർതിരിക്കുന്നു.
സൈൻ-ഇന്നിന് മുൻപുള്ള പരാജയപ്പെട്ട കണക്ഷൻ വേറെ തകരാറാണ്
ഏതെങ്കിലും Windows ലോഗിൻ പ്രത്യക്ഷപ്പെടുന്നതിന് മുൻപ് വ്യൂവർ പരാജയപ്പെട്ടാൽ, ക്രെഡൻഷ്യലുകളല്ല സംശയിക്കേണ്ടത്. ഹോസ്റ്റ്നെയിം പരിഹരിക്കപ്പെടുന്നുണ്ടോ, ടണലിലൂടെ ഹോസ്റ്റിലേക്കുള്ള റൂട്ട് ഉണ്ടോ, RDP സേവനം കേൾക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. ഒരിക്കലും സ്ഥാപിക്കാത്ത TCP കണക്ഷൻ ഒരിക്കലും അക്കൗണ്ട് പാളിയിൽ എത്തുന്നില്ല.
നേരെമറിച്ച്, വ്യക്തമായ അക്കൗണ്ട് നിരസിക്കൽ DNS തകർന്നു എന്നോ സർട്ടിഫിക്കറ്റ് സാധൂകരണം അയച്ചുവിടണമെന്നോ ഉള്ള തെളിവല്ല. അത്തരം മാറ്റങ്ങൾ കണക്ഷൻ ദുർബലമാക്കുകയും സാധാരണയായി നിരസിക്കൽ ഉണ്ടായിരുന്നിടത്ത് തന്നെ വിടുകയും ചെയ്യുന്നു.
കഴിയുന്നത്ര ചെറിയ ഘട്ടങ്ങളിൽ പരീക്ഷിക്കുക: പോർട്ട് എത്താനാകുമെന്ന് ഉറപ്പാക്കുക, സൈൻ-ഇൻ പ്രോംപ്റ്റ് പ്രത്യക്ഷപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, കാണിക്കുന്ന അക്കൗണ്ട് നിങ്ങൾ ഉദ്ദേശിച്ചതാണെന്ന് ഉറപ്പാക്കുക, തുടർന്ന് പാസ്വേഡ് നൽകുക. ഓരോ ഘട്ടത്തിനും വെവ്വേറെ പരാജയവും വെവ്വേറെ പരിഹാരവുമുണ്ട്.
സ്വയമേവയുള്ള വീണ്ടും കണക്ഷൻ അതേപടി വിടുക
സ്വയമേവയുള്ള വീണ്ടും കണക്ഷൻ നിലവിലുള്ള എൻട്രി, അതിന്റെ സൂക്ഷിച്ച അക്കൗണ്ട് ഉൾപ്പെടെ, വീണ്ടും ഉപയോഗിക്കുന്നു. ഇത് സൗകര്യമാണ്, ക്രെഡൻഷ്യൽ അറ്റകുറ്റപ്പണിയല്ല, അതിനാൽ ഇത് ഓഫ് ചെയ്യുന്നത് തെറ്റായ തിരഞ്ഞെടുപ്പ് ശരിയാക്കുന്നില്ല, ഓൺ ചെയ്യുന്നത് ഒന്ന് സൃഷ്ടിക്കുന്നുമില്ല. എൻട്രിയിൽ ഇപ്പോൾ ശരിയായ അക്കൗണ്ട് ഉണ്ടെങ്കിൽ, വീണ്ടും കണക്ഷൻ അത് ഉപയോഗിക്കും.
തിരുത്തിയ എൻട്രി സൂക്ഷിക്കുക, ഒരിക്കൽ കൈകൊണ്ട് കണക്ട് ചെയ്യുക, ഏത് അക്കൗണ്ട് പ്രവർത്തിച്ചു എന്ന് കുറിക്കുക. ആ ഒരു വരി മാത്രമാണ് അടുത്തയാളുടെ രോഗനിർണയത്തെ ഒരു ഉച്ചയിലെ കീചെയ്ൻ പുരാവസ്തുശാസ്ത്രത്തിന് പകരം അഞ്ച് മിനിറ്റാക്കുന്നത്.