RDP ക്ലയന്റിനെ മാറ്റുന്നു: ഡാറ്റാബേസ് എന്തുകൊണ്ട് മറ്റൊരു ഹോസ്റ്റ് കാണുന്നു

നിങ്ങളുടെ VPN നിയമം ഡാറ്റാബേസ് നിരസിക്കുന്നു, ടിക്കറ്റ് ഫയർവാൾ തകരാറായി അടയ്ക്കുന്നു, അതേസമയം അതേ ഉപയോക്താവ് ഒരു പ്രസിദ്ധീകരിച്ച ഡെസ്ക്ടോപ്പ് തുറന്ന് ആ ഡാറ്റാബേസിൽ യാതൊരു ബുദ്ധിമുട്ടുമില്ലാതെ ക്വറി ചെയ്യുന്നു. രണ്ടു പ്രസ്താവനകളും ശരിയാണ്. ഡെസ്ക്ടോപ്പ് മറ്റൊരു ക്ലയന്റാണ്, നിയമങ്ങൾ ഇതിനകം വിശ്വസിക്കുന്ന സെഗ്മെന്റിൽ സ്വന്തം വിലാസവും, മുന്നോട്ട് കണക്ട് ചെയ്യുമ്പോൾ സ്വന്തം ഐഡന്റിറ്റിയും ഉണ്ട്. വൈരുദ്ധ്യമുള്ള നിയമമായി തോന്നുന്നത് സാധാരണയായി ആരും അവലോകനത്തിൽ ഇടാത്ത രണ്ടാമത്തെ അഭ്യർത്ഥനയാണ്.

രണ്ടാമത്തെ അഭ്യർത്ഥനയ്ക്ക് സ്വന്തം ക്ലയന്റ് വിലാസമുണ്ട്

സെഷനുള്ളിലെ ആപ്ലിക്കേഷൻ ഡാറ്റാബേസിലേക്ക് കണക്ഷൻ തുറക്കുമ്പോൾ, TCP ഹാൻഡ്ഷേക്ക് സെഷൻ ഹോസ്റ്റിൽ ആരംഭിക്കുന്നു. അതിന്റെ ഉറവിട വിലാസം ആ ഹോസ്റ്റിന്റെ നെറ്റ്വർക്കിനുള്ളതാണ്, അതിനാൽ വഴിയിലുള്ള ഓരോ റൂട്ടറും ഡാറ്റാബേസ് ഫയർവാളും നിങ്ങളുടെ ലാപ്ടോപ്പ് വന്ന ടണൽ പൂളല്ല, ഡെസ്ക്ടോപ്പിന്റെ സെഗ്മെന്റ് വിലയിരുത്തുന്നു. ആ പ്രവാഹത്തിൽ VPN വിലാസം ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ല. അതുകൊണ്ടാണ് ഉറവിടാധിഷ്ഠിത നിരാകരണ നിയമം ഒരേസമയം ശരിയും അപ്രസക്തവുമാകുന്നത്.

ഉറവിടം ലാപ്ടോപ്പിൽ നിന്നല്ല, സെഷനുള്ളിൽ നിന്ന് വായിക്കുക, തുടർന്ന് അതേ സ്ഥലത്തുനിന്ന് മുന്നോട്ടുള്ള വഴി പരിശോധിക്കുക. ഏത് ഹോസ്റ്റാണ് അഭ്യർത്ഥന നടത്തുന്നതെന്ന കാര്യത്തിൽ രണ്ടു ഉത്തരങ്ങളും യോജിക്കണം.

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

സെഷൻ റിപ്പോർട്ട് ചെയ്യുന്നത് അതേ സമയത്തിന് ഡാറ്റാബേസ് രേഖപ്പെടുത്തിയ വിലാസവുമായി താരതമ്യം ചെയ്യുക. ടണൽ പൂളിന് പകരം സെർവർ ലോഗ് ഡെസ്ക്ടോപ്പിന്റെ സബ്നെറ്റ് കാണിക്കുമ്പോൾ, ചോദ്യം നിയമം പ്രവർത്തിച്ചോ എന്നതിൽ നിന്ന് മാറി ഏത് ഹോസ്റ്റാണ് അഭ്യർത്ഥന നടത്തിയത് എന്നതാകുന്നു. അത് മറ്റൊരു ഉടമയുള്ള മറ്റൊരു അന്വേഷണമാണ്.

ഐഡന്റിറ്റിയും വിലാസവുമൊപ്പം മാറുന്നു

മുന്നോട്ടുള്ള കണക്ഷൻ സാധാരണയായി സെഷന്റെ ടോക്കൺ, സംഭരിച്ച ക്രെഡൻഷ്യൽ അല്ലെങ്കിൽ ആപ്ലിക്കേഷന്റെ സേവന അക്കൗണ്ട് ആയി പ്രാമാണീകരിക്കുന്നു, റിസോഴ്സ് തനിക്ക് നൽകിയത് രേഖപ്പെടുത്തുന്നു. അതിനാൽ ഡാറ്റാബേസിൽ സേവന അക്കൗണ്ട് കാണിക്കുന്ന ഓഡിറ്റ് ട്രെയിൽ ഒരു മനുഷ്യൻ ക്വറി നടത്തിയെന്ന് തെളിയിക്കുന്നില്ല. അത് ആ മനുഷ്യനെ തിരിച്ചറിയുന്നുമില്ല. ഡെസ്ക്ടോപ്പിന്റെ സ്വന്തം സെഷൻ ലോഗ് മാത്രമാണ് ആ രണ്ട് രേഖകളെ ബന്ധിപ്പിക്കുന്നത്.

