Att lägga en användare i en VPN-grupp ger inte åtkomst i sig

Du lade kontot i rätt grupp, inloggningen lyckades och anslutningen nekas ändå — eller så ansluter den och når inget användbart. Den vanliga reflexen är att lägga användaren i fler grupper tills något ger med sig, och det är så organisationer till slut beviljar långt mer än ärendet bad om. Gruppmedlemskap är en av flera indata till ett auktoriseringsbeslut, aldrig beslutet i sig: en gateway samlar in en handfull fakta om sessionen, matchar dem mot ordnad policy och avgör först därefter vad sessionen får röra. Om ett annat villkor fallerade ändrar en gruppredigering ingenting utom din exponering. Här följer hur beslutet faktiskt sätts samman, var medlemskap slutar räcka och den kontroll som visar vilket fel du tittar på.

Gruppmedlemskap är ett villkor, inte en behörighet

I RADIUS kommer gruppen in som ett auktoriseringsattribut, och attribut beskriver sessionen i stället för att bevilja den. Servern svarar med Access-Accept eller Access-Reject; vid accept kan den bifoga Filter-Id, Class eller tunnelattributen från RFC 2868, och nätutrustningen i andra änden tolkar dem precis som dess leverantör bestämt. Ingenting i protokollet kopplar en grupp till full åtkomst. Den kopplingen skrivs av den som konfigurerade policyn på gatewayen eller nätaccessservern, och den kan vara så snäv som en enda värd.

Det är därför ett identiskt gruppnamn beter sig olika på två system. Microsoft NPS sätter samman nätverkspolicyer av villkor, begränsningar och inställningar och utvärderar dem i en konfigurerad ordning. OpenVPN Access Server har sin egen modell för grupper och åtkomstregler, medan en community-OpenVPN-server ofta lägger hela frågan på ett client-connect-skript eller en client-config-dir-fil. Var och en konsumerar en grupp; ingen delar en annans prioritetsordning. En regeluppsättning som kopierats mellan dem bevisar ingenting om den du felsöker.

Regeln som matchade avgör, inte gruppen du förväntade dig

De flesta motorer stannar vid den första policy som matchar, eller vid den mest specifika. Om policy 3 nekar och policy 7 tillåter kan en session misslyckas utan att någonsin nå regeln som skulle ha släppt igenom den. Ordningen är en verklig inställning i NPS och i de flesta produkter för nätverksåtkomstkontroll, och den glider när policyer läggs till under åren. Någon lyfter en nekande policy högst upp för att begränsa en orelaterad incident, och en grupp som fungerade förra kvartalet slutar fungera.

Villkor som följer med gruppen är den andra halvan av problemet. Enhetens säkerhetsstatus, autentiseringsmetod, slutförd MFA, källnätverk, certifikatets subjekt eller ett tidsfönster på dygnet kan alla ligga i samma policy. När ett av dem inte är uppfyllt matchar policyn inte, motorn faller igenom och ett standardnekande gäller. Från användarens plats ser det ut som att gruppen ignoreras; från motorns plats konsulterades gruppen aldrig.

Katalogdetaljer ger samma illusion. En policy som matchar på Windows-gruppmedlemskap läser SID:n i användarens token, och bara säkerhetsgrupper räknas upp där — en distributionsgrupp dyker aldrig upp. En användares primärgrupp bärs i ett eget fält i stället för i den uppräknade listan, så en policy som är knuten till den gruppen kan fallera tyst. Omdöpta grupper och SID:n över domängränser lägger till översättningssteg som fallerar tyst när en förtroenderelation är enkelriktad.

Läs posten för godkännande eller nekande innan du rör en grupp

Ställ en fråga först: nådde begäran över huvud taget auktoriseringssteget? I NPS finns svaret redan i händelseloggen, där 6272 registrerar en beviljad åtkomst, 6273 ett nekande och 6274 en begäran som servern kastade innan den utvärderade policyn. De tre siffrorna delar problemet i tre olika utredningar, och bara en av dem handlar om grupper.

När loggen är utom räckhåll, fråga servern direkt och läs vad den returnerar. Ett svar utan Filter-Id och utan tunnelattribut säger att servern betraktar sessionen som alldaglig och att gatewayen tillämpar egna regler. Ett svar som bär attribut som tillämpningspunkten inte implementerar är ett annat fel: auktoriseringen gick igenom och enheten som skulle agera på den ignorerade resultatet.

radtest alice 'password' 10.0.0.5 0 testing123

Jämför de returnerade attributen med dem som gatewayen dokumenterar, inte med vad gruppnamnet antyder. Den jämförelsen skiljer vanligen ett policyproblem från ett tillämpningsproblem innan någon redigerar en grupp.

En gruppändring är inte retroaktiv

Auktoriseringsattribut returneras en gång, när sessionen autentiseras. Gatewayen lagrar dem på sessionen och läser inte om katalogen för varje paket, vilket är precis varför en etablerad session fortsätter fungera efter att du tagit bort någon från en grupp. Det är också varför en ny session kan misslyckas medan en gammal fortfarande kör, och varför två användare med identiska grupplistor kan få olika resultat.

För att en ändring ska slå igenom behöver du ett nytt auktoriseringsbeslut, inte bara nya nycklar. Där servern stöder dynamisk auktorisering enligt RFC 5176 tvingar en Disconnect-Request eller CoA-Request till UDP 3799 fram en omvärdering av sessionen; annars kopplar du från klienten och låter den återansluta. Omförhandling uppdaterar tunnelnycklarna och lämnar normalt auktoriseringsresultatet orört, så att behandla den som en behörighetsuppdatering ger motsägelsefulla testresultat.

Åtgärda villkoret, inte gruppen

När du vet vilken policy som utlöstes är reparationen oftast liten: ordna om ett nekande som skymmer det avsedda tillåtandet, lägg till det saknade enhets- eller MFA-villkoret i policyn du menade skulle matcha, eller skriv en snäv regel för just den resursen i stället för att lyfta användaren in i en grupp som bär tio andra. Att vidga medlemskapet för att stänga ett ärende är den dyra versionen av samma åtgärd, och det är så en supportgenväg blir ett stående undantag som ingen granskar.

En kort slinga håller ändringen ärlig:

• Reproducera nekandet med det ursprungliga kontot och skriv ned händelse-ID:t innan du ändrar något.
• Ändra ett objekt — en policyordning, ett enskilt villkor eller en grupp — och anteckna vilket.
• Öppna en ny session, bekräfta att beviljandet syns i loggen och bekräfta att resursen faktiskt öppnas.
• Testa en användare som fortfarande bör nekas, så att åtgärden inte råkade vidga policyn.

Om beviljandet är korrekt och resursen fortfarande inte öppnas, har problemet flyttat till routning eller namnmatchning i samma stund som auktoriseringen lyckades. Håll de två felen åtskilda, så tar nästa ärende minuter i stället för en eftermiddag.