RDP byter klient: varför databasen ser en annan värd

Din VPN-regel nekar databasen och ärendet stängs som ett brandväggsfel, medan samma användare öppnar ett publicerat skrivbord och frågar databasen utan problem. Båda påståendena är sanna. Skrivbordet är en annan klient, med sin egen adress i ett segment som reglerna redan litar på, och med sin egen identitet när det ansluter vidare. Det som ser ut som en motstridig regel är oftast en andra förfrågan som ingen lade in i granskningen.

Den andra förfrågan har en egen klientadress

När ett program inne i sessionen öppnar en anslutning till databasen börjar TCP-handskakningen på sessionsvärden. Dess källadress tillhör den värdens nätverk, så varje router och databasbrandvägg på vägen bedömer skrivbordets segment och inte den tunnelpool som din bärbara dator kom från. VPN-adressen förekommer aldrig i det flödet. Därför kan en nekanderegel baserad på källa vara både korrekt och irrelevant samtidigt.

Läs ursprunget inifrån sessionen i stället för från den bärbara datorn och testa sedan vägen vidare från samma plats. De två svaren bör vara överens om vilken värd som gör förfrågan.

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

Jämför det sessionen rapporterar med den adress databasen registrerade för samma tidpunkt. När serverloggen visar skrivbordets subnät i stället för tunnelpoolen slutar frågan handla om regeln utlöstes och blir vilken värd som gjorde förfrågan. Det är en annan undersökning med en annan ägare.

Identiteten ändras liksom adresseringen

Vidareanslutningen autentiserar sig vanligen som sessionens token, en lagrad autentiseringsuppgift eller ett tjänstekonto för programmet, och resursen registrerar vad den fick. Ett granskningsspår som visar ett tjänstekonto på databasen bevisar därför inte att en människa körde frågan. Det identifierar inte heller människan. Bara skrivbordets egen sessionslogg knyter de två posterna samman.

Auktorisering sker två gånger, och det andra beslutet fattas med andra indata. Det första ger en namngiven användare inloggning på ett skrivbord, medan det andra ger vad den användarens token eller programmets konto kan göra mot resursen. En helpdeskgrupp som får öppna ett skrivbord är inte automatiskt en grupp som får läsa en kundtabell.

Titta på token och delegeringsväg innan du skriver åtkomstanteckningen. Båda syns inifrån sessionen, och det är den enda platsen där svaret inte är en gissning.

whoami /groups
klist
query session

Om programmet använder ett tjänstekonto är det dess rättigheter som avgör framåt. Rotation av den autentiseringsuppgiften hör till åtkomstgranskningen, inte till en operativ eftertanke.

Varför den direkta vägen fortfarande är blockerad, och med rätta

Nekanderegeln är inte fel bara för att målet går att nå på annat sätt. Segmentering bedöms per källa, och skrivbordet ligger i ett segment som tilläts långt innan någon tänkte på det som en väg till databasen. Inget kringgick policyn. Policyn beskriver helt enkelt två olika källor med två olika utfall.

Det granskningen måste svara på är vad varje auktoriserad session på den värden kan starta. Webbläsare med sparade sessioner, mappade enheter, agenter som håller autentiseringsuppgifter och lokalt lyssnande tjänster utökar alla skrivbordets räckvidd, och ingen av dem syns i ärendet som gav inloggningen. Den inventeringen är den verkliga behörighetsytan.

Räkna upp den inifrån en testsession, inte från ett kalkylark. En handfull kommandon täcker det mesta av ytan.

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

Välj gränsen medvetet

Tre former passar olika uppgifter, och valet bör följa uppgiften och inte verktyget som råkar finnas. Ett publicerat program exponerar ett program med egna behörigheter, ett fullt skrivbord exponerar allt användarens profil kan göra, och ett snävt databaskonto med källbegränsning exponerar en resurs helt utan skrivbord. Den snävaste form som fortfarande slutför arbetet är den som ska dokumenteras. Allt bredare behöver en anledning skriven bredvid.

För en enda rapport är ett publicerat program eller ett begränsat konto en mindre tilldelning än ett allmänt skrivbord. För underhåll som verkligen behöver flera verktyg kan skrivbordet vara rätt, men då beskriver godkännandet hela värden och inte ett program. Fråga resursägaren vilket av dem de säger ja till.

Dataflytt är en separat brytare. Urklipp, enhetsomdirigering och nedladdningar kan föra företagets data till klienten, och att köra ett program på distans håller inte data på distans av sig själv.

Kontrollera båda godkännandena och borttagningsvägen

Två godkännanden hör till posten: rätten att nå och öppna skrivbordet, och rätten att använda resurser inifrån det. Namnge en ägare för var och en och håll den andra synlig för den som granskar resursen. Det är den andra posten en revisor kommer att fråga om, eftersom den beskriver räckvidd och inte inträde. Skriv båda innan ändringen godkänns, inte efter den första incidenten.

Testa sedan borttagningen, eftersom en frånkopplad session kan överleva skälet till den. Sessionstabellen är den snabbaste platsen att se vad som fortfarande körs.

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

Frånkoppling av klienten lämnar fjärrsessionen igång, och dess nätverksanslutningar och cachelagrade autentiseringsuppgifter kan förbli användbara tills sessionen tar slut. Logga ut, eller avsluta sessionen uttryckligen, och bekräfta att räknaren längre ned slutar att flytta sig efteråt. Ett borttagningstest som bara stänger locket på den bärbara datorn bevisar ingenting. Kör samma test en gång med avstängt konto och en gång med indraget skrivbordsbehörighet och notera sedan vad resursen loggade i varje fall.