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

क्लाइन्ट विच्छेद गर्दा टाढाको सत्र चलिरहन्छ, र यसका नेटवर्क जडान र क्यास गरिएका प्रमाणपत्र त्यो सत्र नसकिँदासम्म प्रयोगयोग्य रहन सक्छन्। साइन आउट गर्नुहोस्, वा सत्र स्पष्ट रूपमा अन्त्य गर्नुहोस्, र त्यसपछि तलको काउन्टर अगाडि बढ्न रोकिन्छ भनी पुष्टि गर्नुहोस्। केवल ल्यापटपको ढकनी बन्द गर्ने हटाउने परीक्षणले केही प्रमाणित गर्दैन। त्यही परीक्षण एक पटक खाता निष्क्रिय गरेर र एक पटक डेस्कटप अनुमति हटाएर गर्नुहोस्, त्यसपछि प्रत्येक अवस्थामा स्रोतले के लग गर्‍यो लेख्नुहोस्।