അധികാരം രണ്ടുതവണ സംഭവിക്കുന്നു, രണ്ടാമത്തെ തീരുമാനം വ്യത്യസ്ത ഇൻപുട്ടുകൾ ഉപയോഗിച്ചാണ് എടുക്കുന്നത്. ആദ്യത്തേത് പേരുള്ള ഉപയോക്താവിന് ഡെസ്ക്ടോപ്പ് സൈൻ-ഇൻ നൽകുന്നു, രണ്ടാമത്തേത് ആ ഉപയോക്താവിന്റെ ടോക്കണിനോ ആപ്ലിക്കേഷന്റെ അക്കൗണ്ടിനോ റിസോഴ്സിൽ ചെയ്യാനാകുന്നത് നൽകുന്നു. ഡെസ്ക്ടോപ്പ് തുറക്കാൻ കഴിയുന്ന ഹെൽപ്ഡെസ്ക് ഗ്രൂപ്പ് സ്വയമേവ ഉപഭോക്തൃ പട്ടിക വായിക്കാൻ കഴിയുന്ന ഗ്രൂപ്പല്ല.

ആക്സസ് കുറിപ്പ് എഴുതുന്നതിന് മുമ്പ് ടോക്കണും പ്രതിനിധാന പാതയും നോക്കുക. രണ്ടും സെഷനുള്ളിൽ നിന്ന് കാണാം, ഉത്തരം ഊഹമല്ലാത്ത ഒരേയൊരു സ്ഥലം അതാണ്.

whoami /groups
klist
query session

ആപ്ലിക്കേഷൻ സേവന അക്കൗണ്ട് ഉപയോഗിക്കുന്നെങ്കിൽ, മുന്നോട്ട് പ്രധാനമായത് അതിന്റെ അവകാശങ്ങളാണ്. ആ ക്രെഡൻഷ്യൽ കറക്കുന്നത് ആക്സസ് അവലോകനത്തിന്റെ ഭാഗമാണ്, പിന്നീടുള്ള പ്രവർത്തന ചിന്തയല്ല.

നേരിട്ടുള്ള വഴി ഇപ്പോഴും ശരിയായി തടഞ്ഞിരിക്കുന്നത് എന്തുകൊണ്ട്

ലക്ഷ്യസ്ഥാനം മറ്റൊരു വഴിയിൽ എത്താമെന്നത് കൊണ്ടുമാത്രം നിരാകരണ നിയമം തെറ്റല്ല. വിഭജനം ഓരോ ഉറവിടത്തിനും അനുസരിച്ച് വിലയിരുത്തുന്നു, ഡെസ്ക്ടോപ്പ്, ആരെങ്കിലും അതിനെ ഡാറ്റാബേസിലേക്കുള്ള വഴിയായി കരുതുന്നതിന് വളരെ മുമ്പേ അനുവദിച്ച സെഗ്മെന്റിലാണ് ഇരിക്കുന്നത്. ഒന്നും നയത്തെ മറികടന്നിട്ടില്ല. രണ്ടു വ്യത്യസ്ത ഫലങ്ങളുള്ള രണ്ടു വ്യത്യസ്ത ഉറവിടങ്ങളെ നയം വിവരിക്കുന്നു എന്നു മാത്രം.

ആ ഹോസ്റ്റിലെ ഓരോ അനുവദിച്ച സെഷനും എന്ത് തുടങ്ങാമെന്നാണ് അവലോകനം ഉത്തരം നൽകേണ്ടത്. സംഭരിച്ച സെഷനുകളുള്ള ബ്രൗസറുകൾ, മാപ്പ് ചെയ്ത ഡ്രൈവുകൾ, ക്രെഡൻഷ്യൽ കൈവശമുള്ള ഏജന്റുകൾ, പ്രാദേശികമായി കേൾക്കുന്ന സേവനങ്ങൾ എന്നിവയെല്ലാം ഡെസ്ക്ടോപ്പിന്റെ വ്യാപ്തി വിപുലീകരിക്കുന്നു, അവയൊന്നും സൈൻ-ഇൻ നൽകിയ ടിക്കറ്റിൽ പ്രത്യക്ഷപ്പെടുന്നില്ല. ആ പട്ടികയാണ് യഥാർത്ഥ അനുമതി ഉപരിതലം.

സ്പ്രെഡ്ഷീറ്റിൽ നിന്നല്ല, ഒരു പരീക്ഷണ സെഷനുള്ളിൽ നിന്ന് അത് എണ്ണുക. കുറച്ച് കമാൻഡുകൾ ഉപരിതലത്തിന്റെ ഭൂരിഭാഗവും ഉൾക്കൊള്ളുന്നു.

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

