RDP ændrer klienten: hvorfor databasen ser en anden vært

Din VPN-regel afviser databasen, og sagen lukkes som en firewallfejl, mens den samme bruger åbner et publiceret skrivebord og forespørger den database uden problemer. Begge udsagn er sande. Skrivebordet er en anden klient med sin egen adresse på et segment, som reglerne allerede stoler på, og sin egen identitet, når den forbinder videre. Det, der ligner en modstridende regel, er som regel en anden anmodning, som ingen lagde i gennemgangen.

Den anden anmodning har sin egen klientadresse

Når et program inde i sessionen åbner en forbindelse til databasen, starter TCP-håndtrykket på sessionsværten. Dens kildeadresse hører til den værtens netværk, så hver router og databasefirewall på vejen vurderer skrivebordets segment i stedet for den tunnelpulje, din bærbare computer kom fra. VPN-adressen optræder aldrig i den strøm. Derfor kan en kildestyret afvisningsregel være både korrekt og irrelevant på samme tid.

Læs oprindelsen inde fra sessionen i stedet for fra den bærbare computer, og test derefter vejen videre fra samme sted. De to svar bør være enige om, hvilken vært der sender anmodningen.

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

Sammenlign det, sessionen rapporterer, med den adresse, databasen registrerede for samme tidspunkt. Når serverloggen viser skrivebordets undernet i stedet for tunnelpuljen, holder spørgsmålet op med at være, om reglen blev udløst, og bliver til, hvilken vært der sendte anmodningen. Det er en anden undersøgelse med en anden ejer.

Identiteten ændrer sig også, ikke kun adresseringen

Den videre forbindelse godkender sig normalt som sessionens token, en gemt legitimationsoplysning eller en tjenestekonto for programmet, og ressourcen registrerer, hvilken af dem den fik. Et revisionsspor, der viser en tjenestekonto på databasen, beviser derfor ikke, at et menneske kørte forespørgslen. Det identificerer heller ikke mennesket. Kun skrivebordets egen sessionslog knytter de to poster sammen.

Autorisation sker to gange, og den anden beslutning træffes med andre input. Den første giver en navngivet bruger login på et skrivebord, mens den anden giver, hvad den brugers token eller programmets konto kan gøre ved ressourcen. En helpdeskgruppe, der må åbne et skrivebord, er ikke automatisk en gruppe, der må læse en kundetabel.

Se på tokenet og delegeringsvejen, før du skriver adgangsnotatet. Begge er synlige inde fra sessionen, og det er det eneste sted, hvor svaret ikke er et gæt.

whoami /groups
klist
query session

Hvis programmet bruger en tjenestekonto, er det dens rettigheder, der betyder noget videre. Rotation af den legitimationsoplysning hører i adgangsgennemgangen, ikke i en operationel eftertanke.

Hvorfor den direkte vej stadig er blokeret, og med rette

Afvisningsreglen er ikke forkert, bare fordi destinationen kan nås ad en anden vej. Segmentering vurderes per kilde, og skrivebordet ligger på et segment, der blev tilladt længe før, nogen tænkte på det som en rute til databasen. Intet omgik politikken. Politikken beskriver blot to forskellige kilder med to forskellige resultater.

Det, gennemgangen skal svare på, er, hvad hver autoriseret session på den vært kan starte. Browsere med gemte sessioner, tilknyttede drev, agenter med legitimationsoplysninger og lokalt lyttende tjenester udvider alle skrivebordets rækkevidde, og ingen af dem optræder i den sag, der gav login. Den fortegnelse er den egentlige tilladelsesflade.

Optæl den inde fra en testsession, ikke fra et regneark. En håndfuld kommandoer dækker det meste af fladen.

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

Vælg grænsen med vilje

Tre former passer til forskellige opgaver, og valget bør følge opgaven i stedet for det værktøj, der tilfældigt findes. Et publiceret program udstiller ét program med sine egne tilladelser, et fuldt skrivebord udstiller alt, brugerens profil kan gøre, og en afgrænset databasekonto med en kildebegrænsning udstiller én ressource helt uden skrivebord. Den snævrest form, der stadig fuldfører arbejdet, er den, der skal dokumenteres. Alt bredere kræver en grund skrevet ved siden af.

Til en enkelt rapport er et publiceret program eller en begrænset konto en mindre bevilling end et generelt skrivebord. Til vedligeholdelse, der virkelig kræver flere værktøjer, kan skrivebordet være rigtigt, men så beskriver godkendelsen hele værten i stedet for ét program. Spørg ressourceejeren, hvilket af dem de siger ja til.

Dataflytning er en separat kontakt. Udklipsholder, drevomdirigering og download kan føre virksomhedsdata til klienten, og det at køre et program eksternt holder ikke data eksternt i sig selv.

Kontroller begge godkendelser og fjernelsesvejen

To godkendelser hører i posten: retten til at nå og åbne skrivebordet, og retten til at bruge ressourcer inde fra det. Navngiv en ejer for hver af dem, og hold den anden synlig for den, der gennemgår ressourcen. Det er den anden post, en revisor vil spørge om, fordi den beskriver rækkevidde i stedet for adgang. Skriv begge, før ændringen godkendes, ikke efter den første hændelse.

Test derefter fjernelsen, fordi en afbrudt session kan overleve grunden til den. Sessionstabellen er det hurtigste sted at se, hvad der stadig kører.

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

Afbrydelse af klienten lader fjernsessionen køre, og dens netværksforbindelser og cachelagrede legitimationsoplysninger kan forblive brugbare, indtil den session slutter. Log ud, eller afslut sessionen udtrykkeligt, og bekræft, at tælleren længere nede holder op med at rykke frem bagefter. En fjernelsestest, der kun lukker den bærbare computers låg, beviser intet. Kør den samme test én gang med deaktiveret konto og én gang med skrivebordstilladelsen fjernet, og noter derefter, hvad ressourcen loggede i hvert tilfælde.