Å legge en bruker til en VPN-gruppe gir ikke tilgang i seg selv
Gruppemedlemskap er én betingelse, ikke en tillatelse. Se hva gatewayen faktisk matchet, les accept- eller avvisningsposten, og test begge utfall.
Kontoen står i riktig gruppe, innloggingen lyktes, men tilkoblingen avvises eller når ingenting nyttig. Flere grupper gir mer enn billetten ba om. Gruppemedlemskap er ett innspill, ikke beslutningen: gatewayen matcher fakta mot ordnet policy og bestemmer først da. Feiler en annen betingelse, endrer gruppen bare eksponeringen.
Gruppemedlemskap er en betingelse, ikke en tillatelse
I RADIUS er gruppen et autorisasjonsattributt som beskriver økten, ikke tillater den. Serveren svarer Access-Accept eller Access-Reject, og kan legge ved Filter-Id, Class eller tunnelattributter fra RFC 2868; utstyret tolker dem som produsenten vil. Ingenting mapper gruppen til full tilgang; mappingen skriver den som satte policyen.
Derfor virker samme gruppenavn ulikt på to systemer. Microsoft NPS bygger policyer av betingelser, begrensninger og innstillinger og vurderer dem i fast rekkefølge. OpenVPN Access Server har egen modell, og community-servere overlater ofte alt til client-connect eller client-config-dir.
Regelen som matchet avgjør, ikke gruppen du forventet
De fleste motorer stopper ved første match eller den mest spesifikke. Avviser policy 3 og tillater policy 7, kan økten feile før den når regelen som slapp den gjennom. Rekkefølgen er en reell innstilling og forskyver seg over år.
Betingelsene rundt gruppen er andre halvdel: enhetstilstand, autentiseringsmetode, MFA, kildenett, sertifikatsubjekt eller tidsvindu. Mangler én, matcher ikke policyen, og standardavvisning gjelder. Brukeren ser en ignorert gruppe; motoren spurte aldri.
Katalogdetaljer lurer på samme måte. Policy på Windows-grupper leser SID-er i tokenet, der bare sikkerhetsgrupper listes. Primærgruppen ligger i eget felt, så policy festet til den kan feile stille.
Les accept- eller avvisningsposten før du rører en gruppe
Spør først: nådde forespørselen autorisasjonsfasen? På NPS står 6272 for gitt tilgang, 6273 for avvisning og 6274 for en forespørsel forkastet før policyvurdering. Tallene deler problemet i tre undersøkelser; bare én gjelder grupper.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Er loggen utilgjengelig, spør serveren og les svaret. Uten Filter-Id og tunnelattributter anser serveren økten som ordinær og gatewayen bruker egne regler. Attributter håndhevelsen ikke implementerer er en annen feil: autorisasjonen gikk gjennom og enheten ignorerte den.
radtest alice 'password' 10.0.0.5 0 testing123Sammenlign attributtene med dem gatewayen dokumenterer, ikke med gruppenavnet. Det skiller policyproblem fra håndhevelsesproblem.
En gruppeendring virker ikke bakover
Attributtene returneres én gang ved autentisering. Gatewayen lagrer dem på økten og leser ikke katalogen per pakke, så en etablert økt fortsetter etter at noen fjernes fra gruppen.
Endringen krever en ny autorisasjonsbeslutning, ikke bare nye nøkler. Støtter serveren RFC 5176, tvinger Disconnect-Request eller CoA-Request til UDP 3799 ny vurdering; ellers koble fra og til på nytt. Nye forhandlinger fornyer bare tunnelnøklene.
Rett betingelsen, ikke gruppen
Når du vet hvilken policy som slo til, er reparasjonen liten: omorganiser avvisningen som skygger for tillatelsen, legg til manglende enhets- eller MFA-betingelse, eller skriv en smal regel for én ressurs i stedet for å løfte brukeren inn i en gruppe med ti andre.
En kort løkke holder endringen ærlig:
- Gjenskap avvisningen med originalkontoen og noter hendelses-ID før du endrer noe.
- Endre ett objekt, policyrekkefølge, én betingelse eller én gruppe, og noter hvilken.
- Åpne ny økt, bekreft at tillatelsen vises i loggen og at ressursen åpnes.
- Test en bruker som fortsatt skal avvises, så reparasjonen ikke utvidet policyen.
Er tillatelsen riktig og ressursen fortsatt stengt, har problemet flyttet seg til ruting eller navneoppslag da autorisasjonen gikk gjennom. Hold feilene atskilt, og neste billett tar minutter.