അതിർത്തി ബോധപൂർവം തിരഞ്ഞെടുക്കുക

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

ഒരു റിപ്പോർട്ടിന്, പ്രസിദ്ധീകരിച്ച ആപ്ലിക്കേഷനോ പരിമിതമായ അക്കൗണ്ടോ പൊതുവായ ഡെസ്ക്ടോപ്പിനേക്കാൾ ചെറിയ അനുമതിയാണ്. യഥാർത്ഥത്തിൽ നിരവധി ഉപകരണങ്ങൾ വേണ്ട അറ്റകുറ്റപ്പണിക്ക് ഡെസ്ക്ടോപ്പ് ശരിയായേക്കാം, പക്ഷേ അപ്പോൾ അംഗീകാരം ഒരു ആപ്ലിക്കേഷനെയല്ല, മുഴുവൻ ഹോസ്റ്റിനെയും വിവരിക്കുന്നു. ഇവയിൽ ഏതിനോടാണ് അവർ യോജിക്കുന്നതെന്ന് റിസോഴ്സ് ഉടമയോട് ചോദിക്കുക.

ഡാറ്റാ ചലനം വേറിട്ട ഒരു സ്വിച്ചാണ്. ക്ലിപ്പ്ബോർഡ്, ഡ്രൈവ് റീഡയറക്ഷൻ, ഡൗൺലോഡുകൾ എന്നിവ കമ്പനിയുടെ ഡാറ്റ ക്ലയന്റിലേക്ക് കൊണ്ടുപോകാം, ആപ്ലിക്കേഷൻ വിദൂരത്തുനിന്ന് പ്രവർത്തിപ്പിക്കുന്നത് ഡാറ്റയെ സ്വയമേവ വിദൂരത്ത് നിർത്തുന്നില്ല.

രണ്ട് അംഗീകാരങ്ങളും നീക്കം ചെയ്യാനുള്ള വഴിയും പരിശോധിക്കുക

രേഖയിൽ രണ്ട് അംഗീകാരങ്ങൾ വേണം: ഡെസ്ക്ടോപ്പ് എത്തി തുറക്കാനുള്ള അവകാശം, അതിനുള്ളിൽ നിന്ന് റിസോഴ്സുകൾ ഉപയോഗിക്കാനുള്ള അവകാശം. ഓരോന്നിനും ഒരു ഉടമയെ പേരിടുക, രണ്ടാമത്തേത് റിസോഴ്സ് അവലോകനം ചെയ്യുന്ന ഓരോർക്കും ദൃശ്യമായി നിർത്തുക. ഓഡിറ്റർ ചോദിക്കുന്നത് ആ രണ്ടാമത്തെ എൻട്രിയെക്കുറിച്ചാണ്, കാരണം അത് പ്രവേശനമല്ല, വ്യാപ്തി വിവരിക്കുന്നു. മാറ്റം അംഗീകരിക്കുന്നതിന് മുമ്പ് രണ്ടും എഴുതുക, ആദ്യ സംഭവത്തിന് ശേഷമല്ല.

തുടർന്ന് നീക്കം ചെയ്യൽ പരീക്ഷിക്കുക, കാരണം വിച്ഛേദിക്കപ്പെട്ട സെഷൻ അതിന്റെ കാരണത്തേക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കാം. സെഷൻ പട്ടിക ഇപ്പോഴും എന്ത് പ്രവർത്തിക്കുന്നു എന്ന് കാണാനുള്ള വേഗതയേറിയ സ്ഥലമാണ്.

query session
query user
qwinsta /server:rdsh01.corp.internal

ക്ലയന്റ് വിച്ഛേദിക്കുമ്പോൾ വിദൂര സെഷൻ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കും, അതിന്റെ നെറ്റ്വർക്ക് കണക്ഷനുകളും കാഷ് ചെയ്ത ക്രെഡൻഷ്യലുകളും ആ സെഷൻ അവസാനിക്കുന്നതുവരെ ഉപയോഗയോഗ്യമായി തുടരാം. സൈൻ ഔട്ട് ചെയ്യുക, അല്ലെങ്കിൽ സെഷൻ വ്യക്തമായി അവസാനിപ്പിക്കുക, തുടർന്ന് താഴത്തെ കൗണ്ടർ പിന്നീട് മുന്നോട്ട് പോകുന്നത് നിർത്തുന്നുവെന്ന് ഉറപ്പാക്കുക. ലാപ്ടോപ്പിന്റെ മൂടി മാത്രം അടയ്ക്കുന്ന നീക്കം ചെയ്യൽ പരീക്ഷണം ഒന്നും തെളിയിക്കുന്നില്ല. അതേ പരീക്ഷണം ഒരിക്കൽ അക്കൗണ്ട് പ്രവർത്തനരഹിതമാക്കി, ഒരിക്കൽ ഡെസ്ക്ടോപ്പ് അനുമതി നീക്കി നടത്തുക, തുടർന്ന് ഓരോ സാഹചര്യത്തിലും റിസോഴ്സ് എന്ത് ലോഗ് ചെയ്തു എന്ന് എഴുതുക.