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

క్లయింట్‌ను డిస్కనెక్ట్ చేయడం దూర సెషన్‌ను నడుస్తూనే ఉంచుతుంది, దాని నెట్‌వర్క్ కనెక్షన్లు మరియు క్యాష్ చేసిన ఆధారాలు ఆ సెషన్ ముగిసే వరకు ఉపయోగకరంగా ఉండవచ్చు. సైన్ అవుట్ చేయండి, లేదా సెషన్‌ను స్పష్టంగా ముగించండి, తర్వాత కింది కౌంటర్ ముందుకు సాగడం ఆగుతుందని నిర్ధారించండి. ల్యాప్‌టాప్ మూతను మాత్రమే మూసే తొలగింపు పరీక్ష ఏమీ నిరూపించదు. అదే పరీక్షను ఒకసారి ఖాతా నిష్క్రియం చేసి, ఒకసారి డెస్క్‌టాప్ అనుమతి తీసివేసి నిర్వహించండి, తర్వాత ప్రతి సందర్భంలో రిసోర్స్ ఏమి లాగ్ చేసిందో రాయండి.