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

ક્લાયંટ વિચ્છેદિત કરવાથી દૂરસ્થ સત્ર ચાલુ રહે છે, અને તેના નેટવર્ક જોડાણો અને કેશ કરેલા ઓળખપત્રો એ સત્ર પૂરું થાય ત્યાં સુધી વાપરી શકાય તેવા રહી શકે છે. સાઇન આઉટ કરો, અથવા સત્ર સ્પષ્ટપણે સમાપ્ત કરો, અને ખાતરી કરો કે પછી નીચેનું કાઉન્ટર આગળ વધવાનું બંધ કરે છે. ફક્ત લેપટોપનું ઢાંકણ બંધ કરતી દૂર કરવાની કસોટી કંઈ સાબિત કરતી નથી. એ જ કસોટી એક વાર ખાતું નિષ્ક્રિય કરીને અને એક વાર ડેસ્કટોપ પરવાનગી દૂર કરીને કરો, પછી દરેક કિસ્સામાં સંસાધને શું લોગ કર્યું તે નોંધો.