NPS-grupprinciper är inte verkställande av VPN-resurser

Två grupper, två åtkomsteprofiler, en VPN-gateway, och till slut når båda grupperna samma servrar. Den vanliga orsaken är inte en trasig princip utan en saknad andra hälft av designen: NPS avgör vem som får upprätta en session, och något annat måste avgöra vad den sessionen får nå. När bara den första hälften finns lyckas auktoriseringen för alla som autentiserar sig. Principen gör sitt jobb, och designen är fortfarande ofullständig.

En nätverksprincip som matchar en grupp är bevis om insläpp. Det är inte bevis om paket, och gapet mellan dessa två påståenden är där det mesta av detta arbete sker.

Hitta principen som faktiskt släppte in sessionen

NPS utvärderar ordnade nätverksprinciper, och den första aktiverade regeln vars villkor matchar vinner. Villkor kan omfatta gruppmedlemskap för användare eller dator, anslutningstyp, tid och enhetsstatus. Därför släpper en bred princip som står tidigare i listan in en anslutning innan en snävare regel längre ner ens beaktas. Ordningen är inte en detalj i gränssnittet; ordningen är principen.

Läs listan i ordning och identifiera den som matchade, och notera sedan vilka inställningar den returnerade. Gruppens namn i redigeraren är inte resultatet; resultatet är den auktorisering som servern tog emot. Håll användarauktorisering och enhetsauktorisering åtskilda där driftsättningen använder båda, eftersom ett konto som får öppna en tunnel inte automatiskt är ett konto som bör nå varje intern tjänst.

RADIUS-svaret är en instruktion, inte ett filter

Ett Filter-Id-attribut bär namnet på en filterlista. Det levererar inte en portabel uppsättning paketfilterregler som varje mottagare förstår, och att skicka ett namn som gatewayen aldrig definierat verkställer ingenting alls. Samma försiktighet gäller VLAN-attribut: att tilldela en tunnelsession ett VLAN är inte i sig en routad åtkomstregel för den användaren.

Det är här en design som ser komplett ut på NPS-sidan tyst inte gör någonting. Bekräfta med gatewayleverantörens dokumentation vilka auktoriseringsattribut som stöds och vad mottagaren gör med var och en, i stället för att anta att ett standardattributnamn innebär standardbeteende.

Placera verkställigheten där trafiken passerar

En gateway som behandlar användarens paket kan tillämpa ett filter per session, mappa en grupp till en gatewayprincip eller ge sessionen en adress från en avskild pool som en brandvägg behandlar annorlunda. Var och en av dessa kan fungera, och de misslyckas på olika sätt. Bestäm vilken mekanism din gateway stöder innan du skriver principen som namnger den. Skriv sedan ner vad som händer med en session när mekanismen saknas, eftersom tystnad är standard.

Beskriv den avsedda behörigheten i fyra delar: källidentitet eller grupp, destination, protokoll och port. Lägg till de beroenden användaren verkligen behöver, som DNS eller en autentiseringstjänst, annars bryter begränsningen inloggningsflöden som ingen kom på att testa. Skriv regeln mot gränssnittet som faktiskt filtrerar, inte mot gränssnittet som råkar vara öppet i redigeraren.

Ta också hänsyn till översättning. Om en brandvägg längre ner ser en enda översatt källadress för varje tunnelanvändare kan den inte skilja individer enbart från den adressen, och en regel skriven som om den kunde blir antingen oanvändbar eller för bred.

Klientprofiler lever på den icke betrodda sidan

En hanterad VPN-profil kan skjuta ut rutter, regler för delad tunnel eller programfilter, och de formar hur en väluppfostrad enhet beter sig. De är inte skydd för tjänsten, eftersom klienten är den part du försöker begränsa. Att ta bort en rutt i en profil är inte heller auktorisering, eftersom en klient kan ha en annan väg till samma destination.

Behandla klientinställningar som bekvämlighet och gatewayinställningar som kontroll. När de två är oeniga har gatewayen rätt, eftersom det är den som ser paketen.

Acceptera med två konton och spåra sedan i ordning

Skapa två vanliga testkonton med olika avsedda behörigheter, upprätta nya sessioner och kontrollera den effektiva gatewayprincipen för var och en. Testa sedan en ofarlig tillåten åtgärd och en specifikt nekad resurs. En misslyckad ping bevisar mycket lite i sig, eftersom ICMP kan vara filtrerat medan TCP-tjänsten bakom svarar glatt.

När båda kontona fortfarande får bred åtkomst, spåra i fast ordning: vilken princip som matchade, vilken auktorisering svaret bar och vad gatewayen gjorde med den. Att lägga till fler NPS-attribut innan du bekräftar att mottagaren implementerar dem är sättet ett litet auktoriseringsproblem blir ett ändringsfönster utan resultat.