At føje en bruger til en VPN-gruppe giver ikke adgang i sig selv

Du har sat kontoen i den rigtige gruppe, login lykkedes, og forbindelsen afvises stadig, eller den oprettes og når intet brugbart. Den sædvanlige reaktion er at tilføje brugeren til flere grupper, indtil noget giver efter, og sådan giver organisationer langt mere end billetten bad om. Gruppemedlemskab er ét input til autorisationsbeslutningen, aldrig beslutningen selv: gatewayen samler nogle fakta om sessionen, matcher dem mod ordnet politik og beslutter først derefter, hvad sessionen må røre. Hvis en anden betingelse fejlede, ændrer gruppen intet ud over din eksponering.

Gruppemedlemskab er en betingelse, ikke en tilladelse

I RADIUS ankommer gruppen som et autorisationsattribut, og attributter beskriver sessionen i stedet for at tillade den. Serveren svarer med Access-Accept eller Access-Reject; ved accept kan den vedhæfte Filter-Id, Class eller tunnelattributterne fra RFC 2868, og netværksudstyret i den anden ende fortolker dem, som producenten besluttede. Intet i protokollen afbilder en gruppe til fuld adgang; den afbildning skrives af den, der har konfigureret politikken på gatewayen eller netværksadgangsserveren, og den kan være så snæver som én vært.

Derfor opfører et identisk gruppenavn sig forskelligt på to systemer. Microsoft NPS sammensætter netværkspolitikker af betingelser, begrænsninger og indstillinger og evaluerer dem i en fastlagt rækkefølge. OpenVPN Access Server har sin egen gruppe- og adgangsregelmodel, mens en community-OpenVPN-server ofte overlader hele spørgsmålet til et client-connect-script eller en fil i client-config-dir. Hver især forbruger en gruppe; ingen deler den andens prioritetslogik.

Det er reglen, der matchede, der afgør, ikke gruppen du forventede

De fleste motorer stopper ved den første politik, der matcher, eller ved den mest specifikke. Hvis politik 3 afviser og politik 7 tillader, kan en session fejle uden nogensinde at nå reglen, der ville slippe den igennem. Rækkefølgen er en reel indstilling på NPS og de fleste produkter til netværksadgangskontrol, og den flytter sig gennem årene.

De betingelser, der følger med gruppen, er den anden halvdel. Enhedstilstand, godkendelsesmetode, gennemført MFA, kildenettet, certifikatemne eller et tidsvindue kan stå i samme politik. Når en af dem ikke er opfyldt, matcher politikken ikke, motoren falder igennem, og standardafvisningen gælder. Fra brugerens stol ser det ud, som om gruppen ignoreres; fra motorens stol blev gruppen aldrig spurgt.

Katalogdetaljer skaber samme illusion. En politik, der matcher Windows-gruppemedlemskab, læser SID’er i brugerens token, og der listes kun sikkerhedsgrupper, en distributionsgruppe dukker aldrig op. Den primære gruppe bæres i sit eget felt i stedet for på listen, så en politik fastgjort til den kan fejle lydløst.

Læs accept- eller afvisningsposten, før du rører en gruppe

Stil først ét spørgsmål: nåede anmodningen overhovedet autorisationsfasen? På NPS står svaret i hændelsesloggen, hvor 6272 registrerer givet adgang, 6273 en afvisning og 6274 en anmodning, som serveren kasserede før politikvurderingen. De tre tal deler problemet i tre forskellige undersøgelser, og kun én af dem handler om grupper.

Når loggen ikke er tilgængelig, spørg serveren direkte og læs, hvad den returnerer. Et svar uden Filter-Id og uden tunnelattributter siger, at serveren anser sessionen for ordinær, og at gatewayen anvender sine egne regler. Et svar med attributter, som håndhævelsespunktet ikke implementerer, er en anden fejl: autorisationen gik igennem, og enheden ignorerede resultatet.

radtest alice 'password' 10.0.0.5 0 testing123

Sammenlign de returnerede attributter med dem, gatewayen dokumenterer, ikke med hvad gruppenavnet antyder. Den sammenligning skiller som regel et politikproblem fra et håndhævelsesproblem.

En gruppeændring virker ikke bagudrettet

Autorisationsattributter returneres én gang, når sessionen godkendes. Gatewayen gemmer dem på sessionen og læser ikke kataloget igen for hver pakke, og derfor bliver en etableret session ved med at virke, efter du fjerner nogen fra en gruppe, mens en ny kan fejle.

For at få ændringen til at virke skal der en ny autorisationsbeslutning til, ikke bare friske nøgler. Hvor serveren understøtter RFC 5176 dynamisk autorisation, tvinger en Disconnect-Request eller CoA-Request til UDP 3799 sessionen til at blive revurderet; ellers afbryd klienten og lad den genoprette forbindelsen. En genforhandling fornyer tunnelnøglerne og lader normalt autorisationsresultatet være urørt.

Ret betingelsen, ikke gruppen

Når du ved, hvilken politik der greb, er reparationen som regel lille: omarranger en afvisning, der overskygger den tilsigtede tilladelse, føj den manglende enheds- eller MFA-betingelse til den politik, du mente, eller skriv en snæver regel for den ene ressource i stedet for at løfte brugeren ind i en gruppe med ti andre.

En kort løkke holder ændringen ærlig:

• Gengiv afvisningen med den oprindelige konto, og skriv hændelses-ID’et ned, før du ændrer noget.
• Ændr ét objekt, en politikrækkefølge, en enkelt betingelse eller én gruppe, og noter hvilket.
• Åbn en ny session, bekræft at tilladelsen vises i loggen, og at ressourcen faktisk åbner.
• Test en bruger, der stadig skal afvises, så reparationen ikke utilsigtet har udvidet politikken.

Hvis tilladelsen er korrekt, og ressourcen stadig ikke åbner, er problemet flyttet til routing eller navneopløsning i det øjeblik autorisationen gik igennem. Hold de to fejl adskilt, og den næste billet tager minutter i stedet for en eftermiddag.