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

क्लायंट तोडल्यास दूरस्थ सत्र चालू राहते, आणि त्याची नेटवर्क कनेक्शन्स व कॅशे केलेली ओळखपत्रे ते सत्र संपेपर्यंत वापरण्यायोग्य राहू शकतात। साइन आउट करा, किंवा सत्र स्पष्टपणे संपवा, आणि नंतर खालचा काउंटर पुढे सरकणे थांबतो याची खात्री करा। फक्त लॅपटॉपचे झाकण बंद करणारी काढण्याची चाचणी काहीही सिद्ध करत नाही। तीच चाचणी एकदा खाते निष्क्रिय करून आणि एकदा डेस्कटॉप परवानगी काढून करा, नंतर प्रत्येक बाबतीत संसाधनाने काय लॉग केले ते लिहा।